Margin and liquidation read the MARK, never the last print. The mark is the oracle plus a banded, size-weighted book premium — one lot lifted through a thin book cannot move it, which is otherwise a way to liquidate other people.
state root 00000000000000000000000000000000
SHA-256 over a canonical encoding of the live state. A validator replays the block and recomputes this; if it differs, the sequencer lied.
What you are looking at
Every number on this page comes from torihiki, an open reimplementation of the exchange state machine that Hyperliquid keeps closed, running live in a Cloudflare Worker. The book, the fills and the state roots are read from that node as it produces them: prices are integer ticks, matching is price-time priority, and the roots are SHA-256 over a canonical encoding.
It is a sequencer, not a chain. One writer decides the order of transactions; nothing votes and nothing tolerates a Byzantine peer. The node says so in its own /head response. What the sequencer cannot do is lie undetectably — every block it produces can be replayed against the same engine and its state root contradicted.
This page renders with the same pure functions that render it on the server, so the browser and the node never disagree about what a row looks like. When the node is unreachable it says so above rather than freezing on the last good frame — a terminal that silently shows stale prices invites a trade.
3,155,313 ops/sec
Measured matching throughput, 317 ns/op — 15.8x HyperCore's documented 200,000 orders/sec. Execution only; the live node is nowhere near that, and nothing here claims it is.
Sequencer, not consensus
One writer decides the order. Nothing votes. The log is checkable by replay, which is a different guarantee from tamper-evidence and the stronger one.
Signed, replay-proof
Every transaction carries an Ed25519 signature over the chain id, the account, a strictly sequential nonce and every field. Reusing a nonce is refused; signing someone else's account is refused.
No floating point
Every value is an integer inside the range both the JVM and JS represent exactly, so two validators cannot disagree in the last bit.