MASTR · CRYPTO & WEB3
Oracles and liquidation: when a price becomes an instruction
A number becomes dangerous when a contract uses it to decide borrowing capacity, settlement or liquidation.
Chapter text and technical graphics are in English. Navigation is available in seven languages.
Which price does the contract use, and what can move it?
A chain does not observe the outside world by itself
A contract can verify computation from inputs it receives, but the market price of another asset is not automatically a native fact of the chain. An oracle supplies a representation of that information. The representation may aggregate several venues, use an average over time or depend on reporters and update rules. The method matters because an apparently precise number can be stale, thinly supported or measured for the wrong asset.
Freshness is part of correctness
A feed’s decimals, units, update timestamp and supported market are not decorative metadata. A consumer that reads the wrong precision or accepts an old answer can make a bad decision even if the oracle network behaved as specified. Some feeds update on a deviation threshold or heartbeat rather than every second. An application needs explicit handling for unavailable, delayed or implausible observations.
Borrowing turns price into permission
If collateral is valued at 1,000 and the allowed loan-to-value is 70%, a simplified model permits borrowing up to 700. If the relevant collateral price is inflated, the same rule may authorise excessive borrowing. If the price falls rapidly, the position may become eligible for liquidation. The exact threshold, bonus and execution are protocol-specific. A correct rule applied to a bad input can still create a loss.
Liquidation can affect the next price
Selling collateral can move a thin market. That movement may reduce the value of similar collateral elsewhere and trigger more liquidations. This feedback is different from a claim that every liquidation is manipulation. The research question is whether market depth, oracle construction and risk parameters together could absorb the event. Include failed liquidations and remaining debt, not only successful keeper transactions.
Trace the full dependency
Find the actual feed or adapter used by the contract, not only the brand named in a presentation. Record administrative overrides, fallback feeds, sequencer checks where relevant and changes since the reviewed code version. A price taken from a market the attacker can cheaply influence requires a different analysis from a robust external aggregate. No single oracle logo answers that question.
Worked example
A hypothetical collateral feed shows 10 dollars while the only executable market has fallen to 6. A loan can look sufficiently collateralised in the application and still leave a shortfall if liquidators can realise only the lower price. The discrepancy is about observable inputs and execution, not merely the displayed ratio.
Questions to take away
- Read the feed address and timestamp.
- Check units, decimals and fallback rules.
- Model the sale of collateral into actual depth.