Oracles: the most common single point of failure in DeFi

A smart contract has no access to anything outside its own chain. It cannot see an exchange, a bank balance or the time of day on another network, so any protocol that needs an external fact depends on a process that writes that fact into on-chain state. That process is an oracle, and because lending, derivatives, stablecoins and structured products all read prices the same way, an oracle is the dependency most likely to be shared by everything that fails at once.

The designs, and what each one trades away

• Push feeds. A set of reporters signs prices and writes them on chain on a heartbeat, or whenever the price has moved by more than a deviation threshold. Everything downstream reads a stored value for free. The stored value is by construction stale between updates, and the deviation threshold defines exactly how stale it may be.
• Pull feeds. Reporters sign prices continuously off chain, and a user submits the signed price along with the transaction that needs it. Updates cost nothing when unused and the price is fresh at the point of use, but whoever chooses which signed price to submit has a degree of selection over the number the protocol will act on.
• Time-weighted averages from an on-chain pool. The price is derived from a decentralized exchange pool's own history, so it requires no external reporter at all. Manipulating a longer average requires holding a distorted price across many blocks, which is expensive, and the same averaging makes the feed lag badly in a fast move.
• Aggregated indices. A median or volume-weighted composite across venues resists a single venue's outage or manipulation, and provides no protection when the venues are correlated because they are all quoting from the same underlying market.

No design removes the tradeoff between freshness and manipulability. A feed that updates instantly reflects whatever just happened, including something an attacker caused. A feed that averages is harder to move and reports the past.

The manipulation arithmetic

The cost of moving an on-chain price is a function of pool depth. Under a constant product curve, pushing the price up by a factor of r requires buying into the pool until the reserve ratio matches, and the trader is left holding the asset at an inflated price; most of the outlay is recovered when the price is pushed back, so the true cost is the round trip's fees and slippage, not the notional deployed.

The payoff is bounded by something else entirely: the size of the position that can be opened against the distorted price. If a lending market will lend against a thinly traded collateral token, the attacker's profit is set by that market's depth, while the attacker's cost is set by the pool's. When those two numbers are far apart, the trade is a matter of execution rather than of capital, and a flash loan removes the capital requirement altogether by borrowing and repaying within one transaction. This is the shape of a large share of the losses in the sector: not a broken cryptographic primitive, but a correct contract reading a price that was true for one block.

Mitigations follow from the same arithmetic. Caps on how much can be borrowed against thin collateral bound the payoff directly. Isolated markets stop the loss from reaching unrelated deposits. Pricing collateral at the lower of several independent feeds removes the single manipulable source. And requiring a price to persist across blocks makes an atomic attack impossible, at the cost of slower liquidations.

A taxonomy of oracle failure

Manipulation is only one branch. The others recur often enough to be worth naming.

• Stale. The reporters stop, or the deviation threshold is never crossed on a low-volatility asset, and the contract keeps using an old number that no longer describes the market. Oracle failure of this kind is silent, because a stored value looks identical whether it is one minute or one week old unless the timestamp is checked.
• Correct but late. In a fast decline the feed is accurate at every update and behind the market between them, so liquidations happen at prices that no longer exist and liquidators refuse to act.
• Right price, wrong asset. A wrapped or receipt token is priced using the underlying's feed on the assumption that they are equivalent. When the wrapper trades at a discount, that assumption is the error, and it typically shows up as a depeg that the protocol cannot see.
• Unit errors. Decimals, denomination in the wrong quote currency, or an inverted pair. These are mundane, and they have caused total losses.
• Governance. The address a protocol reads from is a parameter. Whoever can change it can change every price in the system at once, which makes admin key risk and upgradeability risk oracle questions as much as contract questions.
• Ordering. Because an update and the transactions reacting to it sit in the same block, the right to act first on a new price is valuable, which places MEV and front-running inside the oracle's design rather than outside it.

What can be checked before it matters

Useful questions are specific: how many independent reporters sign a feed and who they are; what the heartbeat and deviation threshold are; whether the price is a broad index or a single venue; whether the contract validates the timestamp and rejects stale data; whether a circuit breaker exists and who can trigger a pause; and whether collateral caps bound the payoff from a successful manipulation. For assets whose price is supposed to be fixed, peg deviation is the direct measure of whether a feed and reality still agree, and the depth behind a price matters more than the price itself, which is why volume relative to value locked is worth reading next to any pool used as a price source.

The incident record classifies past failures by mechanism, including the oracle-driven ones, the risk section lists the feeds protocols depend on, and the data sources page sets out where the prices on this site come from and how they are reconciled, which is the same problem seen from the outside.