Oracle failure: when a protocol reads the wrong price

An oracle failure is any state in which the number a contract acts on differs from the price at which the asset could actually be traded. The consequences are mechanical rather than dramatic: liquidations that should not have happened, positions that should have been liquidated and were not, and new borrowing against collateral that is not worth what the feed reported. Because the contract cannot check the outside world, it has no way to notice that it is wrong.

Why the number has to come from outside

Every node must reach the same result when it re-executes a transaction, so contract code cannot make a network request. Anything the chain does not natively know, including the price of an asset on a venue elsewhere, has to be written into on-chain state by a transaction that someone pays for and someone is trusted to send. An oracle is that arrangement: a set of reporters, a rule for combining their submissions, and a contract that stores the result. Every property of the arrangement is a design choice, and each choice trades cost against the failure it permits.

Designs, and the failure each one invites

• Push feeds. A reporter set writes an aggregated price on a schedule, or whenever the price moves more than a set percentage. The update cadence and the deviation threshold define exactly how wrong the stored value is permitted to be between updates.
• Pull feeds. A signed price is fetched off-chain and submitted with the transaction that uses it, which improves freshness and shifts the question to who signed it and how old the signature is allowed to be.
• Medianized venue prices. Several venue prices are combined, usually by median, which resists one bad source and fails when the venue set is small, when several venues share the same underlying liquidity, or when one thin venue carries as much weight as a deep one.
• On-chain time-weighted averages. A price is derived from an automated market maker over a window, which makes momentary manipulation costly and guarantees the reported price lags a genuine move, which is its own hazard in a fast decline.

Staleness, and the ways it happens

A stale price is the most common failure and the least discussed. Updates stop or slow when the chain is congested and the update transaction is underpriced, when a reporter set has an outage, when a source venue halts trading, or when a layer 2 sequencer is down and no transaction can be included at all. The last case is instructive: when the sequencer resumes, the first transactions to land can be liquidations against prices that moved while nobody could act, which is why several systems add a grace period after downtime. Assets that reference something with trading hours, such as a tokenized instrument, inherit a scheduled staleness every weekend. A contract that does not check the timestamp of the value it reads will treat a two-day-old number as current.

Manipulation: making the reported price genuinely wrong

The second family is manipulation, where the attacker does not falsify the feed but moves the market the feed observes. The cost of doing so is set by the depth of the venues in the source set, not by the size of the protocol relying on it, which is the asymmetry that has produced repeated losses. With a flash loan, the capital required is borrowed and repaid within one transaction, so the constraint becomes depth alone. The most damaging variant is when the manipulated asset is the collateral itself: a trader pushes a thinly traded token upward on the venue whose price the system trusts, borrows against the inflated collateral value, and leaves the protocol holding a bad debt that no liquidation can clear because the collateral was never worth that much. Several well-documented 2022 incidents follow this shape exactly.

When the feed is accurate and the design is still wrong

A third family involves no error in the number at all. A system that prices a wrapped token or a liquid staking receipt at the value of its reference asset is assuming redeemability that may not hold at that moment, since an exit queue or a broken backing can open a gap between the market price and the reference. A system that treats a stablecoin as worth exactly one unit of account will not liquidate anything during a depeg, and will accept new borrowing against collateral the market has already marked down; a system that uses the live market price will liquidate borrowers during a temporary dislocation that later reverses. Both choices are defensible and both have caused losses, which is why the redemption price and the market price are best read as two different questions.

What mitigations look like, and what to check

Mature designs bound the damage rather than promising correctness: multiple independent sources with disagreement thresholds, an explicit maximum age for any value read, caps on total borrowing per asset, isolated markets so a single bad asset cannot reach the main pool, delays between a price update and the liquidation it enables, and a pause for extreme divergence. For a reader assessing a protocol, the checkable questions are which assets are priced, from which sources, how often, with what staleness check, and whether the depth behind those sources is large relative to what can be borrowed against them. On this site, peg deviation tracks stablecoin dislocation and DEX volume to TVL gives a rough sense of how much trading a pool actually supports.

Bridges, covered next, are the other place where a contract acts on an assertion about the outside world. The incidents record and the stablecoin pages show how the failures described here have played out.