On July 30, 2023, attackers exploited a compiler flaw affecting several Curve pools. The event showed why a long-established pool can still carry risks that are hard to see from its advertised yield or an audit badge. For a long-term depositor, the useful question is how to examine the code, assets, permissions and income sources of the particular pool under consideration.
What happened in the 2023 exploit?
Curve pools affected by the incident had been compiled with vulnerable versions of Vyper. Their source code specified reentrancy protection, but functions meant to share a lock received separate locks after compilation. Under the right contract conditions, an attacker could call back into a pool before an operation was complete. The Vyper security advisory identifies versions 0.2.15, 0.2.16 and 0.3.0 as affected; it does not mean every contract built with those versions was exploitable.
Chainalysis documented the event and reported initial losses in the tens of millions of dollars across affected pools. Some funds were later returned, so an initial loss estimate should not be mistaken for the final amount lost. For the incident chronology and subsequent returns, see its report, Vulnerability in Curve Finance Vyper Code Leads to Multi-Million Dollar Hack — Chainalysis. For another technical walkthrough, see Hacken’s technical breakdown, titled Curve Finance liquidity pools hack explained — Hacken.
The distinction is between source code, the compiler output and the bytecode deployed on-chain. Checking that deployed code corresponds to a reviewed build helps establish what is running. It does not prove that the compiler behaved as intended, that the review found every flaw or that the pool’s configuration is safe.
Where can a Curve depositor lose money?
Pool code and the tokens inside it
A pool may have a contract bug even if it has operated for years. Each token it holds brings separate risks: an issuer or custodian may fail, a wrapped asset may lose backing, or a token contract may be exploited or changed. A pool audit does not replace checking those assets and their dependencies.
Pegs and changes in position value
Many Curve pools are designed for assets expected to trade near one another. Imagine two stablecoins each expected to trade around $1. That is an explanatory assumption, not a promise that either coin will hold its peg. If one falls in price, trades can leave liquidity providers with more of the weaker asset and less of the stronger one. Fees may not make up for that change. If the asset does not recover, the loss may persist.
Impermanent loss compares the value of a liquidity position with simply holding the assets contributed. A close peg can keep that difference modest for a time, but a lasting divergence changes the result. There is no dependable rule that a metapool or a shallow pool will suffer a particular loss relative to another design: token behavior, pool balances, trades and exit conditions all matter. A metapool adds a dependency on its base pool, so inspect both layers rather than judging it by the smaller token alone.
Pool prices and external oracle use
A price derived from one pool can be distorted by an unusually large trade, particularly when liquidity is thin or balances are skewed. The question for a depositor is not whether every Curve price can be manipulated at will, but whether another protocol they use relies on pool data in a way an attacker could exploit. For a discussion of that downstream risk, see ChainScore’s analysis of Curve oracle risk, titled Oracle Manipulation Risk in Curve Pools | ChainScore Protocols.
Curve’s get_dy provides a quote for a specified trade. get_virtual_price serves a different purpose related to pool accounting; neither is a universally safe external market-price feed. Integrators may use averaging, independent price sources or limits on abrupt moves, but those protections need to be assessed in the actual borrowing or trading protocol—not assumed because the underlying pool is Curve.
Permissions, upgrades and governance
Do not assume every Curve pool has the same owner or that every owner can pause, upgrade and redirect it. Available controls depend on the deployed pool, factory and related contracts. Check which parameters can change, who can change them, whether changes are delayed and whether an upgrade path exists. A multisig or timelock may limit certain risks, but its presence alone does not establish that a pool is safe.
For broader context on governance and other DeFi risks, Federal Reserve research on DeFi is a paper by Francesca Carapella, Edward Dumas, Jacob Gerszten, Nathan Swem and Larry Wall. It is hosted by the Federal Reserve Board; its conclusions are the authors’ own, not the Board’s position. The same authors’ Decentralized Finance: Transformative potential and associated risks — Federal Reserve offers context, not a pool-specific review.
Do fees and CRV rewards justify the exposure?
Separate a pool’s income sources. Trading fees depend on activity in the pool. CRV rewards depend on gauge incentives and can change with voting and emissions. A high displayed reward rate does not establish that the pool has sustained trading demand or that the token reward will retain its market value.
Compare the value of the entire position at exit, including assets received, fees and rewards, against what holding the original assets would have been worth over the same period. Account for transaction costs. If capital was borrowed to enter the pool, add borrowing interest and the possibility of collateral liquidation. Borrowing does not change the pool’s inherent impermanent-loss mechanics; it adds another set of risks. Tax treatment depends on jurisdiction and the transactions involved.
Large withdrawals may make exits more expensive when liquidity falls. Transaction ordering can also worsen a trader’s swap execution; it should not be described as an automatic, routine deduction from every liquidity provider’s earnings. TVL, volume and incentives are useful observations, but none is a substitute for understanding what the position actually owns.
What should you check before depositing?
- Identify the exact contracts. Confirm the pool and any base pool, gauge or wrapper involved. Look for audits covering the relevant versions, and check the compiler version and deployed build where that information is available. An audit is evidence of review, not a safety certificate.
- Examine every asset. Find out who issues or backs it, how redemption works and what could make its market price diverge from its expected peg.
- Inspect current conditions. Review pool balances, liquidity, recent volume, fees and withdrawal routes. An imbalance deserves investigation; by itself it does not tell you why traders moved or what will happen next.
- Check permissions and dependencies. Determine which controls exist for this deployment, who holds them, and whether a borrowing protocol or another position depends on this pool’s prices or assets.
- Decide what you can monitor. Set a position size that accounts for a possible loss, identify changes that would prompt a review and consider how you would exit during a disruption. Splitting deposits can reduce concentration in one pool, but shared tokens, contracts or protocols can still fail together.
For holders following a Hold → Borrow → Deploy → Earn framework, borrowing is a decision to evaluate, not a required step. Seeing holdings, debt and position risk together can help frame questions for a portfolio-aware AI coach or human guide. Those tools cannot ensure that every Curve position is covered, keep information current in every circumstance or prevent a loss.
What should you revisit after depositing?
Recheck the pool’s assets and balances, fee income versus token rewards, material contract or permission changes, and whether the position still fits your circumstances. If you borrowed, monitor collateral and your LTV ratio alongside adverse-price scenarios. A monitoring routine helps you respond to new information; it cannot guarantee that an exit will be available at an acceptable price during an exploit or depeg.
FAQ
Is Curve Finance safe to use?
There is no single safety rating that applies to all Curve pools. The 2023 exploit affected particular vulnerable deployments, while asset, peg, permission and integration risks differ by pool. Assess the exact position rather than relying on the Curve name alone.
Is a stablecoin pool safer than holding crypto?
It has a different risk profile. A stablecoin pool may earn fees and rewards, but adds pool-contract and withdrawal risks to the token, issuer and peg risks of the assets it holds. The comparison depends on the assets and on what you would otherwise hold.
Does an audit mean the deployed pool is safe?
No. Check what contracts and versions were reviewed, what was deployed and whether material dependencies or settings have changed. The Vyper incident illustrates why even source code that appears to contain a safeguard may not behave as expected after compilation.
Can borrowing against crypto make a Curve position riskier?
Yes. Interest and potential liquidation add to the pool’s existing risks. If collateral falls in value or borrowing terms change, you may need to add collateral or repay debt at an unfavorable time. Read more about crypto borrowing and liquidation risk before treating a pool’s advertised yield as net income.