Crypto · Advanced · 11 min read

Oracles: the price a contract believes

Distinguish market prices from contract inputs and analyze stale, thin or mismatched reference data.

An oracle aggregates several external price observations before a smart contract uses the result; stale inputs remain a risk.
Original educational illustration. No live prices or performance claims.

The boundary between code and observation

A smart contract can apply arithmetic consistently while using a poor input. An oracle supplies information that the contract cannot independently infer from its own execution state, such as an external market price. Ethereum’s oracle documentation explains this boundary between blockchain execution and outside data. The important question is not only whether a feed updates, but what the updated number means.

A price may represent one venue, an aggregate, a time-weighted observation or a redemption value. These definitions answer different questions. An exchange execution price describes a transaction; a reference price supports a rule; a redemption value describes a claim under specified conditions. They should not be substituted without explanation.

Inspect the feed specification

For a fictional lending market, write down the asset pair, units, decimals, update conditions and fallback behavior. Determine whether a value is quoted in dollars, another token or a base asset. A correct-looking number scaled by the wrong decimal factor can be catastrophically wrong when interpreted by another component.

Also examine freshness. A feed that updates only after a deviation or elapsed interval can legitimately differ from a fast-moving order book. The application must decide how old is too old and what to do then. Pausing new borrowing can protect against stale data while still leaving existing positions exposed to subsequent price updates. There is no universally harmless fallback.

Liquidity is part of input quality

A thin market can produce a last-trade price that is unrepresentative of a large executable transaction. Aggregating venues may reduce dependence on one venue, but common ownership, shared liquidity or synchronized outages can limit the independence gained. A time average smooths short-lived moves while introducing delay. Every design exchanges one set of weaknesses for another.

Consider a token with a quoted price of $10 but only $5,000 of nearby buying depth. Valuing $1 million of collateral at that marginal price does not show that liquidators can realize $1 million. The oracle can report its defined reference correctly while the risk model overestimates recoverable proceeds. Data quality and liquidation capacity are related but distinct problems.

Stress both sides of a collateral ratio

A collateralized loan depends on the collateral price and the debt price. Borrowing a token described as stable does not make its dollar value mathematically fixed. If debt becomes more expensive to repurchase while collateral falls, the position deteriorates from both directions. Model those changes separately instead of holding one side constant by habit.

Suppose collateral is worth $12,000, debt is 6,000 units initially worth $1 each, and the hypothetical liquidation threshold is 75%. The initial health ratio is 1.50. If collateral drops 25% to $9,000 while debt units rise to $1.10, the ratio becomes $9,000 × 0.75 ÷ $6,600, approximately 1.023. A seemingly comfortable buffer is almost exhausted.

Research the integration, not just the provider

A reputable data provider does not guarantee that an application selects the correct feed, handles unavailable values or checks timestamps properly. Review the application documentation, relevant audits and parameter decisions. In a paper exercise, trace an ordinary price update and then a missing update through the calculation. State where you lack evidence rather than filling gaps with confidence.

A useful monitoring plan distinguishes a market move from a feed anomaly. Compare the stated reference with independent observations and the feed’s expected update policy. Differences deserve investigation, not automatic trading. This lesson is about understanding contract behavior and operational risk, not exploiting an input weakness or assuming that apparent mispricing can safely be captured.

For additional practice, calculate the same collateral position using three reference assumptions: the last reported feed, a current executable bid and a stressed sale price. Label each clearly. The resulting range is not a confidence interval; it is sensitivity to valuation choices. Its purpose is to reveal which price definition drives the conclusion and where additional liquidity evidence is needed.

Correct units are as important as a fresh timestamp

Imagine a collateral token quoted at 0.02 units of another asset, while the reference asset is worth $2,000. The implied collateral price is $40. If an integration reads 0.02 as a dollar value, or combines prices from mismatched units, the error is not a subtle market disagreement: it is a different calculation. Feed decimals, quote currency and the precise asset being represented belong in the specification.

In a paper review, label every intermediate number with a unit. Write “reference asset per collateral token” multiplied by “dollars per reference asset” and check that the reference unit cancels. Then change one feed while holding the other stale. The exercise shows how a composed dollar price can inherit two measurement times and two sets of assumptions. A plausible-looking final number is not proof that either input was handled correctly.

Distinguish an asset’s market quote from an accounting or redemption rate as well. A receipt might represent 1.04 underlying units while trading at a discount to that claim. Using 1.04 as if it were an immediately executable sale price answers the wrong question for a liquidation. The appropriate valuation method depends on the protocol’s design, not merely on which number is easiest to obtain.

A pause trades one risk for another

Price-feed users need rules for stale or anomalous observations. Chainlink’s documentation makes the integration responsibilities explicit: selecting a feed is not the same as deciding how an application should behave when data or infrastructure conditions change. Review the feed-selection and integration considerations.

Suppose a fictional lending system stops new borrowing when its price is too old. That can prevent loans against an unreliable valuation. But if it also stops liquidations while collateral is falling, debt may become harder to recover before the system resumes. If it continues liquidating with the old price instead, some accounts might be treated using a stale valuation. “Pause on error” therefore needs an explanation of what pauses, what continues and how recovery works.

Create a timeline with the last accepted observation, the market move, the stale-data threshold and the first valid update. Ask which actions are possible in each interval and who can change those rules. The objective is not to find a setting that eliminates every risk. It is to see the trade-off clearly enough that a normal-day health indicator is not mistaken for a guarantee under stress.

A QUICK CHECK

Did the idea stick?

Can an accurately reported reference price still overstate liquidation proceeds?

General education, not a trade recommendation. Examples simplify real markets. Check the exact contract, costs and rules of any product before using it.
Next: DeFi composability: mapping the dependencies beneath yield →