HyperLiquid: How It Actually Works

A backend engineer's guide to BFT consensus, on-chain CLOBs, dual-block architecture, and what makes HL genuinely different.

01. The Right Mental Model#

HyperLiquid is not a DEX built on a chain. It's a chain built around a DEX.

Every other DEX is smart contracts on top of a general-purpose blockchain — Ethereum, Solana, Arbitrum. The blockchain doesn't know or care it's running a trading application. HyperLiquid flipped this completely. They built a Layer-1 blockchain whose sole purpose is to be an exchange.

Key Framing: HyperBFT, HyperCore, and HyperEVM are not separate chains. They are three components of the same single chain — each responsible for a different layer of work, sharing the same state, committed under the same consensus round.

02. What is BFT Consensus?#

Imagine 20 computers that need to agree on the same value. Some might be crashed, faulty, or deliberately malicious. BFT (Byzantine Fault Tolerance) answers: how do you reach agreement when you can't trust all participants?

Core guarantee: consensus works as long as fewer than 1/3 of participants are faulty. With 21 validators (HL's current active set), you can tolerate up to 7 bad actors.

BFT Round Structure:

// One consensus round, ~0.1 seconds

Round 1 — Propose
  Leader validator proposes a block of transactions

Round 2 — Prepare (first vote)
  All validators: "I received and validated this proposal"
  Collect 2/3+ before proceeding

Round 3 — Commit (second vote)
  All validators: "I saw that 2/3+ agreed"
  Collect 2/3+ commit messages → block is FINAL

// Once committed: irreversible. No reorgs. No forks.

The two-phase voting prevents split-brain. The first phase establishes "did everyone see the same proposal?" The second: "does everyone know that everyone agreed?"

HyperBFT specifically is built on the HotStuff family (same as Facebook's Diem). Two critical improvements:

1. Linear message complexity via threshold signatures — O(n) instead of O(n²)
2. Pipelining — multiple consensus rounds run simultaneously like an assembly line

Result: 0.1s median finality.

The Trade-off: 21 validators means only 7 colluding validators could halt the chain. The March 2025 JELLY incident demonstrated that validators can and will manually intervene. Not censorship-resistant in the Bitcoin sense.

03. The Three-Layer Stack#

┌─────────────────────────────┐
│        HyperEVM             │  EVM-compatible smart contracts
│    (February 2025)          │  Runs Solidity with direct HyperCore access
├─────────────────────────────┤
│        HyperCore            │  The exchange engine
│  On-chain CLOB + Risk       │  Native L1 actions. No gas. 200K orders/sec
├─────────────────────────────┤
│        HyperBFT             │  Consensus engine
│  ~0.1s BFT rounds           │  All three layers share the same consensus
└─────────────────────────────┘

Restaurant analogy:

• HyperBFT = the kitchen ticket system — takes orders, decides sequence, doesn't cook anything
• HyperCore = the chef — processes tickets and executes trades
• HyperEVM = the specialty pastry station — same kitchen, same ticket system, handles different work

One restaurant. Three roles. The shared state is what makes everything possible — when HyperCore updates BTC's price, HyperEVM sees it instantly in the same block. No oracle query. Same state.

04. AMM LP vs CLOB#

Most DEXs use AMMs because building a CLOB on-chain at speed was considered impossible. An AMM is elegant: two reserves, one formula, no order book needed.

// AMM: x * y = k

Pool: 10 ETH + 20,000 USDC  →  k = 200,000

You buy 1 ETH:
  New ETH in pool  = 10 - 1 = 9
  New USDC needed  = 200,000 / 9 = 22,222
  You paid         = $2,222  (not $2,000)
  Slippage         = $222  ← the cost of the formula

The AMM LP is always the passive counterparty. They don't set prices — the formula does. This creates impermanent loss: as prices move, the AMM automatically sells the winning asset and buys the losing one.

A CLOB has professional market makers actively posting bids and asks, competing on spread. This is how NYSE, CME, and NASDAQ work.

HyperLiquid solves the cold-start problem with HLP (protocol-native market-making vault) and HIP-2 (automatic liquidity provisioning for spot tokens).

05. Before HyperEVM#

Before February 2025, HyperLiquid was a pure trading platform — no smart contracts, no programmability.

The Strategic Logic: Build the killer app first, then open the platform. HyperLiquid had a liquid, battle-tested exchange before inviting external developers. The opposite of most chains.

06. Two Block Types, One Chain#

HyperBFT produces one continuous stream of consensus rounds. Within that stream, two types of execution blocks are produced at different cadences.

BFT Rounds (continuous, every ~0.1s):

Round 1   → HyperCore Block (trading txs execute)
Round 2   → HyperCore Block
Round 3   → HyperCore Block
...
Round 10  → HyperCore Block + EVM Fast Block  ← every ~1s
Round 11  → HyperCore Block
...
Round 600 → HyperCore Block + EVM Slow Block  ← every ~1min
            // Both committed under same BFT signature
            // Atomic — one commits, both commit

Why the split? Traders need fast confirmation for order cancellations during a flash crash. Developers deploying a contract don't care if it takes 60 seconds. Different latency requirements get separate block streams.

Fast EVM Blocks  (~1s, 2M gas limit)
  → Order cancellations, simple transfers, lightweight calls

Slow EVM Blocks  (~1min, high gas limit)
  → Contract deployments, complex DeFi interactions

HyperCore Blocks  (every BFT round with txs)
  → Order placements and cancellations
  → Liquidations and funding payments
  → Native L1 actions (no EVM, no gas)

This is fundamentally different from L1+L2 rollups where the L2 periodically posts state roots and there's a finality gap. HyperLiquid's block types were never separate chains — they commit together in the same BFT round.

CoreWriter (EVM → HyperCore): When an EVM smart contract sends an order via the CoreWriter system contract (0x333...333), the action appears in the next HyperCore block — one-block lag for writes. But reads via precompiles are instant and reflect current HyperCore state.

07. Block Numbering & Sequencing#

HyperCore and HyperEVM maintain completely independent block counters:

HyperBFT Round Number
  → Master clock. Increments every ~0.1s.
  → Not all rounds produce execution blocks.

HyperCore Height
  → Increments only when a BFT round has trading txs.
  → Currently: ~901,000,000+ (18 blocks/sec × 2 years)

HyperEVM Block Number
  → Increments on EVM cadence (~1s).
  → Standard eth_blockNumber — EVM tooling compatible

Block 901M on the HyperCore explorer is expected — 18 blocks/second × 2 years ≈ ~1.1B blocks. Ethereum at 1 block/12s is at ~22M after 9 years.

Why separate counters? If they shared a block number, EVM tooling (MetaMask, ethers.js) would see enormous gaps (1, 11, 21...) since HyperCore produces ~10x more blocks. EVM tooling assumes sequential block numbers and would break.

08. Separate RPCs, Separate Protocols#

HyperCore API (Custom REST):

// Read
POST https://api.hyperliquid.xyz/info
{ "type": "orderbook", "coin": "BTC" }

// Write: signed EIP-712 action
POST https://api.hyperliquid.xyz/exchange
{ "action": { "type": "order", ... }, "nonce": 1234567890, "signature": "0x..." }

// No gas. No contract address. No ABI. Pure HTTP.

HyperEVM RPC (Standard Ethereum):

Endpoint: https://rpc.hyperliquid.xyz/evm

eth_blockNumber, eth_getBalance, eth_call, eth_sendRawTransaction

// MetaMask, ethers.js, wagmi, viem — all just work.

For trading: you never touch the EVM RPC. Your order goes as a native HyperCore action via the custom REST API — which is why integrating HyperLiquid feels exactly like integrating a CEX API.

09. Running Your Own Node#

HyperBFT, HyperCore, and HyperEVM are not three separate programs. They're three modules compiled into one binary — hl-node.

# HyperCore only (default) — lean, trading-focused
./hl-node --chain Mainnet

# HyperCore + HyperEVM RPC (opt-in flag)
./hl-node --chain Mainnet --serve-eth-rpc

Always maintained: All account USDC balances, full order book, all open positions, HIP-1 token balances, validator stake records.

With --serve-eth-rpc additionally: EVM state trie, contract bytecode, EVM account nonces and balances, event logs.

Practical decision:

• Trading bot? Run without --serve-eth-rpc. Full HyperCore API available. No EVM overhead.
• DeFi dApp builder? Add the flag. Full EVM RPC available.

Even without the flag, your node still processes EVM blocks from the BFT stream — it needs to apply CoreWriter actions into Core state. It just doesn't maintain the full EVM state trie.

The Architecture in One Sentence#

One chain. One BFT consensus stream as the master clock. Two execution environments sharing state atomically — HyperCore for native trading operations and HyperEVM for smart contracts — each with its own block counter, its own RPC protocol, and its own optional service within the same binary.

Every other multi-environment architecture solves coordination with bridges, message passing, or optimistic rollups — all introducing latency, trust assumptions, and sync complexity. HyperLiquid eliminates the coordination problem by having nothing to coordinate. Both execution environments commit inside the same BFT round, under the same signature.

That architectural simplicity — achieved through significant consensus engineering — is what enables the shared-state features: atomic hedging, real-time prices in contracts, cross-margin between protocols — structurally impossible on any other platform today.