HyperCore overview
HyperCore is where Hyperliquid's order books, margin, clearing and settlement run as native protocol state, applied by every validator in one order.
When you trade on Hyperliquid, your orders, balances and positions live in HyperCore. They are chain state, not an app’s records, so every interface sees the same account and the same book. An app adds a fee only with your approval (builder codes).
An order is matched and settled in one execution
Section titled “An order is matched and settled in one execution”Say you buy 1 ETH of perps from a co-located client.
- You sign the order and send it to an API server.
- HyperBFT commits it, and every validator applies it in the same order.
- The book matches it and both accounts update in that same execution. There is no separate settlement step.
- The reply reaches you after commit: median 0.2 s, 99th percentile 0.9 s.
That’s the docs’ principle: no off-chain order books, one order for everyone (why it matters). Think of an exchange’s matching engine and clearing house in one, except that consensus, not an operator, sets the order.
What HyperCore holds
Section titled “What HyperCore holds”HyperCore and the HyperEVM are two execution environments on one chain, both secured by HyperBFT (why). HyperCore’s state changes only through signed actions. It holds:
| Component | What it holds | Owning page |
|---|---|---|
| Order books | One book per asset, matched in price-time priority | The order book |
| Clearinghouses | Perp balances, positions and margin; spot token balances and holds | The clearinghouse |
| Oracle | Validator-published prices, and the mark price built from them | Oracles |
| Staking | HYPE delegated to validators | Staking |
| Vaults | HLP and user vaults, each trading as one account | Vaults |
| Lending | Supplied and borrowed balances | Borrowing and lending |
| Multi-sig | Accounts controlled by several keys | Multi-sig accounts |
| Market deployment | HIP-1 tokens, HIP-3 perp dexes, HIP-4 outcome markets | What a HIP is |
Reaching HyperCore from code
Section titled “Reaching HyperCore from code”From outside the chain, /exchange takes signed actions, /info serves reads and /ws streams. Start with your first request.
From a HyperEVM contract there are three paths, none a function call that returns a result.
- Read through precompiles at
0x800to0x814. - Write through CoreWriter. An order (action 1) carries price and size as
1e8times the human value; the HTTP API takes decimal strings. - Move tokens through system addresses.
Keep matching, margin and liquidation in HyperCore; put custom logic, tokenised positions and composability on the HyperEVM. Four rules catch contracts out:
- A refused CoreWriter action does not revert: gas is spent, nothing happens.
- Precompiles read only the latest block; there is no historical HyperCore state from the HyperEVM.
- A contract must be a HyperCore account before the EVM block that uses CoreWriter.
- Multi-sig accounts cannot use CoreWriter.
The numbers
Section titled “The numbers”| Parameter | Value | Source |
|---|---|---|
| End-to-end order latency, co-located client | median 0.2 s, 99th percentile 0.9 s | official docs |
| Throughput | about 200k orders per second; execution is the bottleneck | official docs |
| Oracle publication | every 3 seconds, by validators | official docs |
| Consensus batches per block | usually 1 to 2 | official docs |
| Unstaking queue | 7 days | official docs |
| Authorised users per multi-sig account | at most 10 | official docs |
| USDC decimals | 8 on HyperCore, 6 on the HyperEVM | measured |
For balances, positions and margin, see The clearinghouse. For the environment on the other side, see The HyperEVM.