Liquidity Manipulation Remediation

Overview

Related Detector: Liquidity Manipulation

Pool manipulation exploits missing invariant enforcement. The fix is to validate mathematical invariants (constant product, constant sum) after every pool state modification and verify token account balances match reserve values.

Recommended Fix

Before (Vulnerable)

pool.reserve_a += amount_a;
pool.reserve_b += amount_b;
// No invariant check

After (Fixed)

let k_before = (pool.reserve_a as u128) * (pool.reserve_b as u128);
pool.reserve_a += amount_a;
pool.reserve_b += amount_b;
let k_after = (pool.reserve_a as u128) * (pool.reserve_b as u128);
require!(k_after >= k_before, ErrorCode::InvariantViolation);

// Also verify actual token balances match
let actual_a = ctx.accounts.token_a.amount;
require!(actual_a == pool.reserve_a, ErrorCode::ReserveMismatch);

Alternative Mitigations

Flash Loan Protection

Add a re-entrancy guard to prevent flash loan manipulation:

require!(!pool.is_locked, ErrorCode::ReentrancyGuard);
pool.is_locked = true;
// ... pool operations ...
pool.is_locked = false;

Common Mistakes

Mistake: Checking Only One Reserve

// WRONG: only validates reserve_a, attacker can manipulate reserve_b
require!(pool.reserve_a >= min_reserve_a, Insufficient);

Always validate the invariant relationship between all reserves.

References

• CWE-682: Incorrect Calculation
• Sealevel Attacks