Architecture
Understanding Hyperliquid means separating three things that are usually bundled together on other venues: how transactions are ordered, where the order book lives, and where programmable logic runs.
In short
HyperBFT orders transactions and produces blocks in proportion to staked HYPE. Execution splits into HyperCore, which contains the perp and spot order books plus all margin and clearinghouse state, and the HyperEVM, a general-purpose EVM environment on the same chain that can read HyperCore state through precompiles and write to it through CoreWriter.
Hyperliquid is secured by HyperBFT, a variant of HotStuff consensus. As on most proof-of-stake chains, validators produce blocks in proportion to the native token staked to them, and each validator needs a self-delegation of 10,000 HYPE to become active.
The relevant property for traders is finality: an accepted order is final in one block, so there is no ambiguity window in which a fill might be reordered or dropped.
HyperCore holds the matching engine, the perp and spot order books, margin state and the clearinghouse. Crucially, it does not lean on an off-chain book — the documentation calls that 'the crutch of off-chain order books' explicitly. Orders, cancels, trades and liquidations are all state transitions.
HyperCore is also where oracle prices live. Validators publish a weighted median of centralised-exchange spot prices roughly every three seconds, and that oracle feeds both funding and mark price.
The HyperEVM is a familiar general-purpose EVM environment running on the same chain. Contracts there can read HyperCore state through precompiles and act on it through CoreWriter, which is how onchain vaults, tokenised strategies and automated systems interact with the real order book rather than a wrapper.
For builders this collapses a normally awkward boundary: liquidity and accounting live on the same chain, so an EVM contract can hold a position, delegate an agent, or read its own margin without trusting an external relayer.
HyperMirror plugs into two of these primitives. Public HyperCore state provides every candidate trader's verifiable fill history, and Hyperliquid's agent-approval mechanism allows a trade-only signer to place orders on a user's account without any withdrawal or transfer authority.
Neither of those requires trusting HyperMirror with custody. Both are exchange-level features, which is why the model is structurally non-custodial rather than non-custodial by promise.
Methodology
Scoring and replacement are documented in full on How it works and in the Docs (Policy v3). In short: the Elite basket is sticky, emergencies remove a leader immediately, and soft issues accrue at most one strike per UTC day with three strike-days triggering replacement. Read how it works or the documentation for the full table.
Questions
HyperCore is the exchange state: order books, margin, clearinghouse. The HyperEVM is a general-purpose smart contract environment on the same chain that can read and write HyperCore state via precompiles and CoreWriter.
Published figures are a median end-to-end latency of about 0.2 seconds for co-located clients, a 99th percentile of about 0.9 seconds, and roughly 200,000 orders per second of mainnet throughput.
Validators secure the chain under delegated proof of stake, producing blocks in proportion to delegated HYPE, with a 10,000 HYPE self-delegation requirement to become active.
Score-weighted allocation across up to 10 elite Hyperliquid traders, each isolated in its own sub-account. Your funds never leave your account.
Non-custodial · Agent cannot withdraw · Cancel delegation anytime
