Skip to content
DFUHL Docs
LearnStart here4 pages
How these docs workFoundationHow the site is organised by what you came to do, how every page runs from first principles to engineering detail, and where every fact comes from.Hyperliquid in five minutesFoundationHyperliquid is a set of financial primitives and protocols that combine into one financial system. Build a financial system from nothing, and each Hyperliquid protocol takes its place in it.The house of finance, layer by layerFoundationHyperliquid drawn as a house: one consensus, two engines joined by two bridges, an accounts layer, six financial pillars, a distribution layer that pays others to build, and Hyperliquid itself on top.Traditional finance, pillar by pillarFoundationEvery part of Hyperliquid has a traditional finance counterpart, and each analogy breaks in a specific place that shows what is actually new.
LearnFirst principles5 pages
Why Hyperliquid runs on its own chainFoundationHyperliquid built its own chain so that order books, margin and matching run fully on chain, in one consensus order, fast enough to trade on and with no off-chain book.One chain, two execution environmentsFoundationHyperCore holds the markets as native state and the HyperEVM runs contracts; one HyperBFT consensus orders both, joined by precompiles and CoreWriter.What an on-chain order book actually meansFoundationEvery order, cancel and fill is a transaction ordered by consensus and executed by every node, so the book is public chain state, not a private database.Ordering, finality and fairnessPractitionerHyperBFT gives every honest node one ordered list of committed rounds, a committed block is final, and each block runs cancels before GTC and IOC orders.HYPE: what the token doesFoundationHYPE pays HyperEVM gas, secures consensus, discounts fees, bonds deployers, backs borrowing, and is what the Assistance Fund converts fees into and burns.
LearnConsensus and validators4 pages
HyperBFTPractitionerHyperBFT is Hyperliquid's HotStuff-derived proof-of-stake consensus: stake-weighted validators commit rounds that every honest node executes in the same order.Validators and delegationPractitionerValidators run HyperBFT, ranked by stake; delegators choose them, pay commission, earn nothing while one is jailed and face no automatic slashing yet.Staking HYPE, rewards and the unstaking queueFoundationStaked HYPE is delegated to validators for compounding rewards and fee discounts; getting it back to spot takes a 7-day queue on mainnet.Running a nodeExpertA non-validating node follows consensus and writes every committed transaction, fill, order status, book change and HyperEVM block to local disk.
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.
LearnResearch5 pages
What one HyperEVM transaction can and cannot doExpertOne HyperEVM transaction can read HyperCore and emit a perp order and an outcome operation, but it only enqueues them, so the legs are not atomic.Options on the borrow rateExpertA research track priced the HyperCore USDC borrow rate with HIP-4 scalar bands, listed them on somebody else's perp, and found owning the perp does not pay.Composable creditExpertA research track tokenised HyperCore lending positions as HyperEVM ERC20s, proved a contract can supply on testnet, and found the vault must be a queue, not a wrapper.Collateral underwritingExpertA research track found the protocol refuses a deployer stake posted by somebody else, and rebuilt underwriting as two-of-two co-custody of the deployer's own bond.Where the chain and the docs disagreeExpertEvery place where measured behaviour on Hyperliquid contradicts the official docs: what the docs say, what was measured, the sample and the covering page.
LearnFor the press4 pages
Start here: press and analystsFoundationFor people writing about Hyperliquid: what it is, how to measure and name it correctly, and the stories behind the numbers.Measuring Hyperliquid: volume, open interest, usersFoundationPublic Hyperliquid figures disagree mostly because each counts the same fills differently; a number means something only with its rows and units.Common misconceptionsFoundationTwelve common claims about Hyperliquid that the official docs or on-chain measurement contradict, each with what is true and where it is explained.Naming and style guideFoundationWrite HyperCore, HyperEVM, HyperBFT, CoreWriter and HIP-1 to HIP-4 exactly, never shorten HyperCore to one word, and do not cite a HIP-5, because none exists.
LearnWhat Hyperliquid is and how it works
Start here
First principles
Consensus and validators
HyperCore
Research
For the press
TradeMarkets, margin and risk
Start here
Trading fundamentals
Perpetuals
Spot
Outcome markets
Accounts and credit
Advanced trading
Incentives
BuildApps, bots and contracts
Start here
Build on HyperCore
Build on the HyperEVM
DeployLaunch and run markets
Start here
The HIPs
Deploy markets
ReferenceEvery number, action and term
Look up
Protocol tables

HyperBFT

Practitioner

HyperBFT is Hyperliquid's HotStuff-derived proof-of-stake consensus: stake-weighted validators commit rounds that every honest node executes in the same order.

HyperBFT decides the order of every transaction on Hyperliquid. Every node must hold the same balances, books and fills, so all must agree on one ordered list while some validators are slow, offline or dishonest. HyperBFT guarantees that as long as a quorum of stake is honest.

It is Hyperliquid’s own: a custom algorithm the docs call a variant of HotStuff, on a networking stack built from the ground up, optimised for end-to-end latency (request sent to committed response).

Say 300M HYPE is staked in total. A round commits when validators holding more than 200M sign it. Any two such quorums overlap by more than 100M, a third of the stake, so conflicting rounds can both commit only if that overlap signs both.

Consensus orders, execution follows

Section titled “Consensus orders, execution follows”
Transaction gossiped by nodes Round over 2/3 of stake signs Committed same order everywhere Executed height +1 if not empty HyperCore HyperEVM HyperEVM block only when one is due
Consensus decides the order; execution follows it. Both environments execute from the same committed list.
  • Quorum: any set of validators holding more than 2/3 of total stake. Double-signing is the docs’ example of slashable behaviour, but no slashing is automatic yet.
  • Round: a bundle of transactions with a quorum’s signatures. Once certain conditions are met it is committed, and all honest nodes agree on the ordered list of committed rounds.
  • Height: the execution block number, which rises only on rounds with at least one transaction.
  • Jailing: validators may vote to jail a peer that answers consensus messages without adequate latency or frequency. On a quorum of votes it leaves consensus and its delegators earn nothing; it can unjail once fixed, within on-chain rate limits. Jailing is not slashing, which the docs reserve for provably malicious behaviour.

Validators produce blocks in proportion to stake. The mempool and consensus logic know which transactions touch the order books, so the protocol can sort cancels ahead of GTC and IOC orders in each batch (ordering).

A HyperEVM block is built only on the first L1 block in each interval, after that L1 block (execution order).

The numbers

Section titled “The numbers”
Parameter Value Context
Commit quorum more than 2/3 of total stake any such set of validators
Finality 1 block “one-block finality” for HyperCore actions
Time to commit usually 2 blocks pipelined consensus
Consensus batches per block usually 1 to 2 sorting happens per batch
Priority window 70 ms the docs say this usually corresponds to 1 block
Epoch 100,000 rounds, about 90 minutes mainnet; validator set and stakes fixed within it
Active validator set top 27 by stake
Validator self-delegation 10,000 HYPE, locked 1 year
End-to-end latency median 0.2 s, 99th percentile 0.9 s order from a co-located client
Throughput about 200,000 orders per second execution, not consensus, is the bottleneck
HyperEVM blocks small every 1 s (3M gas), big every 60 s (30M gas) built inside L1 blocks
Node state snapshots every 10,000 blocks written by any node

What commit means for your orders

Section titled “What commit means for your orders”
  • The API answers only after commit, so the response is final.
  • Most end-to-end latency is the API trip, mempool entry and the 2-block commit. The docs say sequencing is far less noisy.

Following consensus from code

Section titled “Following consensus from code”
  • Keep three counters apart: rounds (consensus steps), height (execution blocks, skipping empty rounds) and HyperEVM block numbers (one series shared by small and big blocks). A contract reads the L1 block number from precompile 0x809 (l1BlockNumber).
  • A node writes every committed block, and a state snapshot every 10,000 blocks, to disk: paths are on running a node.
  • Measured on testnet, small HyperEVM blocks arrive every 0.95 to 1.00 s, as documented.
  • The docs give properties, not a full specification. Don’t assume HotStuff’s leader rotation, timeouts or message formats apply unchanged.

Reading the headline claims precisely

Section titled “Reading the headline claims precisely”
  • “One-block finality” and “commit in 2 blocks” are both true. A committed block is never reversed; reaching commit takes 2 blocks because consensus is pipelined.
  • Stake changes wait for the epoch. The validator set and consensus stakes are fixed within an epoch, so a delegation changes consensus weight only from the next one. Rewards use each epoch’s minimum balance.
  • One headline, two nouns. The HyperCore overview says about 200,000 orders per second; another page says up to 200,000 transactions per second. It is one figure.
  • Guarantees are conditional on honest stake. The docs point to the 7-day unstaking queue as the window to penalise a large-scale attack, by slashing or social-layer mechanisms.

For who holds the stake, see Validators and delegation; for how it enters and leaves, see staking.