How does Hyperliquid run a fully on-chain order book? · Jumpstart Blockchain
How does Hyperliquid run a fully on-chain order book?
Hyperliquid builds the exchange into the chain: HyperCore runs order books, margin, liquidations and the HLP vault as native logic under HotStuff-style HyperBFT, with HyperEVM alongside under the same consensus.
Most on-chain exchanges are AMMs because a central limit order book (CLOB) is too expensive to run inside a general-purpose smart contract platform. Every place, cancel and modify is a state write, market makers update quotes many times per second, and the matching engine has to be deterministic and fast. Hyperliquid solves this by building the exchange into the chain itself. Its state machine, HyperCore, holds the order books, margin accounts and liquidation engine as native protocol logic, and a general-purpose HyperEVM runs alongside it under the same consensus, HyperBFT.
Why a CLOB needs a purpose-built chain
On Ethereum or a typical L2, an order book contract runs into three problems:
Problem
Why it hurts a CLOB
Gas per action
Market makers cancel and replace quotes constantly. Paying EVM gas for each update makes tight quoting uneconomic.
Block time and finality
Quotes go stale while waiting for inclusion. Makers widen spreads to cover the risk.
Ordering control
The block producer decides which cancels and fills land first, which invites MEV against resting orders.
Hyperliquid's answer is to make orders, cancels and liquidations native actions rather than contract calls. They are processed by compiled matching code, not interpreted bytecode, and the chain is tuned for one workload. The documentation states a median end-to-end latency of about 0.2 seconds for a co-located client, and throughput on the order of 200,000 orders per second on mainnet. Treat those as the project's own figures.
HyperBFT consensus
HyperBFT is a variant of HotStuff, the leader-based BFT family that also influenced Diem's LibraBFT and Aptos. Validators take turns proposing blocks, the rest vote, and a block is final once more than two-thirds of stake has signed. There are no reorgs and no confirmation counts: once an order fill appears in a committed block, it is final.
Validators are chosen by staked HYPE. The active set has been small, around two dozen validators for much of 2025 and 2026, with expansions announced over time. Becoming a validator is permissionless in principle (it requires a self-bond of HYPE), but the node software is distributed as a signed binary rather than open source, and a large share of stake has historically been delegated to validators run by the Hyper Foundation. Those two facts are the core of most decentralization criticism.
HyperCore: the exchange as the state machine
HyperCore is where trading happens. Its main components:
Order books. Spot and perpetual markets, matched in price-time priority. Prices must be multiples of the market's tick size and sizes multiples of its lot size. Orders can be good-til-cancel, immediate-or-cancel, or add-liquidity-only (post-only).
Margin. Accounts trade perps with cross or isolated margin, collateralized mainly in USDC. Margin is checked against the mark price, which blends the book with an oracle price that validators publish from external exchange prices.
Liquidations. When an account's equity falls below maintenance margin, the protocol first tries to close positions by sending market orders to the book. If the book can't absorb them, the position is taken over by a liquidator vault.
HLP (Hyperliquidity Provider). A protocol-run vault that users can deposit into. It market-makes across listed markets and backstops liquidations, earning trading PnL and liquidation profits, and absorbing losses when a liquidated position moves against it.
Token and market listing. HIP-1 lets anyone deploy a spot token through a gas auction. HIP-3 lets builders who stake a large amount of HYPE deploy their own perp markets, with the deployer responsible for oracle and parameter choices.
One design detail matters for makers. Within each block, Hyperliquid sorts actions by type before execution: first actions that don't send GTC or IOC orders (including post-only quotes), then cancels, then actions that send GTC or IOC orders. Within each group the proposer's order is kept. The effect is that a maker's cancel in the same block as an incoming taker order gets processed first, which reduces the "stale quote sniping" that plagues on-chain books and lets makers quote tighter.
Anyone can read the full book from the public info API:
Trading actions are signed with an Ethereum-style key and posted to the /exchange endpoint, which forwards them to validators for inclusion.
HyperEVM and how the two sides interact
HyperEVM is an EVM execution environment secured by the same HyperBFT consensus, not a separate chain or rollup. It uses HYPE for gas and chain ID 999, so standard tooling (Foundry, Hardhat, viem, MetaMask) works. EVM blocks are produced in a dual-block pattern: small, frequent blocks with a low gas limit for fast transactions, and larger blocks roughly once a minute for heavy deployments. The docs describe the current limits as conservative.
The bridge between the two sides is built in:
Direction
Mechanism
EVM reads Core
Read precompiles starting at 0x0000000000000000000000000000000000000800 return positions, balances, oracle and mark prices, and similar state
EVM writes Core
The CoreWriter system contract at 0x3333333333333333333333333333333333333333 takes encoded actions, such as placing orders or moving funds
Assets
Tokens move between Core and EVM through system addresses, so a spot token on Core can have a linked ERC-20 on the EVM side
A contract can place an order on HyperCore for its own Core account. Actions are a version byte, a 3-byte action ID, and ABI-encoded fields; prices and sizes are scaled by 10^8:
Two caveats. CoreWriter calls only emit an action; the order is validated and executed by HyperCore afterwards, so a successful EVM transaction does not mean the order filled. And order actions sent from CoreWriter are deliberately delayed by a few seconds on-chain, so EVM contracts can't use this path to gain a latency edge over direct traders. Look up asset indexes from the info API's metadata rather than hard-coding them.
Risk events
An integrated exchange concentrates risk in the protocol itself, and Hyperliquid has had public stress tests.
March 2025, ETH position unwind. A trader opened a very large leveraged ETH long, withdrew most of the margin, and let the position be liquidated. HLP took over the position and closed it at a loss of a few million dollars. Hyperliquid responded by lowering maximum leverage on major assets and tightening margin rules for withdrawals from open positions.
March 2025, JELLY. A trader opened a large short on the thinly traded JELLYJELLY perp, then the token's spot price was pushed sharply higher on other venues. The short was liquidated, HLP inherited it, and as the price kept rising HLP's unrealized loss grew into the low tens of millions of dollars. Validators then voted, within minutes, to delist the JELLY perp and settle all positions at about $0.0095, roughly the price at which the attacker's short had been opened, rather than the manipulated market price. HLP ended the episode with a small profit, and the Hyper Foundation said it would reimburse affected users apart from flagged addresses.
The market outcome was contained, but the response showed that a small validator set can intervene in a market and choose a settlement price after the fact. Supporters called it a necessary circuit breaker; critics said it looked more like an exchange operator's decision than neutral protocol rules. Hyperliquid later adjusted open-interest caps and listing and liquidation parameters.
The general lessons: low-liquidity markets with external oracle prices are manipulable, a shared backstop vault concentrates losses, and "on-chain" does not automatically mean "no discretionary control".
Summary
Layer
Role
HyperBFT
HotStuff-style BFT, one-block finality, small stake-weighted validator set
HyperCore
Native order books, margin, oracle and mark prices, liquidations, HLP vault
Block ordering
Non-taker actions, then cancels, then GTC/IOC orders, which favors makers
HyperEVM
EVM under the same consensus, chain ID 999, dual small and large blocks
Core and EVM link
Read precompiles, CoreWriter actions (orders delayed a few seconds), linked tokens
Hyperliquid's order book is fully on-chain because the chain was designed around it. For developers, the practical model is simple: trade through HyperCore's API for speed, build composable logic on HyperEVM, and treat the link between them as asynchronous.
