Safe StableSwap-NG Deployment: How to Prevent Risks from Volatile Oracles

Source: Safe StableSwap-NG Deployment: How to Avoid Risks from Volatile Oracles | MixBytes

Curve’s StableSwap-NG upgrades the original StableSwap AMM by using an on-chain oracle to rescale one token’s balance dynamically, keeping the pool’s price tightly aligned with off-chain data. This enables low-slippage, stable trading with efficient fee collection but also introduces risks tied to oracle volatility and asset selection.

How StableSwap-NG Works

• Core idea: One token’s balance is multiplied by an oracle-derived rate factor, so both tokens are measured in a consistent monetary unit on-chain.
• This adjustment updates the pool’s invariant immediately after each oracle update, changing the swap price even without any liquidity movement.
• Near the peg, the pool mixes a flat constant-sum curve with the traditional constant-product curve to achieve smooth price transitions.

Oracle Updates and Price Sensitivity

• The oracle price influences the swap price almost one-to-one in high-amplification pools (where the amplification factor is large).
• A 1% oracle increase directly reduces the output token amount by about 1%, letting traders track price moves tightly.
• This design requires asset pairs with stable, well-correlated oracles; volatile or unreliable oracles cause inefficiencies and risks.

The Oracle Sandwich Attack Risk

• A trader can exploit sudden oracle updates by:

1. Buying tokens priced below the new oracle rate.
2. Letting the oracle update shift prices.
3. Selling back immediately after at a profit.

• Since each swap fee is typically about 0.03%, a quick round trip costs roughly 0.06%. If the oracle jumps more than ~0.065%, the trader profits after fees and gas.
• Simply increasing fees to block this is problematic:
  • High fees reduce competitiveness.
  • They erode staking yields for LPs in wrapped or yield-bearing tokens (e.g., wstETH).

Why Existing Fee Surcharges Don’t Help

• StableSwap-NG’s imbalance surcharge triggers on token imbalance, but oracle updates don’t change raw token balances - only their valuations.
• This surcharge remains inactive during oracle jumps, leaving LPs vulnerable to arbitrage losses.
• Thus, fees tied to token imbalance cannot protect against price shocks caused by oracle changes.

Proposed Solution: Volatility-Responsive Fee with Linear Decay

To protect the pool without handicapping normal trading, the authors suggest a dynamic “circuit breaker” fee triggered by large oracle moves:

• Shock Detection: When the oracle’s rate changes beyond a small threshold (e.g., 0.10%), record the jump and timestamp.
• Extra Spread: Apply an immediate additional fee roughly equal to the oracle’s jump (e.g., 0.1% surcharge for a 0.1% move).
• Linear Decay: The surcharge fades linearly over a fixed window (e.g., 1 hour) back to zero.
• Low Gas Cost: Only three contract variables need updating; swaps incur minimal computation.

This mechanism raises the cost of the sandwich attack proportionally to the oracle jump, eliminating arbitrage incentives while preserving low fees during stable periods.

Key Takeaways for Pool Deployers

• Choose stable, well-correlated oracles and token pairs to minimize volatility risks.
• Monitor oracle update sizes; if typical moves exceed twice the base fee (~0.06%), implement the volatility-responsive surcharge.
• Use backtests and audits with historical data to calibrate surcharge thresholds and decay times.
• Understand that pools involving highly volatile or unmatched tokens may require more sophisticated mechanisms beyond current StableSwap-NG capabilities.

Conclusion

StableSwap-NG’s elegant oracle-driven design offers efficient, low-slippage swaps with stable assets, but:

• Large oracle jumps pass directly into swap prices.
• Flat fees alone cannot prevent arbitrage from sudden price shifts.
• The volatility-responsive surcharge is a simple, gas-efficient way to protect liquidity providers without penalizing regular trades.

Deployers should carefully analyze oracle behavior and consider integrating adaptive fee mechanisms when deploying StableSwap-NG pools to ensure secure, smooth operations.