Pricing: BBO precompile

BBO precompile technical implementation

A perpetuals exchange needs prices for two jobs: filling trades and deciding when positions are liquidated. On most chains that means trusting an oracle operator, or a slow and costly decentralised feed, or living with the risk that whoever posts prices can freeze the market by stopping.

HyperEVM offers another way. HyperCore, the layer that runs Hyperliquid’s order books, is readable from HyperEVM contracts through read precompiles: system contracts at fixed addresses that return live HyperCore state, prices included. The Exchange uses the BBO precompile at 0x000000000000000000000000000000000000080e. Given a Hyperliquid asset index (on mainnet, BTC is 0 and ETH is 1), it returns the current best bid and best offer of that perpetual:

(ok, bid, ask) = HyperCore.readBbo(assetIndex, precompileGas)   // a static call with a fixed gas allowance
require(ok && bid != 0 && ask != 0 && ask >= bid)                // an empty or crossed book reverts

The fill price is the midpoint, rounded down, in the market’s raw price units (the Hyperliquid price times a per-market scale):

price = (bid + ask) / 2

That is the whole pricing pipeline. All reads in a block see the same snapshot, and the Exchange caches each market’s price for the rest of the call, so every open, close and liquidation of a market in a block uses the same price.

What this gives up, and what it gives us

The cost is plain: only markets that already trade on Hyperliquid’s book can be listed. Nothing that Hyperliquid does not list can be traded here.

In return, pricing has no off-chain part at all. The BBO is HyperCore state, verified by Hyperliquid’s consensus like the balances on its ledger. There is no price signer and no oracle committee; the price the Exchange sees is the price Hyperliquid’s market makers quote in that block, readable by any contract.

No deviation breaker

Someone can try to move Hyperliquid’s book for a block, by widening the spread or shifting the inside quote, and trade here against the distorted mid. That is a real risk of using the BBO directly.

A read reverts the trade when the precompile does not answer, when either side of the book is zero, or when the book is crossed; a locked book, with bid equal to ask, is accepted. The contracts also contain price guards: a maximum spread, and bands that compare the mid with Hyperliquid’s mark and oracle prices. They are switched off in the deployed configuration, which keeps fills at the raw mid by design, so a manipulated but non-zero, uncrossed book is accepted. The deadband, the impact curve, the per-side open-interest caps and the relayer’s short hold on closing young positions (6 seconds) reduce some payoffs and limit exposure; they do not make manipulation unprofitable or bound the LP’s loss. See Risk.

The one real-time lever: retiring a market

One admin action over prices takes effect at once: retiring a market. The guardian calls pauseMarket(instrumentId), which stores the current BBO as a frozen bid and ask and marks the market retired. From then on:

• new opens on that market revert;
• closes and liquidations still work, at the frozen book instead of the live one.

Retirement is permanent: nobody, not even the owner, can reopen that market id. If a retired market could come back, holders could choose between the frozen price and the later live one, and the moment of reopening would itself become something to game. If the market returns, it is listed again under a new id. The frozen price lets an operator stop a market without stranding its positions: they can still be closed at a price that made sense when the operator stepped in. Retirement is per market, so a problem with one asset does not stop the others.

If the book itself is unusable or untrustworthy at that moment, the guardian can instead retire the market at Hyperliquid’s mark or oracle price (retireMarket with that source); a failed BBO read falls back to the mark automatically. The guardian can also pause trading on every market with setTradingPaused(true), without freezing prices: closes and liquidations keep using the live book, and only the owner can lift the pause.

Apart from the market keeper’s open-interest caps and trade minimums, the off-hours keeper’s choice between the two payout curves, and the governance multisig’s removal of a builder, every other admin action (fees, impact parameters, listings, keepers, upgrades) is an owner action through the timelock.