Lesson 7 — Oracle and price manipulation: flash loans against TWAPs

**The naive design: spot price from a single AMM.** A protocol needs to price token X in USD. It calls `getReserves()` on the X/USDC Uniswap V2 pool and computes `price = reservesUSDC / reservesX`. The bug: anyone with capital can move that ratio temporarily. An attacker borrows a large amount of USDC via flash loan, swaps it for X (driving the price up), uses the inflated price to borrow more X-collateralised value than they could legitimately, exits, repays the flash loan from the borrowed value. Net profit: the gap between the inflated oracle price and reality. Spot price from a single pool is unsafe.

**Time-weighted average prices (TWAPs).** Uniswap V2 includes a cumulative-price accumulator that lets contracts compute a TWAP over a chosen window. A 30-minute TWAP is much harder to manipulate than spot — moving the average by N% requires the attacker to either hold the manipulated price for 30 minutes (capital-cost prohibitive) or move it by enormous N during a portion of the window. Uniswap V3 adds a more efficient TWAP with arbitrary windows. TWAPs are the minimum defence; they're not a complete one — long-window TWAPs lag real moves and create their own liquidation-pricing problems.

**Cross-pool / cross-DEX manipulation.** A TWAP from a single pool can still be manipulated by an attacker willing to spend capital across the window. The defence is to use multiple pools / DEXes / sources and aggregate. Chainlink's price feeds aggregate multiple off-chain market-data sources and post the median. Pyth uses publisher-aggregated prices with explicit confidence intervals. Both are substantially harder to manipulate than any single-pool oracle.

**The Mango Markets exploit (October 2022).** Avraham Eisenberg's $117M exploit: Mango's perpetuals platform priced MNGO from on-chain DEX trading. Eisenberg used $5M to push the MNGO price up by ~1000% within a window, used the inflated mark price to borrow $117M of other assets against the MNGO collateral, and exited. The 'attack' was deemed legal-ish at first because the price moves were genuine market trades — he later negotiated a partial return, then was charged criminally and convicted in 2024. The contract was 'correct' under its design; the design assumed market prices weren't manipulable, which the attacker proved wrong.

**The Inverse Finance / Cream Finance / bZx pattern.** Multiple protocols lost funds to the same pattern: lending against a collateral asset priced from a single AMM, attacker manipulates the AMM, borrows the inflated value, exits. The defence is well-known (TWAP from multiple sources, conservative LTV limits, circuit breakers on rapid price moves) but the bug class continues to appear because adopting safer oracles costs gas and complexity.

**Validation patterns.** A defensive oracle integration includes: (1) **Staleness check** — reject prices older than N minutes (Chainlink reports a last-update timestamp). (2) **Deviation circuit breaker** — if the new price differs from the previous by more than X%, halt operations and require manual review. (3) **Heartbeat enforcement** — require the oracle to update at minimum frequency; if it doesn't, pause. (4) **Sanity-bound checks** — reject prices outside a plausible range. None of these eliminate manipulation but each makes attacks harder and slower.

**The honest framing.** Even the best on-chain oracle is not infallible — Chainlink has had bugs, Pyth has had incident reports. The right framing for protocol design is *defence in depth*: oracles, conservative LTVs, slow-moving accounting (no liquidations on a single bad tick), circuit breakers, and emergency pause governance. Protocols that rely on a single oracle source are taking concentrated counterparty risk regardless of the source's reputation.