On July 30, 2023, attackers exploited a compiler defect affecting several Curve liquidity pools. The incident was not a 2026 bug, and it did not establish that every Curve pool was vulnerable. It did show why a long-term holder needs to examine more than a pool’s advertised yield or audit badge: the assets, deployed contracts and dependencies all matter.
A Curve position can earn trading fees and, in some cases, token rewards. In return, the depositor takes risks that do not come with simply holding the assets, including contract failure, changes in the assets’ relative prices and difficulty exiting during stress. The checks below help make those exposures visible; none can make a deposit safe by itself.
What happened in the 2023 Vyper exploit?
Several affected pools used contracts written in Vyper. According to the Vyper security advisory, compiler versions 0.2.15, 0.2.16 and 0.3.0 could assign separate locks to functions that were intended to share a named reentrancy lock. Under additional contract-specific conditions, an attacker could call back into a contract before its operation was complete. The source code appeared to specify protection, but the compiled behavior did not provide the intended shared lock. This was not a failure of every use of @nonreentrant.
Chainalysis documented the event and describes affected pools including JPEG’d pETH–ETH, Alchemix alETH–ETH, Metronome msETH–ETH and CRV/ETH. Chainalysis estimated that approximately $70 million was initially affected and reported subsequent returns and white-hat recoveries. That initial estimate is not a final unrecovered-loss figure. For more accounts of the incident, see Hacken’s technical breakdown and Curve Finance liquidity pools hack explained — Hacken. The event is also covered in Vulnerability in Curve Finance Vyper Code Leads to Multi-Million Dollar Hack — Chainalysis.
The practical lesson is to separate three checks. A source-code review examines the intended logic. A compiler-version check identifies the toolchain used to build it. Verification of deployed code helps establish which code and settings correspond to the contract on-chain. Even when reviewed source matches a deployment, that match does not prove the compiler produced safe behavior or that the review covered every relevant dependency.
What risks sit inside a Curve pool?
Token backing, pegs and pool composition
Many Curve pools are designed for assets expected to trade near one another, such as stablecoins or related wrapped tokens. When one asset weakens, trading can leave the pool holding more of it and less of the stronger asset. A liquidity provider may then receive a different mix on withdrawal and fare worse than if they had held their original assets. Whether that difference persists depends on the price path, withdrawal timing, fees and pool design; a peg can recover, but it may not.
Research each token as well as the pool. A stablecoin, wrapped asset or liquid-staking token can have its own issuer, backing arrangements, contracts and administrative controls. A pool audit does not resolve a weakness in an underlying asset. A metapool adds another dependency: it trades against a base pool, so its depositor should examine the base assets and contracts as well as the asset featured in the metapool. That structure does not, by itself, mean a larger loss in every scenario.
Price readings and downstream borrowing
A Curve pool can provide a swap quote, while a virtual-price reading measures something different about an LP token. Neither should automatically be treated as a reliable external market price. The question is whether another protocol uses a particular pool reading to value collateral or make another consequential decision. ChainScore’s analysis of Curve oracle risk discusses this category of oracle risk; the exact reading and its downstream use determine the exposure. Oracle Manipulation Risk in Curve Pools | ChainScore Protocols provides further context, but a pool quote and an LP-token virtual price are not interchangeable.
A downstream protocol may use averaged prices, independent references or limits on abrupt changes to reduce particular manipulation risks. Those measures are not complete fixes. If you plan to borrow against an LP position or an asset priced through a pool, examine the lending protocol’s price source and liquidation rules separately. Borrowing adds interest and collateral risk; it does not change the pool’s underlying loss mechanics.
Permissions and contract changes
Admin and upgrade powers vary by contract. Do not assume that every Curve pool can be paused, repriced or upgraded by the same party. Inspect the specific pool, factory, gauge and other contracts your position depends on: who can change what, whether a multisig or timelock is involved, and how much notice a change would provide. Federal Reserve research on DeFi discusses governance risks across DeFi, rather than documenting the permissions of any particular Curve pool. For the broader governance discussion, see Decentralized Finance: Transformative potential and associated risks — Federal Reserve.
A contract that can change introduces a different risk from the 2023 compiler defect. An upgrade may address a problem, but it may also introduce one. Conversely, an immutable pool can still have vulnerable code or risky assets. Check the actual authorities and dependencies instead of treating either design as an automatic mark of safety.
Where does pool income come from—and what can reduce it?
Trading fees come from swaps through the pool. Some positions may also receive token incentives, such as rewards directed through Curve gauges. These are different sources of income: fees depend in part on trading activity, while token rewards can change with emissions, votes and the reward token’s price. Curve has described paid incentives for gauge votes, so a displayed reward rate alone does not establish strong demand for trading in that pool.
Consider fees and rewards alongside changes in position value, transaction costs and any borrowing interest. A positive displayed rate does not guarantee a positive net result. Falling liquidity or an increasingly uneven asset mix can also make an exit less attractive. Large swaps may face poor execution or transaction-ordering attacks; a sandwich attack directly harms an affected trader’s execution, not automatically every liquidity provider’s returns.
A pre-deposit and ongoing-review checklist
- Identify the exposure. List every pool asset, its issuer or backing, and any base-pool or wrapped-token dependencies. Ask what you might receive if one asset loses its peg.
- Identify the contracts. Find the specific deployed pool and related contracts, their compiler versions where relevant, and the scope and date of available security reviews. Verification and audits are evidence to assess, not guarantees.
- Check control and price dependencies. Read the actual admin and upgrade permissions. If another protocol values your position, find out which price reading it uses and what happens when prices move sharply.
- Separate sources of income. Compare recent trading activity and fees with token incentives. Account for transaction costs and, if applicable, borrowing interest and liquidation exposure.
- Plan the position and exit. Choose a size that fits the possibility of substantial loss. Check pool balances and available exit liquidity, and decide what changes would prompt a review or withdrawal. Splitting positions can limit concentration in one pool, but can also add contracts and assets to monitor.
- Review what can change. Recheck asset backing, pool composition, permissions, reward terms and your ability to exit. A period without incidents does not establish that the pool has become safe.
For a long-term holder, the useful question is not simply whether a pool pays a rate today. It is whether the expected fees and possible rewards justify holding a changing mix of assets through that pool’s particular contracts and controls. Seeing holdings, debt and position risk together can help frame questions for a portfolio-aware AI coach or human guide, but the decision and its risks remain yours.
FAQ
Was there a Curve Vyper exploit in 2026?
The compiler incident discussed here occurred on July 30, 2023. This article does not establish a corresponding 2026 exploit.
Did the Vyper bug affect every Curve pool?
No. The advisory identifies particular compiler versions and a named-lock defect that required additional contract-specific conditions. Check the contracts behind a particular pool rather than assuming all pools shared the vulnerability.
Does an audit or verified deployment make a pool safe?
No. An audit has a scope and date, and a deployment match does not prove that a compiler produced the intended behavior. Underlying tokens, permissions and downstream dependencies also need attention.
Which Curve pool is safest for a beginner?
There is no universally safest pool. Compare asset backing, pool dependencies, deployed contracts, permissions, liquidity and how you would exit under stress. If you cannot explain those exposures, waiting rather than depositing is a reasonable choice.
Does earning fees offset a depeg?
Not necessarily. Fees and rewards may be smaller than a decline in position value or other costs. The result depends on the assets, price path, pool design and when you withdraw.