Skip to content
LearnHyperCore8 pages
HyperCore overviewFoundationHyperCore is where Hyperliquid's order books, margin, clearing and settlement run as native protocol state, applied by every validator in one order.The clearinghouse: one margin enginePractitionerHyperCore's clearinghouse holds balances and positions and checks margin on every trade; in standard mode each perp dex has its own balance and cross margin.The order book and matchingPractitionerEach HyperCore asset has one on-chain book matched in price-time priority, with cancels and post-only orders sequenced ahead of orders that take liquidity.Oracles, mark prices and robust price indicesPractitionerValidators publish perp oracle prices every 3 seconds; the mark price used for margin and liquidation is a median that no single book or venue can move.Quote assets: USDC, USDH, aligned and permissionlessPractitionerAny token can become a HyperCore quote asset if its issuer stakes 200k HYPE against a peg and liquidity standard; aligned issuers also share reserve yield.Vaults: HLP, protocol vaults, user vaultsFoundationA vault pools depositors' USDC into one HyperCore account run by one strategy; HLP is the protocol vault that makes markets and performs liquidations.Multi-sig accountsPractitionerHyperCore can make any account a native k-of-n multi-sig with no smart contract, but CoreWriter stops working for it and its HyperEVM side keeps the old key.API servers and how state reaches youPractitionerAPI servers follow a node, keep a local copy of HyperCore state, answer reads from it, and reply to a transaction only once it executes in a committed block.

HyperCore overview

Foundation

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.

  1. You sign the order and send it to an API server.
  2. HyperBFT commits it, and every validator applies it in the same order.
  3. The book matches it and both accounts update in that same execution. There is no separate settlement step.
  4. 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.

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

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.

HyperEVM general-purpose contracts chain id 999 on mainnet HyperCore order books clearinghouses oracle and mark prices staking, vaults, lending HIP-1, HIP-3, HIP-4 markets CoreWriter action, executed later precompile read, latest block only assets through system addresses
Reads are synchronous but only at the latest block; writes are queued and never report back.
  • Read through precompiles at 0x800 to 0x814.
  • Write through CoreWriter. An order (action 1) carries price and size as 1e8 times 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.
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.