Oracle Latency: How a Price Feed Decides Who Gets Liquidated

Smart contracts have no access to outside data. A protocol that needs to know what an asset is worth must be told, by an oracle, and it then treats that figure as truth. Whether the figure is current, whether it can be moved by someone with capital, and how long it lags reality are not incidental details — they determine who is liquidated and when.

Why feeds are not continuous

Publishing a price on-chain costs a transaction, so no feed updates constantly. Instead, oracles use two triggers.

A deviation threshold publishes when the price has moved more than a set percentage since the last update. A heartbeat publishes after a fixed interval regardless. Between updates, the protocol is using a stale figure, and how stale depends on which threshold is set and how volatile the market has been.

This is not laziness; it is a cost trade-off, and the parameters are published. A feed with a wide deviation threshold is cheap to operate and can be meaningfully behind during a fast move. A tight one is expensive and closer to real.

The practical consequence for a borrower is that liquidation runs on the oracle's clock rather than the market's. A position can appear safe on an exchange while already being liquidatable on-chain, or the reverse, and the difference is a parameter you can look up.

The manipulation surface

If a feed derives its price from a market, moving that market moves the feed.

The cheapest version uses a venue with thin liquidity as the source. Someone with enough capital — borrowed for a single transaction if the design permits — pushes the price on that venue, the oracle reports it, and a protocol acts on a figure that reflects the attacker's trade rather than the market. Positions get liquidated, or the attacker borrows against collateral valued at a price they created.

The defences are all about making the reported number harder to move. Aggregating across many venues means an attacker must move all of them. Using a volume-weighted average over time means a momentary spike does not register. Requiring multiple independent reporters to agree removes any single compromised source.

Time-weighted averaging is the most common on-chain defence, and it has a cost worth naming: an average over a window is by construction behind the market, so a design that resists manipulation is also a design that liquidates late. Resistance and responsiveness trade directly against each other, and there is no parameter that gives both.

Aggregation, and what it hides

A feed that aggregates across venues is stronger, and it introduces a question about what happens when the venues disagree.

During a genuine dislocation, prices diverge. An aggregate is then a number that exists nowhere — no venue is trading there, and a liquidator acting on it may be unable to execute at anything close. That is how liquidations execute at prices that leave a shortfall even when the aggregate looked adequate.

The other failure is a source going stale or offline. A well-built feed detects this and excludes the source; a poorly built one keeps averaging in a frozen number and reports something increasingly detached from reality.

Checking a protocol's exposure

• Which oracle does it use, and is that documented on-chain rather than in a blog post.
• What are the deviation threshold and heartbeat for the specific asset you hold, since parameters differ per feed.
• Is the price aggregated across venues, and is it time-weighted — and if so, over what window.
• What happens if the feed stops updating: does the protocol pause, or keep acting on the last figure.
• Is there a fallback source, and who decides when to switch to it.

Oracle configuration is one of the parameters an appointed risk manager answers for, and mispriced feeds recur in our incident ledger of DeFi risk managers.

What it means for a borrower

The operational conclusion is that a safety buffer measured against the market price is measured against the wrong number. The figure that matters is the one your protocol will act on, and it can differ from the market by more than a comfortable margin during exactly the conditions that put a position at risk.

Borrowers who size their buffer from what they see on an exchange, and who are liquidated while that exchange showed them safe, have usually met a deviation threshold rather than bad luck.