A perpetual future has no expiry date that pulls it back to spot, so the venue needs another way to know where the underlying asset trades elsewhere. That outside reference is usually called an oracle or index price. It can drive funding, often feeds the mark price, and through the mark can reach margin checks and liquidation. This guide explains what an oracle does, why perpetual venues and DeFi lending both rely on external prices, where oracle risk tends to hide, and which questions to ask before trusting a backtest, stop or liquidation estimate.
What an oracle does, and why a venue needs one
A matching engine knows its own book: its bids, asks and trades. It cannot see the same asset’s price on other spot markets unless a process brings that information in. An oracle is that process. It collects outside observations, applies a rule, and publishes a value that other logic then consumes. The background on blockchain oracles describes the general pattern: an outside source, an oracle step, a recorded input, and a rule that acts on it. A recorded value shows that the input was published, not that it matched the outside market.
For a perpetual, the need is structural. Without expiry, the contract is held near spot mainly by funding payments, and funding needs a definition of “spot.” The funding-rate mechanics depend on that reference. If a venue used only its own last trade, a thin or one-sided book could move the very number meant to discipline it. An external reference is an attempt to anchor the contract to a broader market.
DeFi lending meets the same problem from a different side. A lending protocol runs on a smart contract’s fixed rules, which cannot browse a website; it needs a price input to decide whether a borrower’s collateral still covers a loan. The moving parts of DeFi, from interfaces to wallets to contracts, all inherit whatever that input says. When the input is wrong or late, collateral can be liquidated automatically under rules that do not pause for a human review.
How one venue documents its oracle
Hyperliquid’s oracle documentation shows the components concretely. It says validators publish a spot oracle price for each perpetual asset every three seconds. Each validator computes a weighted median of spot mid prices from external venues, with Binance weighted 3, OKX and Bybit weighted 2, and Kraken, KuCoin, Gate.io, MEXC and Hyperliquid spot weighted 1 each. The clearinghouse then takes a stake-weighted median of the validators’ submissions.
The source scope depends on the asset. Where primary spot liquidity is on Hyperliquid, the page says external sources are excluded until there is sufficient liquidity; where primary spot liquidity is elsewhere, with BTC as its example, Hyperliquid spot is excluded. The documentation says the oracle is used to compute funding and is an input to the mark price, which handles margining, liquidations and TP/SL triggers.
Hyperliquid’s robust-price page summarizes the oracle as a weighted median of centralized-exchange prices that does not depend on Hyperliquid’s own market data, and says its robust prices aim to minimize the risk of market manipulation. How the mark combines the oracle with book and external perpetual prices, and how mark differs from last trade, is covered in the mark, index and last price comparison; this article stays with the oracle itself. These rules describe one venue as documented when checked. Other venues use different source lists, weights and cadences, and any venue’s documentation can change.
Where oracle risk hides
A median of several sources is designed so that one bad input does not dominate. That reduces some risks without removing them.
- Stale inputs. Every published value has an age. If a source stops updating or the publishing process pauses, consuming logic may keep using the last value while markets move. Ask what the system does when an input is old or missing.
- Thin source markets. A median of illiquid books can still move. If several constituents are thin at once, during an outage at a large venue or for a newly listed asset, the reference may reflect very little real trading.
- Manipulation. If someone can move enough constituent markets, briefly and for less than they gain from the contract that reads the price, the reference becomes a target. Weighting, medians and exclusions raise that cost; they do not make it unlimited.
- Update cadence. A value refreshed every few seconds is a series of snapshots, not a continuous line. Between updates the outside market can move, and a threshold check sees only the published points.
- Method changes. Constituents can be added, removed or excluded under documented conditions, as the asset-dependent rule above shows. A long historical series may span more than one method.
The contract that consumes the price matters as much as the feed. Before relying on any protocol, reading an audit’s actual scope helps separate what was reviewed from what was assumed.
A fictional example: one thin source, then three
Suppose a simplified reference takes an equal-weight median of five fictional spot venues. All numbers are invented for illustration.
| Source (fictional) | Spot mid, case 1 | Spot mid, case 2 |
|---|---|---|
| Venue A | $100.00 | $100.00 |
| Venue B | $100.04 | $100.04 |
| Venue C | $99.98 | $94.10 |
| Venue D | $100.06 | $94.20 |
| Venue E (thin book) | $94.00 | $94.00 |
| Median | $100.00 | $94.20 |
In case 1, one thin venue prints $94.00 after a single large sell. The median stays at $100.00, while a simple average would fall to about $98.82. In case 2, three of the five venues are thin at the same moment and all print near $94. The median moves to $94.20, because the outliers are now the majority.
Now add time. If the last published value is $100.00 from 30 fictional seconds ago and the sources have since moved to $97, a rule reading it acts on a price that no longer describes the market. Neither case reconstructs any venue’s method.
Which price did your test, stop or liquidation use?
Many disagreements about “what happened” come down to mixed price fields. Before interpreting a result, work through this list:
- Name the venue, the exact contract and the field: last trade, oracle or index, or mark.
- For each decision in a test, including entry signal, stop trigger, liquidation check, funding accrual and P&L, record which field drove it. On Hyperliquid, funding uses the oracle and liquidation uses mark; a chart candle usually shows trades.
- Check the asset’s current source list, weights and exclusions, and whether they changed across your test window.
- Note the update cadence and timestamps. An hourly candle cannot show which reference crossed a threshold first within the hour.
- Record what the venue does when an input is stale or missing, or mark that question unanswered.
- Keep the trigger separate from the fill. A threshold crossed on one field is not an execution at that price; see how liquidation proceeds after a breach.
SuperQuant’s included examples use synthetic hourly data. They are not exchange oracle, mark or index series, and the engine does not reproduce any venue’s oracle method or verify live execution. When a result depends on which reference was used, state it as a model assumption rather than a fact the data can confirm.
Keep learning
For the lending side of the same problem, the DeFi topic hub collects guides on contracts, collateral and price inputs. For the derivatives side, continue with perpetual futures explained. This is educational research context, not investment advice.