SKN3X.COM

Oracle risk: where the price comes from

The data source a collateralized position is actually exposed to.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

  • You can name the oracle properties that decide liquidations.
  • You can explain why an oracle error does damage in both directions.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

Core concept

Fact

Three properties decide everything

Source: where does the price come from — a single venue, an average across several, a pool on the same chain? Frequency: how often does it update, and past what deviation? Control: who may write it, and is there a fallback when the source fails? Those three determine when a position is liquidated — not the market price a human sees on a screen.

Risk

A price from a tradable pool is manipulable

If a protocol derives its price from a pool the same transaction can move, the price can be bought. Capital for that is borrowable inside one transaction in DeFi, unsecured, as long as everything is repaid by the end. The defense is not more capital but a source a single transaction cannot move — a time-weighted average, say, or an external network of several reporters.

Interpretation

Too slow hurts as much as too fast

An oracle that updates rarely dampens short-term spikes — and, in a genuine crash, reports collateral values that are too high, so liquidation comes too late and uncovered claims arise. An oracle passing every twitch through liquidates positions on a spike that is gone minutes later. Both are design trade-offs, not faults — but the trade-off must be named, because it decides which scenario the protocol handles worse.

Definitions

Oracle
A mechanism that writes off-chain data into a contract.
Time-weighted average price
A price averaged over a period, so a single transaction can barely move it.
Flash loan
An unsecured loan that must be repaid within the same transaction.

Model

  1. Source — one venue, several, or a pool on the same chain

  2. Aggregation — averaging, weighting, outlier handling

  3. Write — who may, how often, past what deviation

  4. Contract computes — health factor against that value

  5. Liquidation — triggered by the oracle value, not the market

The path from price to liquidation — The human at the screen sees step 1; the position hangs on step 4.

Worked example

The same position, two oracle designs

Collateral market price
falls 22 % in 10 minutes
Oracle X
updates at 0.5 % deviation
Oracle Y
30-minute average

X passes the drop straight through: positions near the threshold liquidate simultaneously, and the sales hit the same falling market. Y reports a markedly higher value over those same ten minutes: few liquidations, but loans against collateral worth less than assumed.

X risks a cascade, Y risks uncovered claims.

Reading: Neither design is the safe one. The question is which of the two scenarios the protocol — and your position in it — handles worse.

Retrieval

What is a collateralized position directly exposed to?
Why is a particularly slow oracle not automatically the safer one?

Exercise on real data

Read what this platform reports about dependencies — and note that the oracle design is not part of it. Record where you would evidence it instead.

Dimension 10: dependencies →

Application

Which three details about the oracle design do you request before your organization posts collateral in a lending market?

Related case studies

Institutional reading

Bank
Would the oracle dependency be recorded as model risk or as counterparty risk?
Insurance
Would a faulty price be an insured event or a market loss?

Metrics in this lesson

Key takeaways

Evidence