StableSwap Invariant Attack

The attack targets the StableSwap invariant, a hybrid function designed for stablecoin pairs that approximates a constant sum (low slippage) near the peg but behaves like a constant product (Uniswap v2) far from it. The attacker identifies a flaw where large, imbalanced trades can be executed with minimal slippage due to miscalculated fees or rounding errors within the curve's implementation, enabling arbitrage-free extraction of value.

A critical precursor step involves donating a large amount of a single token to the liquidity pool. This artificially skews the pool's reserves, dramatically altering the effective exchange rate for subsequent swaps. The donation manipulates the pool's internal state so that a follow-up trade in the opposite direction yields a disproportionately large output, effectively returning the donated tokens plus a significant portion of the pool's other assets.

The attack does not rely on external oracle price feeds. Instead, it manipulates the pool's internal spot price by exploiting the invariant's mathematical properties. The manipulated state causes the AMM to misprice assets, allowing the attacker to swap tokens at a highly favorable rate with abnormally low slippage, contrary to the curve's intended behavior for such an imbalanced trade.

These attacks are typically executed within a single transaction using flash loans. The attacker borrows millions in capital to fund the initial donation and large swap, repaying the loan at the end of the transaction. This requires zero upfront capital and makes the attack economically feasible, as seen in incidents like the Curve Finance exploit of July 2023.

Not all StableSwap pools are vulnerable. The exploit requires specific conditions:

• An implementation bug in the invariant's fee calculation or precision handling.
• Use of a vulnerable Vyper compiler version (as in the 2023 Curve incident).
• A pool with significant liquidity to make the attack profitable after flash loan fees.
• Low network congestion to ensure transaction atomicity.

After the attack drains value, the pool is left in a severely imbalanced state. This creates a massive arbitrage opportunity for other bots to rebalance the pool back to the market price, profiting from the discrepancy. This secondary activity can partially recover some losses for LPs but also adds complexity to the post-mortem analysis of fund flows.

An attacker exploited the peg stability mechanism of the MIM-UST 3Pool on Curve. By taking a flash loan to skew the pool's balance, they manipulated the StableSwap invariant to mint an excessive amount of MIM (Magic Internet Money) at an incorrect price. The attack netted the exploiter over $130M, demonstrating how invariant-based pricing can be gamed when one asset significantly deviates from its peg.

Shortly after launch, Ellipsis Finance (a Curve fork on BSC) suffered an exploit due to an incorrect implementation of the StableSwap invariant. A flaw in the deposit function allowed an attacker to mint an inflated number of LP tokens for a minimal deposit, enabling them to drain approximately $200k from the BUSD-USDT-USDC pool. This incident underscored the dangers of forking complex financial protocols without rigorous security audits.

While not a direct attack on the invariant's math, this incident targeted Saddle Finance's frontend, which implemented the StableSwap model. Attackers compromised the DNS to redirect users to a malicious site, stealing wallet approvals. Although the smart contracts remained secure, it highlighted that the security of an AMM extends beyond its core invariant formula to its entire operational stack.

A persistent theoretical risk for StableSwap pools is oracle manipulation. If a pool's invariant relies on an external price feed for a pegged asset, an attacker could:

• Manipulate the oracle price on a DEX.
• Cause the StableSwap pool to misprice assets relative to the manipulated oracle.
• Arbitrage the pool to extract value, exploiting the discrepancy between the invariant's internal calculation and the corrupted external data.

Post-incident analyses consistently point to parameter tuning and comprehensive audits as critical defenses. The amplification coefficient (A or p parameter) must be carefully set to balance capital efficiency with resistance to manipulation. Major protocols now employ:

• Formal verification of invariant mathematics.
• Time-weighted average price (TWAP) oracles for peg references.
• Emergency DAO controls to pause pools during detected anomalies.

The attack targets the StableSwap invariant, the core formula governing liquidity in pools like Curve Finance. Unlike a constant product AMM (x*y=k), StableSwap uses a hybrid function that approximates a constant sum (x+y=k) when assets are near peg, enabling low slippage. Attackers exploit this by performing large, imbalanced swaps that push the pool far from equilibrium, temporarily breaking the 'stable' region and causing the invariant to behave more like a volatile constant product curve. This creates massive, artificial price impact that can be arbitraged for profit, draining value from the pool's liquidity providers.

A successful attack hinges on manipulating the pool's internal price oracle. StableSwap pools use a time-weighted average price (TWAP) oracle for rebalancing and fee adjustments. By executing a large, imbalanced swap, the attacker creates a severe, short-term price dislocation. If the pool's oracle has a short lookback period or low granularity, this manipulated price can be used to trigger unfavorable rebalancing or be read by external protocols (e.g., lending markets) that rely on it, leading to cascading liquidations or faulty valuations that the attacker profits from.

The key parameter for defense is the pool's amplification coefficient (A). This value controls how 'flat' the bonding curve is within the peg range. A higher A creates a wider, flatter region (more like a constant sum), making it exponentially more expensive to move the price. Mitigations involve:

• Setting A appropriately high for the asset pair's expected volatility.
• Dynamic A adjustments via governance to respond to market conditions.
• Oracle hardening using longer TWAP windows (e.g., 2 hours on Curve v2) to smooth out short-term manipulation attempts.

Attack feasibility is directly tied to liquidity depth and asset correlation. Mitigations include:

• Requiring massive TVL: A deep pool makes the cost of price manipulation prohibitively high.
• Curating asset pairs: Pools should contain only assets with proven, high correlation (e.g., USDC/DAI/USDT). Including a volatile, low-liquidity asset dramatically increases risk.
• Monitoring imbalance: Protocols monitor the pool's token balances; large, sustained imbalances can trigger alerts or temporary fee increases to deter attacks.

Adaptive fee models are a critical line of defense. When a pool detects conditions ripe for an invariant attack (e.g., rapid price deviation), it can activate dynamic fees. For example:

• Curve v2's 'Profit' Algorithm: Automatically increases the swap fee when the internal oracle price deviates from the external market price, capturing arbitrage profit for LPs instead of the attacker.
• Asymmetric Fees: Charging higher fees on the imbalanced side of a trade. This directly increases the attacker's cost, making the exploit economically unviable.

StableSwap pools can be indirectly attacked via read-only reentrancy. This occurs when an external contract (e.g., a lending market) reads the manipulated price from the pool's oracle during a state-changing call to the pool itself. While the pool's state may be secure, the corrupted price read can cause faulty logic in the external protocol. Mitigation requires protocols to implement the Checks-Effects-Interactions pattern and use non-reentrant modifiers on functions that make external calls which could query the vulnerable pool state.

The foundational automated market maker (AMM) model, most famously used by Uniswap V2. It maintains liquidity according to the formula x * y = k, where x and y are reserve amounts and k is a constant. This creates a hyperbolic price curve, leading to significant slippage and making it inefficient for trading stable assets (like USDC/DAI) that should maintain a near-constant 1:1 price.

A hybrid AMM formula designed by Curve Finance for efficient stablecoin trading. It combines the constant product invariant (x * y = k) with a constant sum invariant (x + y = D) using a leverage parameter A. This creates a flatter curve within a defined price range (e.g., $0.99 to $1.01), minimizing slippage for like-kind assets. The precise balance of this formula is what attackers manipulate in an invariant attack.

A crucial, tunable parameter in the StableSwap invariant that controls the pool's preference for the constant sum vs. constant product curve. A higher A value (e.g., 1000) creates a flatter, more capital-efficient curve ideal for stablecoins. A lower A makes the curve more like Uniswap's. Attackers may exploit pools where A is set too high for the actual correlation of the assets, or manipulate the effective A by draining one reserve.

A related attack vector where an attacker artificially manipulates the price feed used by a DeFi protocol. While a pure StableSwap invariant attack exploits the mathematical formula internally, oracle attacks feed false external data. However, the two can be combined: draining a pool via an invariant attack can itself manipulate the pool's spot price, which if used as an oracle, can enable further exploits in lending protocols or derivative contracts.

The risk liquidity providers (LPs) face when the price of deposited assets diverges. In a StableSwap pool for pegged assets, impermanent loss is expected to be minimal. An invariant attack fundamentally changes this dynamic. By forcing the pool's price far from peg (e.g., draining all USDC), the attacker inflicts massive, permanent divergence loss on LPs, who are left holding an imbalanced basket of depegged assets.

A classic smart contract vulnerability where an external call allows an attacker to re-enter the calling contract and manipulate state before the initial execution finishes. This is distinct from a StableSwap invariant attack, which is a financial/logical exploit of the AMM's bonding curve, not a smart contract bug. However, poorly implemented AMM contracts could theoretically be vulnerable to both if balance updates are not handled securely.