The AMM's price discovery mechanism, common to such protocols, can be significantly influenced by large trades, especially when liquidity is low. This could be exploited by an attacker to manipulate the price for their benefit, potentially affecting other users or integrated systems relying on this AMM as a price oracle.
Technical Description:
Mechanism: AMMs determine prices based on the ratio of reserves in their liquidity pools. A trade that significantly alters this ratio will cause a correspondingly significant price change (slippage).
Root Cause: This is an inherent characteristic of the constant function market maker (CFMM) model, where price is a direct function of pool balances. Low liquidity (small reserve_a and reserve_b) exacerbates this, as smaller trades can cause larger proportional changes.
Attack Vector: An attacker could execute a large trade to shift the AMM's price, then exploit this altered price in another transaction (e.g., on another protocol that uses this AMM as an oracle, or by sandwiching a victim's trade).
Prerequisites: The pool must have relatively low liquidity compared to the size of the manipulative trade. For oracle manipulation, another protocol must be using this AMM's price feed without sufficient safeguards (e.g., TWAP, multiple oracle sources).
Severity Classification: Medium (primarily due to systemic risk if used as an oracle without care)
Likelihood:
Likelihood Assessment:
Attack Complexity: Low to Medium. Requires capital for the manipulative trade.
Prerequisites: Low liquidity in the target pool.
Detection Difficulty: Medium. A large trade is visible, but intent can be hard to discern immediately.
Impact:
Impact Assessment:
Confidentiality: Not directly applicable.
Integrity: Price integrity can be compromised. If used as an oracle, data provided by the AMM (price) can be intentionally falsified.
Availability: Not directly applicable, though extreme price volatility might deter legitimate users.
Financial: Direct users may suffer from high slippage. Protocols relying on a manipulated price oracle could suffer significant financial loss.
Exploit Scenario:
Assume a pool A/B with low liquidity, e.g., 100 A and 100 B, price 1 A = 1 B.
Attacker swaps a large amount of A, e.g., 100 A, for B.
The pool becomes, e.g., 200 A and 50 B (amount_out = 100 * 100 / (100+100) = 50 B, ignoring fees for simplicity). The new price is 1 A = 0.25 B.
If another protocol reads this price, it sees A as much cheaper.
Strategy: This is an inherent AMM property. Mitigation focuses on user awareness and safeguards for dependent systems.
Implementation (for users): Users should always provide min_out (for swap_exact_in) and max_in (for swap_exact_out) parameters to limit their slippage.
Implementation (for protocols using this AMM as an oracle):
Do not rely on a single spot price from the AMM.
Implement Time-Weighted Average Price (TWAP) or Volume-Weighted Average Price (VWAP) oracles.
Use multiple oracle sources and cross-reference prices.
Perform sanity checks on price changes.
Alternative Solutions: For the AMM itself, ensuring deep liquidity is the best defence, though this is market-dependent
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.