Known Issues
Last updated
Was this helpful?
Last updated
Was this helpful?
Convex has strived to be a trustless platform in which deposits can never be touched or accessed by the admin account.
Since launch we have determined a few vectors that would go against that stance and thus have implemented various checks and conditions that the admin account must clear before certain actions can be taken.
With the help from V (OpenZeppelin) and 0xJuicer/0xPhaedra0x (Tang Finance) we have implemented layers that either completely block some patterns or make it extremely difficult to put into action.
Additional Layers: poolManagerProxy: poolManagerSecondaryProxy: boosterOwner:
These layers, to our knowledge, successfully block most vectors that could be used. However there is still one known path that uses a series of fake gauges to create fake pools and exploits the shutdown system. We believe this has been sufficiently mitigated as the steps that must be taken are as follows:
Create a fake gauge for an existing pool and create an Curve DAO proposal to add said fake gauge
Pass Curve DAO proposal undetected (7 day voting period)
Give the fake gauge weight on Curve's gauge controller.
Shutdown an existing legit Convex pool. (Curve LP tokens are unstaked and returned to Booster contract)
Add a new pool on Convex that uses the fake gauge but legitimate LP tokens
Loop fake liquidity onto the gauge to increase Convex Deposit Tokens (deposit, withdraw directly from gauge, deposit again)
Call shutdownSystem() on Pool Manager Secondary Proxy. New pools can no longer be added
Call queueForceShutdown() on Booster Owner. A normal shutdown call will fail with the fake pool as there are more Convex Deposit Tokens than there are LP tokens, thus need to use this timelock shutdown feature.
Wait 30 days for the timelock to complete
Call forceShutdownSystem() on Booster Owner
Withdraw real Curve LP tokens using the illegitimate Convex Deposit Tokens
We believe this process which requires a DAO proposal, shutting down a legitimate pool, and waiting for a 30 day timelock should be sufficient mitigation. We are writing this process here as well so that this weakness is known and can be detected.