Oracle Manipulation and Flash Loans

The previous three pages each turned on a single mistaken assumption inside one contract: reentrancy assumed control would return before state changed; integer overflow assumed arithmetic wrapped safely; the Parity multisig assumed only owners could call a function. This page is different in kind. Here the vulnerable contract can be perfectly written — no reentrancy, no overflow, airtight access control — and still be drained, because it trusts a number that came from outside itself.

That number is a price. And the tool that turns a bad price into a theft is a flash loan — a primitive with no equivalent in traditional finance, made possible by exactly one property this book keeps returning to: a transaction on Ethereum is atomic. It either happens completely or not at all. This page builds the canonical DeFi exploit — flash-borrow, distort a market, rob a contract that believed the market, repay — and then the defenses that exist precisely because it works.

Why a contract needs an oracle at all

Recall from What a Contract Actually Is that the EVM is deliberately blind. It has no wall clock, no randomness, and — the relevant blindness here — no way to see anything off-chain. A contract cannot open a socket to Coinbase and ask “what is ETH worth in dollars?” There is no network call opcode. The only things a contract can read are its own storage, the storage exposed by other contracts it calls, and a handful of block fields.

So how does a lending protocol know that the ETH you deposited is worth enough to cover the DAI you borrowed? It reads the price from somewhere on-chain. That “somewhere” is an oracle: a contract (or mechanism) whose job is to make an external fact — usually a price — readable by other contracts.

   OFF-CHAIN reality                ON-CHAIN, what a contract can read
   ┌────────────────────┐           ┌──────────────────────────────────┐
   │  ETH = $2,000 on   │   ??? ──► │  the EVM cannot reach out here.   │
   │  Coinbase, Binance │           │  it can only read a NUMBER that   │
   │  Kraken, ...       │           │  some on-chain contract exposes.  │
   └────────────────────┘           └──────────────────────────────────┘
                                              ▲
                                              │  an ORACLE puts a price
                                              │  into on-chain state
                                     ┌──────────────────────┐
                                     │  price = 2000 (slot) │
                                     └──────────────────────┘

The oracle is the bridge across that blindness. And the cheapest, most tempting bridge to build is to read a price that is already on-chain for another reason: the ratio of tokens sitting in a decentralized exchange (DEX) pool.

The tempting shortcut: a DEX pool’s spot ratio

A constant-product automated market maker (AMM) like Uniswap v2 holds a pool of two tokens — say ETH and DAI — and enforces the invariant x * y = k, where x is the ETH reserve, y is the DAI reserve, and k is constant across a swap. The spot price the pool implies is simply the ratio of the reserves:

   pool reserves:   x = 100 ETH      y = 200,000 DAI
   implied price =  y / x  =  200,000 / 100  =  2,000 DAI per ETH

This is free to read: the reserves live in the pool contract’s storage, so any contract can call the pool and divide. No extra infrastructure, no subscription, no third party. A protocol author under deadline reads reserveDAI / reserveETH, calls it “the price of ETH,” and ships.

The fatal word in that last paragraph is spot. The spot ratio is the price at this instant, and — this is the whole vulnerability — anyone can change it by trading against the pool. The reserves are not a passive readout of some external truth; they are a mutable variable that a single large trade moves. A price you can move is a price an attacker can move.

What a flash loan is

Before we weaponize that, we need the second ingredient. A flash loan is a loan with zero collateral, of an arbitrary amount, on one condition: it must be repaid (plus a small fee) before the same transaction ends — otherwise the entire transaction reverts as if it never happened.

This sounds impossible until you remember atomicity. In normal finance, an uncollateralized loan is a bet that the borrower will pay you back later, in a separate future event, which is why it requires trust or collateral. On Ethereum there is no “later” inside a transaction. The lender’s contract can do this:

   within ONE atomic transaction:
     1. lender sends you 10,000,000 DAI          (no collateral!)
     2. your contract's code runs — do anything  (the "callback")
     3. lender checks: did my 10,000,000 DAI + fee come back?
          ├─ YES → transaction commits. everyone's happy.
          └─ NO  → REVERT the whole transaction. step 1 never happened.

Because step 3 can undo step 1, the lender takes no risk. If you fail to repay, the loan is erased along with everything you did with it. The money was only ever “yours” inside a transaction that is guaranteed to leave the lender whole. This is a primitive that only a deterministic, atomic state machine can offer — it is impossible in a world where money moves in irreversible real-time steps.

The consequence is stark: for the length of one transaction, anyone is as rich as the deepest liquidity pool on the network. Capital stops being a barrier to entry for an attack. You do not need to own ten million dollars to wield ten million dollars for a few milliseconds of block-building time.

Under the hood — the callback that makes it work

A flash loan is implemented as a call with a callback into the borrower’s contract, wrapped in a balance check. Stripped to its essence, the lender looks like this:

function flashLoan(uint256 amount) external {
    uint256 balanceBefore = token.balanceOf(address(this));

    token.transfer(msg.sender, amount);          // 1. hand over the funds

    IBorrower(msg.sender).onFlashLoan(amount);   // 2. run the borrower's code

    uint256 balanceAfter = token.balanceOf(address(this));
    require(balanceAfter >= balanceBefore + fee, "not repaid"); // 3. or revert
}

Everything the attacker does happens inside onFlashLoan, in step 2, while holding the borrowed funds. The require in step 3 is the atomic guillotine: if the balance did not return, the whole call tree — including the transfer in step 1 — is rolled back by the EVM. No trust, no risk, purely structural. That is the same “all or nothing” that lets the reentrancy check-effects pattern work, used here for a benign purpose that becomes the engine of an attack.

The manipulation template

Now combine the two facts. A cheap oracle reads a spot price that anyone can move; a flash loan lets anyone move it enormously for one transaction. The result is the single most-repeated exploit in DeFi’s history, and it fits in five steps — all inside one atomic transaction:

   ══════════════ ONE ATOMIC TRANSACTION ══════════════
   1. FLASH-BORROW  a huge amount of token A (say 50,000 ETH), no collateral.

   2. SKEW THE ORACLE  dump all of it into the DEX pool the victim trusts.
        pool was:  100 ETH / 200,000 DAI   → price 2,000
        now:      50,100 ETH / ~400 DAI    → price ~0.008   (ETH looks worthless)
      ...or buy it all up to make ETH look priceless — whichever the exploit needs.

   3. EXPLOIT THE VICTIM  call the protocol that reads THAT pool as its oracle.
        - borrow against ETH now priced absurdly high, or
        - liquidate / mint / redeem at the distorted price for free value.

   4. REPAY THE LOAN  reverse the swap and hand back the 50,000 ETH + fee.

   5. KEEP THE PROFIT  whatever the victim mispaid in step 3 is yours.
   ═════════════════════════════════════════════════════

The elegance — from the attacker’s side — is total. There is no price risk: because it is one atomic transaction, the market never moves against them between steps. There is no capital requirement: the flash loan supplied the ammunition. And the victim contract did nothing “wrong” by its own logic — it read a price and acted on it faithfully. The bug is not in any single line; it is in the trust placed in a manipulable number.

A useful way to see it: the attacker briefly makes the victim contract’s model of the world false, extracts value against that false model, then restores the world before the transaction closes so no one else ever saw the distortion — except in the receipts, after the money is gone.

It actually happened — bZx, February 2020

In mid-February 2020, an attacker hit the bZx lending protocol using a flash loan in one of the first widely-publicized incidents of its kind. They flash-borrowed ETH, used part of it to open an oversized position that pushed the price on a thinly-traded Uniswap-sourced price source that bZx trusted, and exploited the resulting mispricing — netting on the order of a few hundred thousand dollars in a single transaction. Days later, on 18 February 2020, bZx was hit again by a similar oracle-manipulation pattern for a comparable sum.

The lesson landed hard on the whole industry: bZx’s own accounting code was not obviously broken. It was defeated through its oracle — it trusted a spot price on a pool shallow enough for one flash-loaned trade to move. This pair of attacks is widely treated as the moment “flash loan attack” entered the standard vocabulary.

It actually happened — Harvest Finance, October 2020

On 26 October 2020, Harvest Finance, a yield aggregator, lost roughly US$24–34 million (reported figures vary) to the same template at larger scale. The attacker used flash-loaned funds to distort the price of stablecoins inside Curve pools that Harvest used to value deposits, then repeatedly deposited and withdrew from Harvest’s vaults — each cycle minting or burning shares at a manipulated valuation and skimming the difference — before restoring the pools and repaying. It was not a bug in Harvest’s share math per se; it was, once again, trusting an on-chain spot price that a flash loan could bend.

Defenses: making a price expensive to move

Every defense against this attack attacks the same weak point: the price was cheap to move within one transaction. Make it expensive — in capital, in time, or in trust assumptions — and the exploit stops paying.

Defense 1 — Time-weighted average price (TWAP)

The flash-loan attack lives and dies inside one transaction in one block. A time-weighted average price neutralizes exactly that. Instead of reading the spot ratio right now, the oracle reports an average of the price over a window — say the last 30 minutes’ worth of blocks.

   spot price (attackable):      read reserves THIS instant  ── one trade moves it
   TWAP (resistant):    average of price across many blocks  ── one block can't move the AVERAGE

   to bend a 30-min TWAP, the attacker must hold the price distorted
   for 30 minutes of real blocks — not one atomic transaction — during
   which arbitrageurs trade against them and the position bleeds.

Uniswap v2 introduced a TWAP mechanism by accumulating a running price * time sum on-chain; any contract can read two snapshots and divide by the elapsed time to get the average. Because a flash loan lives for a single transaction, it cannot influence a multi-block average meaningfully — to move a TWAP an attacker must sustain the distorted price across many blocks, with real capital exposed the whole time, while arbitrage bots profit by pushing it back. That sustained cost is the point.

TWAP is not free of trade-offs. It is laggy by construction: in a genuine, fast market move, a TWAP reports a stale price, which can itself be dangerous (a real crash the oracle hasn’t caught up to). And it is only as safe as the depth of the pool underneath it — a TWAP over a shallow pool is still cheaper to move than one over a deep one.

Defense 2 — Deep and multiple liquidity sources

The manipulation math is a function of pool depth. Moving a pool with 100 ETH of liquidity by 50% costs a trivial trade; moving a pool with 100,000 ETH by the same amount requires flash-borrowing (and paying fees on) a fortune, and eats slippage that can wipe out the attack’s profit. So a first, blunt defense is: only read prices from deep pools, and never from a token’s shallowest market.

Better still, read from several independent sources and combine them (e.g. take a median). To move a median of five deep venues, an attacker must move a majority of them simultaneously within one transaction — multiplying the required capital and slippage until the attack is uneconomic. Manipulation resistance is, at bottom, about making the price a function of more money than any flash loan can profitably wield.

Defense 3 — Decentralized off-chain oracles (Chainlink)

The most common answer in production is to stop deriving the price from any single on-chain pool at all, and instead consume a price computed off-chain and delivered on-chain by a decentralized oracle network such as Chainlink.

   many independent node operators, each reading many exchanges off-chain
        │        │        │        │        │
        ▼        ▼        ▼        ▼        ▼
     price₁   price₂   price₃   price₄   price₅   (from Coinbase, Binance, ... )
        └────────┴───┬────┴────────┴────────┘
                     ▼
             aggregate (e.g. median)  ── one bad/manipulated node can't move it
                     ▼
        write to an on-chain "price feed" contract  ── contracts read THIS

A network of independent operators each pulls prices from many real exchanges, they aggregate the values (so one lying or manipulated node can’t swing the result), and they post the agreed price into an on-chain price feed contract that any protocol can read cheaply. Because the price reflects a volume-weighted average across the whole global market — not one pool’s instantaneous ratio — a flash loan against any single DEX pool doesn’t touch it. To move a mature aggregated feed you would have to move the real global market price, which no atomic transaction can do.

The cost is a different kind of trust. You are no longer trusting only the EVM’s determinism; you are trusting the honesty and liveness of the oracle network — its operators, its aggregation, its update cadence. Feeds update on a “heartbeat” or a price-deviation threshold, so between updates the on-chain number is slightly stale. And you are trusting an external system that, unlike the base protocol, can have its own bugs, downtime, or governance. You have traded a cheap, attackable, fully trustless read for an expensive, robust, partially-trusted one.

By the numbers — why depth is the whole game

Take a Uniswap-style pool with the invariant x * y = k, holding x = 100 ETH and y = 200,000 DAI, so k = 20,000,000 and the spot price is 2,000 DAI/ETH. Suppose an attacker flash-borrows DAI and buys 50 ETH out of the pool.

   before:  x = 100 ETH,   y = 200,000 DAI,   k = 20,000,000
   buy 50 ETH → new ETH reserve x' = 50
   invariant: x' * y' = k  →  y' = 20,000,000 / 50 = 400,000 DAI
   DAI paid in = y' − y = 400,000 − 200,000 = 200,000 DAI
   new SPOT price = y' / x' = 400,000 / 50 = 8,000 DAI/ETH   ← 4× distortion!

A single trade quadrupled the pool’s reported price. Now scale the pool up 1,000× — x = 100,000 ETH, y = 200,000,000 DAI — and buying the same 50 ETH barely moves the ratio at all. The attack’s leverage is inversely proportional to depth: 10× the liquidity means ~10× the capital to achieve the same distortion, and more slippage lost to fees. That single relationship is why “just use a deep pool” and “aggregate many sources” are real defenses, not hand-waving.

The architect’s lens

The price oracle is the seam where a blind on-chain world computer touches external reality, so it earns the lens.

• Why does it exist? Because the EVM is deliberately blind to everything off-chain — it has no way to fetch a price — yet DeFi contracts constantly need to know what things are worth. An oracle is the bridge that puts an external fact into on-chain state a contract can read.
• What problem does it solve? It lets a contract make value-dependent decisions — how much you can borrow, when to liquidate, what a share is worth — using a number sourced from the outside world, without the contract itself needing to reach outside.
• What are the trade-offs? A cheap oracle (a single pool’s spot ratio) is fully trustless but manipulable in one atomic transaction; a robust oracle (TWAP, deep/multiple sources, or an off-chain network like Chainlink) resists manipulation but adds latency, gas cost, staleness, and external trust assumptions. You are choosing where on the cheap-vs-robust curve to sit.
• When should I avoid it? Avoid a naive spot-price oracle whenever the value it reports gates real funds and the underlying pool is shallow — that is the exact configuration bZx and Harvest were drained through. If a protocol doesn’t need an external price at all, don’t introduce one; every oracle is new attack surface.
• What breaks if I remove it? Lending, liquidations, synthetic assets, and most of DeFi stop working — a contract with no price feed cannot tell whether a loan is under-collateralized. But remove it carelessly (or wire in a manipulable one) and you don’t lose the feature, you lose the funds: the contract keeps running, faithfully, on a lie an attacker fed it.

Check your understanding

1. Why can’t a smart contract simply fetch the price of ETH from an exchange’s API itself? What must it do instead?
2. What exactly makes a flash loan possible on Ethereum but impossible in traditional finance? Name the one property that lets the lender take zero risk.
3. Walk the five-step manipulation template in your own words, and explain why the attacker faces neither price risk nor a capital requirement.
4. A protocol reads its price from a single Uniswap pool’s spot reserve ratio. Explain why switching that to a 30-minute TWAP defeats a flash-loan attack, and name one downside of the TWAP.
5. Both a deep-pool TWAP and a Chainlink-style off-chain feed resist manipulation. What kind of trust assumption does the off-chain feed add that the fully on-chain TWAP does not, and what do you gain in exchange?

Show answers

1. The EVM is deliberately blind to everything off-chain — there is no opcode to open a network connection, so a contract cannot call an exchange API. It can only read on-chain state: its own storage, other contracts’ exposed values, and block fields. So it must read the price from an oracle — some on-chain contract or mechanism that has put an external fact into on-chain state. The cheapest such source is a DEX pool’s spot reserve ratio.
2. Atomicity: an Ethereum transaction happens completely or not at all. The lender hands over funds, runs the borrower’s callback, then checks the funds returned — and if they didn’t, the entire transaction (including the original transfer) is reverted by the EVM as if it never happened. That undo is what lets the lender take zero risk, so no collateral or trust is needed. Traditional finance has no “undo the whole thing” step because money moves in irreversible real-time events.
3. (1) Flash-borrow a huge amount with no collateral. (2) Skew the oracle by dumping/buying it all against the shallow DEX pool the victim trusts, distorting the spot price. (3) Exploit the victim contract, which reads that distorted price and lets you borrow / liquidate / mint at the wrong value. (4) Repay the flash loan (reverse the swap) plus fee. (5) Keep the profit the victim mispaid. No price risk because it’s all one atomic transaction — the market can’t move against the attacker mid-way; no capital requirement because the flash loan supplied the money.
4. A flash loan lives inside a single transaction in a single block, so it can move the spot price only for that instant. A 30-minute TWAP reports the average price over many blocks, and one block’s distortion barely moves the average — to bend the TWAP the attacker would have to sustain the distorted price for 30 minutes of real blocks with real capital exposed, while arbitrageurs trade against them. Downside: a TWAP is laggy — during a genuine fast market move it reports a stale price, which can itself be dangerous (and it’s only as strong as the depth of the pool beneath it).
5. The off-chain feed adds trust in the oracle network itself — the honesty, liveness, aggregation, and update cadence of its independent node operators — which is an external system that can have its own bugs, downtime, or governance, and whose posted price is slightly stale between updates. In exchange you get a price that reflects the whole global market rather than one pool’s instantaneous ratio, so no single-pool flash loan can move it; you’ve traded a cheap, fully-trustless-but-attackable read for an expensive, robust, partially-trusted one.