A liquidation engine does not know the market price. It knows the last price an oracle wrote to the chain, and it liquidates against that. When the two diverge the difference is not a data quality complaint. It is a transfer of value from a borrower to whoever watches the feed more closely.
A stale price is a different number, not a wrong one
Oracle designs usually combine two triggers. A heartbeat publishes on a schedule, and a deviation threshold publishes early when the price has moved far enough from the last update.
Both parameters describe the same thing from different angles, and neither is a promise about the current price. A feed with a twenty-minute heartbeat and a 0.5% deviation threshold will publish steadily through a quiet morning and then hold a price for up to twenty minutes across the one move that matters, because the move happened between heartbeats.
The written price is not wrong. It was correct when it was signed. It is a price from the past used as if it were a price from now.
The threshold matters more than the interval
Most checklists ask for the update interval, because the interval is easy to find. The deviation threshold is the parameter that decides how much price movement can accumulate before the contract hears anything.
A feed that updates every minute on a 2% deviation can sit 1.9% away from the market indefinitely. A feed that updates every fifteen minutes on a 0.25% deviation tracks far more closely, and it costs more to run because every update is a transaction somebody pays for.
That trade-off is why oracle choice is a design decision rather than a procurement one. Cheap feeds on low-volume assets update rarely, and a lending market listing a long tail inherits that thinness.
How a safe position becomes liquidatable
Take a borrower near the maximum loan-to-value, which is where leveraged users sit by construction. The liquidation threshold is a few points above the maximum, so the buffer between opening and being liquidated is deliberately thin.
Now let collateral fall 6% in five minutes and let the feed publish it ten minutes later. Two things fill the gap. The borrower sees a health factor that says they are fine, because the dashboard reads the same stale feed. A liquidator running a faster price source sees a position already underwater and can repay the debt and seize collateral at the stale price, which is higher than the market.
The liquidator’s profit is the bonus plus the staleness. The borrower’s loss is the same amount, and it is larger than the move that triggered it.
The asymmetry runs both ways. A feed lagging a rally overstates collateral, lets borrowers draw more debt than the position supports, and sets up a sharper liquidation when the price snaps back. Latency is biased against the borrower closest to the limit.
Settlement time is a different clock
On a rollup, price freshness and settlement are separate questions. Arbitrum One’s dispute window runs 45,818 blocks, about 6.4 days, per the Ethereum.org L2 directory readings of 1 to 6 October 2026. That is how long a withdrawal takes to become final on the main chain. It says nothing about how fresh the price is on the rollup, and conflating the two is a common error in risk notes.
What matters is where the oracle writes and where the liquidation executes. A feed posting on the rollup is fast, and the residual risk is its own threshold. A feed that depends on a main-chain update which must be relayed gives the rollup’s liquidation engine a delay no fee table mentions (what a sequencer does).
What to check before borrowing near the limit
| What to check | Why it matters | Where to look |
|---|---|---|
| Deviation threshold | Caps how far price can drift before an update | Oracle configuration, not the market page |
| Heartbeat | Longest silence in a quiet market | The same configuration |
| Liquidation threshold vs max LTV | The real buffer before a call | Market parameters |
| Feed count and fallback | One feed is one failure point | Market documentation |
| Liquidator depth | Thin liquidation markets mean bigger discounts | Recent liquidation history |
The first two rows decide whether the price you see is current. The third decides how much room you have.
A market with a stale feed and deep liquidators hurts you precisely. A market with a fresh feed and no liquidators leaves bad debt, and bad debt lands on suppliers through utilisation and rate changes rather than through a single liquidation (how utilisation sets lending rates).
Verdict
Oracle latency is a liquidation parameter. It sets the price at which your collateral can be taken, and it is chosen by people optimising cost per update.
Borrow well inside the limit, and compute the buffer in units of the feed’s threshold rather than your own reaction time. Your reaction time does not enter the contract. The feed’s settings do.
0 comments
No comments yet — ask a question and we will answer it here.