← Back to Blog

Oracle Manipulation Attacks: Chainlink vs TWAP vs Custom Feeds

2026-04-09 solidity smart contract security oracle manipulation chainlink TWAP flash loan DeFi security audit price feed

In October 2022, Mango Markets lost $117M in under an hour. The attacker didn't find a bug in the contract code. They read the code, understood exactly how it worked, and used that knowledge to do something the protocol designers hadn't fully accounted for: they pumped the price of MNGO tokens across two accounts they controlled, inflating their collateral value, and borrowed everything the protocol had against it.

The price oracle was technically functioning correctly. It was reading a real market price. The market price was just wrong — because the attacker made it wrong.

That's the oracle problem in DeFi. The contract code can be flawless and the protocol still gets drained.

What an Oracle Attack Actually Is

A price oracle is any mechanism that tells your contract what something is worth. DeFi protocols use price oracles for:

When an attacker can influence the value the oracle returns — even temporarily — they can manipulate any of the above. The window doesn't need to be long. A single block is often enough.

Chainlink is a decentralized oracle network where independent node operators fetch off-chain data and submit it on-chain. Because the price isn't derived from on-chain liquidity, flash loans can't directly influence it. This is Chainlink's key security property.

But "can't be flash-loan manipulated" isn't the same as "can't be attacked."

Staleness and heartbeat

Chainlink feeds update when the price moves more than a deviation threshold (typically 0.5–1%) or after a heartbeat interval (often 1 hour or 24 hours depending on the feed). If the underlying market moves significantly within a heartbeat window, your protocol may be operating on a stale price.

// Common pattern — but missing staleness check
function getPrice(address feed) external view returns (uint256) {
    (, int256 price,,,) = AggregatorV3Interface(feed).latestRoundData();
    require(price > 0, "invalid price");
    return uint256(price);
}

The fix is checking updatedAt against an acceptable staleness threshold:

function getPrice(address feed, uint256 maxStaleness) external view returns (uint256) {
    (
        uint80 roundId,
        int256 price,
        ,
        uint256 updatedAt,
        uint80 answeredInRound
    ) = AggregatorV3Interface(feed).latestRoundData();

    require(price > 0, "negative or zero price");
    require(updatedAt != 0, "round not complete");
    require(answeredInRound >= roundId, "stale round");
    require(block.timestamp - updatedAt <= maxStaleness, "price too stale");

    return uint256(price);
}

Feed unavailability and sequencer downtime

On L2s (Arbitrum, Optimism), Chainlink feeds depend on the sequencer. If the sequencer goes down, the feed stops updating. When the sequencer comes back, there's a grace period before the feed is considered reliable. Protocols that don't check sequencer uptime can be exploited immediately after sequencer restarts, when prices haven't caught up to market reality.

Chainlink provides a Sequencer Uptime Feed for this purpose. Using it is not optional if you're deploying on an L2.

Chainlink won't help you if:
- You're pricing an asset that doesn't have a Chainlink feed (long tail tokens, LP tokens, NFTs)
- Your protocol derives a "price" from the Chainlink price in a way that's manipulable (e.g., calculating LP token value by combining a Chainlink price with on-chain reserves)
- The underlying markets Chainlink aggregates from are thin enough to be moved by large trades

TWAP: Manipulation-Resistant but Latent

TWAP (Time-Weighted Average Price) is computed from on-chain trade history — usually Uniswap V2 or V3 price accumulators. Because it averages over time, you need to move the price and hold it there for the full TWAP window to shift the oracle value significantly.

This makes TWAP resistant to single-block flash loan attacks. It's not free, though.

The cost-of-attack math

For a TWAP window of length T (say, 30 minutes), an attacker who wants to shift the oracle by X% needs to:
1. Move the spot price by X%
2. Hold it there for enough of the T window to shift the average meaningfully
3. Absorb all the arbitrage that will trade against them during that window

Against a liquid pool, this is capital-intensive. Against a thin pool, it's cheap. TWAP security is entirely dependent on the liquidity depth and the TWAP window length.

// Uniswap V3 TWAP example
function getTWAP(address pool, uint32 secondsAgo) internal view returns (uint256) {
    uint32[] memory secondsAgos = new uint32[](2);
    secondsAgos[0] = secondsAgo;
    secondsAgos[1] = 0;

    (int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos);

    int56 tickCumulativeDelta = tickCumulatives[1] - tickCumulatives[0];
    int24 avgTick = int24(tickCumulativeDelta / int56(uint56(secondsAgo)));

    return TickMath.getSqrtRatioAtTick(avgTick); // convert to price
}

Common TWAP mistakes:

Where TWAP fails outright

TWAP needs trading history. If a pool has low volume, the price accumulator barely moves — the "average" is just whatever price the pool happened to be at when it was last traded. In a thin, stale pool, TWAP provides false confidence.

Custom Feeds: The Highest-Risk Category

Many protocols implement their own price calculations — typically to price assets that don't have Chainlink feeds or to combine data sources. This is where the most critical oracle bugs live.

Spot price from reserves

The original sin of DeFi oracle design:

// Never use this as your oracle
function getSpotPrice() public view returns (uint256) {
    (uint112 reserve0, uint112 reserve1,) = pair.getReserves();
    return (reserve1 * 1e18) / reserve0; // instantaneous spot price
}

This returns the price at the moment of the call. A flash loan attack can manipulate reserve0 and reserve1 to any desired ratio within a single transaction, read the manipulated price, exploit the protocol, and repay — all atomically.

Virtually every flash loan attack in DeFi history exploits this pattern in some form.

LP token pricing

LP tokens represent a share of pool liquidity. A common (and wrong) approach is:

LP price = (reserve0 * price0 + reserve1 * price1) / totalSupply

This is manipulable because reserve0 and reserve1 can be shifted by a large trade. The correct approach, formalized by Alpha Finance and widely cited after the CREAM Finance exploit, uses the geometric mean of reserves with an external price feed:

LP price = 2 * sqrt(reserve0 * reserve1) * sqrt(price0 * price1) / totalSupply

This method's key property: it doesn't rely on the current reserve ratio, which is the manipulable part.

Audit Checklist

When reviewing oracle usage in a Solidity contract:

ContractScan's AI engine specifically flags spot-price oracle patterns and unguarded latestRoundData() calls. The LP pricing subtleties and economic attack paths usually require manual or AI-assisted reasoning — static analysis alone won't catch them.

There's no universal "safe oracle." The right choice depends on what asset you're pricing, what liquidity exists, and what latency your protocol can tolerate. What's not acceptable is spot price reads on-chain — that vulnerability class should be extinct by now, and it isn't.

ContractScan is a multi-engine smart contract security scanner. QuickScan is free and unlimited — no sign-up required. Try it now.

Scan your contract now
Slither + AI analysis — Unlimited QuickScans, no signup required
Try Free Scan →