What an on-chain order book actually means

An order book is the list of resting offers to buy and sell. A crossing order matches the best opposite price, earliest first. On Hyperliquid the orders, every change to them and the priority rule are chain state, so you can check all of it.

HyperCore does not use what the docs call the crutch of off-chain order books. Your order is a transaction like any other.

Every order takes the same path

1. You sign an order. An API server forwards it to a node, which gossips it into HyperBFT consensus.
2. Validators with more than 2/3 of stake commit the round, usually 2 blocks later, and every node executes it at the same position.
3. Execution checks margin (perps), then matches in price-time priority or rests the order. Price must be a whole multiple of the tick size, size of the lot size.
4. The API server returns the result from the committed block: a median 0.2 s after you sent it, from a co-located client.

Cancels, fills and liquidations take the same path. Within a block, cancels are sorted ahead of GTC and IOC orders: see ordering and matching.

Nobody matches in private. Every node computes the same book, so no operator can fill an order the chain did not sequence, or reorder fills afterwards.

The book is public down to the order. A node can build an L4 snapshot (every order at every level, with id and time) and update it from order statuses. These, like raw book diffs, name the address behind each change.

The numbers

Parameter	Value	Context
Orders supported	about 200,000 per second	mainnet, per the docs; execution is the bottleneck
Consensus headroom	millions of orders per second	what the docs say consensus and networking can reach once execution keeps up
End-to-end latency	median 0.2 s, 99th percentile 0.9 s	order from a geographically co-located client to committed response
Example cancel or ALO latency	about 380 ms end to end	quoted in the latency guide
Time to commit	usually 2 blocks	pipelined HyperBFT
Consensus batches per block	usually 1 to 2	orders are sorted within each batch
Send-time variation for predictable ordering	under 10 ms	per the latency guide
Gas per order	0	trading fees still apply
Node output	about 100 GB of logs per day	default settings

What it means for your orders

• Every resting order is public and attributable: anyone with a node sees your size, price and queue position.
• A cancel sent alongside someone’s aggressive order almost always executes first. The docs frame this as protecting makers from toxic flow.
• A resting perp order is margin-checked again at match time, at that moment’s prices.
• A fill in the API response is final.

Reading the full book from code

• WebSocket l2Book aggregates by price level. The per-order book needs your own node: an L4 snapshot from a state file, then the order status and raw book diff streams.
• Historical fills and L1 transactions are published as bulk data.
• The older node_trades format does not match the API; node_fills does.

How to read the speed figures

• Latency is not comparable with a centralised engine. It includes the API server, mempool and commit. The docs say sequencing is far less noisy.
• Time can be bought. Priority fees move some orders earlier.
• Throughput is capacity, not traffic.

For who goes first inside a block, see Ordering, finality and fairness. For why the book is chain state at all, see Why Hyperliquid runs on its own chain.