Liquidity Manipulation

Overview

The liquidity manipulation detector identifies vulnerabilities in liquidity pool operations that could allow manipulation of pool state, reserves, or pricing. It detects direct pool reserve manipulation without validation, missing balance checks on liquidity operations, pool state imbalance after operations, flash loan combined with pool manipulation, and missing invariant checks such as the constant product formula.

For remediation guidance, see Liquidity Manipulation Remediation.

Why This Is an Issue

Liquidity pools hold significant value and rely on mathematical invariants (constant product, constant sum) to maintain correct pricing. If a program allows direct manipulation of pool reserves without enforcing these invariants, an attacker can drain the pool, manipulate prices for downstream protocols, or execute flash loan attacks that temporarily distort pool state for profit.

How to Resolve

Before (Vulnerable)

// Vulnerable: directly modifies reserves without invariant check
pub fn add_liquidity(ctx: Context<AddLiq>, amount_a: u64, amount_b: u64) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    pool.reserve_a += amount_a;
    pool.reserve_b += amount_b;
    // No constant product invariant check
    Ok(())
}

After (Fixed)

// Fixed: enforces constant product invariant
pub fn add_liquidity(ctx: Context<AddLiq>, amount_a: u64, amount_b: u64) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    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);
    Ok(())
}

Example JSON Finding

{
  "detector": "liquidity-manipulation",
  "severity": "critical",
  "confidence": 0.65,
  "message": "Pool reserve modification without constant product invariant validation",
  "location": { "function": "add_liquidity", "block": 0, "statement": 3 }
}

Detection Methodology

1. Pool state write detection: Identifies store operations to pool reserve accounts.
2. Invariant check search: Looks for mathematical invariant validations (k = x * y) after state modifications.
3. Balance consistency: Verifies that token account balances match pool reserve values.
4. Flash loan pattern detection: Identifies borrow-use-repay patterns that could manipulate pool state temporarily.

Limitations

False positives: Administrative functions for pool initialization or migration may legitimately modify reserves. False negatives: Custom invariant formulas (concentrated liquidity, weighted pools) may not be recognized.

Related Detectors

• Price Impact — price manipulation through large trades
• Wrapped Token Parity — token supply invariants
• Swap Validation — missing swap operation validation

References

• CWE-682: Incorrect Calculation
• Sealevel Attacks