Oracle

Also written price oracle, oracle price

A mechanism that puts an outside price where a contract or a matching engine can read it. On a chain it is a feed such as Chainlink or Pyth, written on-chain on a threshold, a heartbeat or a user's request. On a perpetuals venue it is the venue's own reference price, a median of other exchanges' spot prices. Both are reported values with a timestamp, never a live market.

This catalogue uses "oracle" in two senses, and the corpus needs both. A lending protocol liquidates against one, and a perpetuals venue computes funding against another. They share a name and a property: each is a number somebody reported, at a time somebody chose.

How it works

On a chain, a price has to be written before it can be read. A smart contract cannot fetch a web page. It reads storage, so somebody has to put a price there in a transaction, and the design question is who does it and when.

  • Push. Chainlink's data feeds update their answer "when the value deviates beyond a specified threshold or when the heartbeat idle time has passed". Between those events the on-chain value is the last one written, which can sit anywhere inside the threshold from the market. Chainlink tells consumers to check the updatedAt value returned by latestRoundData(), and to "pause operation or switch to an alternate operation mode" when it is older than the application can tolerate.
  • Pull. Pyth publishes prices off-chain every 400 milliseconds and lets "anyone" post an update on-chain. Applications "need to update the on-chain price before reading it"; until somebody does, the stored value is whatever was last posted. Pyth characterises push oracles as typically updating every 10 minutes to an hour, which is a competitor's description and should be read as one.
  • The pool itself. A DEX pool's price is readable on-chain with no feed at all, and it can be moved within one block by whoever orders the transactions. That is why contracts read a time-weighted average instead; getting a DEX pair price covers it.

On a perpetuals venue, the oracle is an internal reference. Hyperliquid's validators publish a spot oracle price for each perpetual every three seconds, computed as a weighted median of spot mid prices on Binance, OKX, Bybit, Kraken, KuCoin, Gate, MEXC and Hyperliquid, weighted 3, 2, 2, 1, 1, 1, 1, 1. The price the clearinghouse uses is then a stake-weighted median of the validators' submissions. It sets funding and is one input to the mark price. On dYdX each validator runs a sidecar pulling prices from oracle providers and exchanges, the block proposer aggregates what they submit, and the result checks collateral, triggers liquidations and fires stop-limit and take-profit orders.

Why it matters here

An oracle price is not any one exchange's price. A funding payment on Hyperliquid or a liquidation on dYdX was computed against a median of several venues, filtered through validators. Checking it against one exchange's chart finds a gap that is the method, not an error. The funding rate and mark price entries follow the same number into the two calculations it feeds. The Hyperliquid SDK and the dYdX clients are where a program reads these values rather than recomputing them.

The timestamp matters more than the value. A push feed's history is a series of updates that happened when the price moved far enough or the heartbeat expired. It is irregular by design: a quiet hour produces one row and a volatile minute produces several. Read it as a step function, the value a contract would have been given until the next write, and not as a sample of the market taken at regular intervals. A pull feed's on-chain history is worse as a price record, because it contains only the moments somebody paid to update it. Anything built from oracle events pulled through an on-chain SQL tool inherits that shape; querying a chain with SQL covers the tooling.

Lending liquidations answer to the oracle, not the tape. A position on a lending protocol is closed when the protocol's oracle says it is under-collateralised, whatever an exchange chart showed at that moment. A liquidation record from a lending market and one from a perpetuals venue are two mechanisms, and watching liquidations keeps them apart.

What an oracle secures is a measure of dependency, not accuracy. DefiLlama publishes total value secured per oracle, defined as the sum of the TVL of every protocol that depends on it, and framed as the potential loss "if that oracle malfunctioned or reported incorrect data". A large figure says many protocols trust the feed. It says nothing about how close to the market the feed has been.

Off-hours, the oracle decides what price means. Assets whose underlying market closes — tokenized stocks, stock-tagged perpetuals — are priced through oracles that must choose between a stale value, a carried-forward one and a model. Aster's card records that its stock perpetuals are priced off an index built partly from the Pyth oracle and smoothed off-hours, and what a tokenized stock is compares what Chainlink and Pyth publish when the exchange is shut.

Where you will meet this

The cards where this changes a decision, then the rest that use the word.

Sources

  1. Data Feeds — deviation threshold, heartbeat and checking updatedAt — Chainlink, read
  2. Pull updates — pull and push oracles compared — Pyth Network, read
  3. Oracle — Hyperliquid, read
  4. Oracle Prices — dYdX, read
  5. Data Definitions — Total Value Secured (TVS, for oracles) — DefiLlama, read

Updated