Hyperliquid Architecture · The Hyperliquid L1 · 2/8
HyperBFT Consensus
The Consensus Challenge for Trading
For a trading platform, consensus has different requirements than a general-purpose blockchain. You need:
- Low latency — Traders need sub-second confirmation, not 12-second blocks
- High throughput — Many thousands of order actions per second, not just token transfers
- Deterministic ordering — Every validator must see the same sequence of orders and cancels to reach the same book state
How HyperBFT Works
HyperBFT is Hyperliquid's custom consensus algorithm, a variant of the HotStuff family of BFT protocols. The key properties:
Leader-Based Rounds
Consensus proceeds in rounds. In each round a leader proposes a bundle of transactions, and validators vote on it. A round can be committed once it carries signatures from a quorum — validators holding more than 2/3 of total stake. All honest nodes agree on the same ordered list of committed rounds, and each committed round is passed to execution. A round that contains at least one transaction produces a new block.
Leader proposes round → Validators vote
→ Quorum (>2/3 of stake) reached → Round committed → Executed as a block
Pipelining
HotStuff-family protocols pipeline their voting phases, so work on the next proposal overlaps with votes on the previous one. This overlap is a large part of how such protocols reach sub-second confirmation. (Hyperliquid does not publish a detailed specification of HyperBFT's internal phases.)
Order-Book-Aware Ordering
The mempool and consensus logic are aware of order book transactions. Within each block, non-order actions run first, then cancels, then actions that send GTC or IOC orders. Running cancels before new takers gives makers a chance to pull stale quotes.
Validator Set
The active validator set is the top validators by stake (the top 27, per the docs); running a validator node is permissionless. Validators must:
- Self-delegate at least 10,000 HYPE (locked for one year)
- Run high-performance hardware (low-latency networking is critical)
- Respond quickly to consensus messages — validators that lag can be jailed by a quorum vote and stop earning rewards until they fix the issue
Jailing is not slashing. Slashing is reserved for provably malicious behavior such as double-signing, and as of October 2026 the docs state there is no automatic slashing implemented (staking docs).
How It Compares
HyperBFT was designed specifically for order book workloads, with consensus and networking built together with the matching engine. Many other venues adapt general-purpose consensus for trading, or keep the order book outside consensus and only commit fills on-chain.