Hyperliquid HyperBFT: spot vs perp, and sub-accounts

If you read Part 1 of this series, we established a fundamental architectural reality: if you want to build a fully on-chain Central Limit Order Book (CLOB) capable of mathematically rivaling centralized exchanges, you cannot force it into a generic virtual machine. General-purpose VMs carry a massive latency tax because they must dynamically meter gas for every computation. To achieve sub-millisecond finality and handle massive throughput, the order book cannot merely live inside a smart contract, the order book must be the blockchain.

This is exactly the thesis behind Hyperliquid. But knowing why a protocol built a sovereign, dual-engine architecture (HyperCore and HyperEVM) is only half the battle. The real engineering magic lies in how they actually pull it off.

How does a network process 200,000 orders per second without choking on state contention? How do we achieve the deterministic, one-block finality that high-frequency market makers demand? And perhaps most importantly for EVM developers: how do standard Solidity contracts natively interact with a closed, highly-specialized financial state machine without relying on external, lagging oracles?

In Part 2 we go under the hood — dissecting how Hyperliquid HyperBFT achieves deterministic one-block finality, how Spot and Perp accounting differ at the L1 state level, and how sub-accounts enable programmatic risk isolation for trading bots.

The engine room, Hyperliquid HyperBFT and one-block finality

📖 For a high-level overview of Hyperliquid HyperBFT, see What is Hyperliquid? — this section goes deeper into why deterministic finality is a hard requirement for market makers.

To build a decentralized exchange that institutional market makers actually want to use, you have to solve the “finality problem.”

In traditional blockchain environments like Ethereum or its rollups, finality is probabilistic. You submit a transaction, it sits in a mempool, it gets picked up by a block builder, and then you wait for several block confirmations (or in the case of optimistic rollups, a massive challenge period) to be absolutely certain your transaction won’t be reverted in a chain re-org. Even on highly optimized parallel networks like Solana, you are dealing with a layered finality model where leaders can occasionally skip slots, creating micro windows of uncertainty.

For a yield farmer depositing USDC into Aave, a 12-second block time with probabilistic finality is perfectly fine. But for a market maker algorithmically updating their quotes 1,000 times a second across dozens of assets, uncertainty is money loss. If a bot sends an API request to cancel an order, it needs to know immediately and irrevocably that the order is off the book before quoting the next price. If there is even a fractional risk of a block re-org bringing that cancelled order back from the dead, the market maker will get arbitraged.

This strict requirement for deterministic execution is why Hyperliquid had to build its consensus layer from scratch.

Hyperliquid utilizes a custom consensus algorithm known as Hyperliquid HyperBFT, which was heavily inspired by Hotstuff and its successors. Rather than relying on probabilistic models, HyperBFT operates on a deterministic, one-block finality model. Once the validator set agrees on a block, the state transition is permanent. There are no chain re-orgs and no waiting for epoch finalization.

Because the underlying consensus guarantees immediate permanence, every single order, cancel, trade, and liquidation executed by the network happens transparently with this exact one-block finality inherited directly from HyperBFT.

This architecture practically eliminates the predatory MEV dynamics that plague EVM automated market makers. On generic chains, block builders can actively hold your transaction in the mempool, observe your slippage tolerance, and inject their own trades before and after yours to sandwich your execution. On Hyperliquid, the sub-millisecond block times and strict sequencing of Hyperliquid HyperBFT force transactions into the matching engine at breakneck speeds, fundamentally protecting the integrity of the Central Limit Order Book (CLOB) from traditional block-reordering attacks.

The architecture of accounting, spot vs. perps

Before a transaction can even hit that blazing-fast matching engine we discussed, the L1 has to know exactly what kind of assets it is managing. This brings us to the fundamental differences in how Hyperliquid handles state.

The protocol’s core execution layer, HyperCore, includes fully onchain perpetual futures and spot order books. However, from an engineering perspective, Spot and Perps require vastly different accounting architectures.

Spot Mechanics: Asset Transfers Spot trading is mathematically straightforward. If you place a limit order to buy 1 Spot BTC using USDC, and that order is matched, the resulting state transition is essentially a two-way asset transfer. The network deducts USDC from your balance and credits you with 1 BTC. You now hold the underlying base asset. In an EVM context, this is equivalent to a simple ERC-20 transfer function updating two balances. On Hyperliquid, it is a native state mutation handled instantly within the node’s memory.

Perp Mechanics: Native Collateral Management Perpetuals are a completely different beast. When trading perps, you aren’t transferring base assets, you are trading synthetic contracts. This means the L1 state machine is strictly tasked with managing collateral, tracking entry prices, and processing liquidations natively within the L1. Every time the index price updates or a trade executes, the node software must calculate your Unrealized PnL, check your maintenance margin requirements, and determine if your account is solvent.

On generic networks, processing this complex state across thousands of active positions creates massive compute bottlenecks. On HyperCore, this margin logic is baked directly into the validator client. It never has to load a smart contract to figure out if you are liquidatable. It knows intrinsically.

The Unified Advantage: Protocol-Level Portfolio Margin This stark architectural contrast between Spot and Perps brings us back to the Portfolio Margin concept we explored in Part 1. Because the developers control the actual L1 execution client, they built a unified data structure that natively understands both straightforward spot balances and complex perpetual margin requirements.

It unifies your spot holdings and perpetual positions into a single global balance. If you hold that 1 Spot BTC we mentioned earlier, the native Clearinghouse state immediately recognizes its USD value and allows you to use it as cross-margin collateral for your Perp positions. There is no bridging assets between protocols and no depositing into fragmented smart contract vaults, just native, protocol-level capital efficiency.

Reading Raw L1 State with curl: Master Wallet Example

To see how this architectural risk isolation translates into reality, look no further than the native UI.

Notice the exact state of this wallet (0x09174...274e8). The Spot Account Equity holds $798.65, while the Perps Account Equity is empty.

If you were building a frontend for a traditional EVM protocol, rendering these two columns would require the client to make asynchronous balanceOf calls to completely different smart contracts. But because Hyperliquid is a specialized L1, the frontend doesn’t query smart contracts, it directly queries the validator node’s in-memory state.

We can actually bypass the UI entirely and verify this strict class separation using the native API. If we fire a standard curl request to the L1’s /info endpoint, we can ask the node to deserialize the state for this exact Ethereum address.

To check the Perps account (which the UI shows as empty), we query the clearinghouseState:

curl -X POST https://api.hyperliquid-testnet.xyz/info \
     -H "Content-Type: application/json" \
     -d '{"type": "clearinghouseState", "user": "0x09174CC31425746672737a0c3d06Fb27E82274e8"}' | jq

Output

{
  "marginSummary": {
    "accountValue": "0.0",
    "totalNtlPos": "0.0",
    "totalRawUsd": "0.0",
    "totalMarginUsed": "0.0"
  },
  "crossMarginSummary": {
    "accountValue": "0.0",
    "totalNtlPos": "0.0",
    "totalRawUsd": "0.0",
    "totalMarginUsed": "0.0"
  },
  "crossMaintenanceMarginUsed": "0.0",
  "withdrawable": "0.0",
  "assetPositions": [],
  "time": 1776982271519
}

Because we haven’t executed a usdClassTransfer to move funds into the Perps engine, the L1 returns a marginSummary with a totalRawUsd of "0.0".

But if we change the request type to query the Spot engine (spotClearinghouseState), the node instantly returns the isolated Spot state:

curl -X POST https://api.hyperliquid-testnet.xyz/info \
     -H "Content-Type: application/json" \
     -d '{"type": "spotClearinghouseState", "user": "0x09174CC31425746672737a0c3d06Fb27E82274e8"}' | jq

Output

{
  "balances": [
    {
      "coin": "USDC",
      "token": 0,
      "total": "798.0",
      "hold": "0.0",
      "entryNtl": "0.0"
    },
    {
      "coin": "TZERO",
      "token": 1204,
      "total": "0.0",
      "hold": "0.0",
      "entryNtl": "0.0"
    },
    {
      "coin": "UETH",
      "token": 1242,
      "total": "0.006404022",
      "hold": "0.0",
      "entryNtl": "2.67278865"
    },
    ...
  ],
  "tokenToAvailableAfterMaintenance": [
    [
      0,
      "798.0"
    ]
  ]
}

This specific response explicitly shows the isolated Spot state of this account. But if you look closely at the payload, it reveals exactly how the HyperCore execution engine manages internal accounting.

The Architecture of Asset IDs Look at the balances array. Under UETH (Testnet ETH), it says "token": 1242.

In the Hyperliquid API response, the "token" field does not represent how many tokens you own. Instead, it represents the internal numeric Asset ID (or Token Index) assigned to that specific asset by the L1 state machine. Your actual balance is tracked under the "total" field.

Why does the API use these numbers? As we discussed earlier, Hyperliquid is optimized for extreme high-frequency trading. When a trading bot sends a raw JSON order payload to the network, passing string tickers like "UETH" or "USDC" wastes bytes and compute time. Instead, the network assigns a strict integer ID to every single asset. USDC is 0. UETH is 1242.

Solving the UI Mystery: Equity vs. Balance This JSON also solves a major point of confusion for developers migrating from generic EVMs. If you look at our UI screenshot from earlier, the Master Account showed a Spot Account Equity of $798.65.

But looking at the JSON, your USDC "total" is only 798.0. Where did the extra 65 cents come from?

The UI does not just display your raw cash. “Equity” represents the total aggregated USD value of every single asset sitting inside that Spot account natively calculated by the L1. If we do the math based on our raw JSON:

• USDC: $798.00
• UETH: ~ $0.64 (The live USD value of 0.006404022 ETH)

$798.00 + $0.64 = $798.64 (which the UI rounds to $798.65 based on micro-fluctuations in the ETH oracle price).

Available Equity Finally, look at the very bottom of the payload at the second data structure: tokenToAvailableAfterMaintenance.

It returns a nested array: [0, "798.0"].

• The 0 is the internal L1 Asset ID (which we just established is USDC).
• The "798.0" is the free capital.

In high-frequency trading, your "total" balance is rarely the same as your usable balance. If you place a limit order to buy an asset, that order hasn’t filled yet, but it locks up capital. The L1 matching engine immediately updates your "hold" field to reflect this.

If you are writing a quantitative trading bot, you don’t want to manually loop through the balances array, find your total, and mathematically subtract your holds just to figure out if you have enough free capital to execute your next trade.

Instead, the tokenToAvailableAfterMaintenance field does the heavy lifting for you. It explicitly tells your bot exactly how much raw USDC (Token 0) is free to be deployed, withdrawn, or transferred to the Perps account right now, natively factoring in any locked funds. Because your "hold" is currently "0.0", the L1 confirms your full 798.0 USDC is available.

While we have another $0.65 of equity sitting in UETH, you cannot use ETH to place a direct bid on a BTC trading pair. You would have to sell the UETH first. Therefore, the L1 correctly isolates your available purchasing power and reports it as exactly 798.0 USDC.

The transfer boundary: you can’t spend what’s “isolated”

This architectural isolation leads to a critical operational rule that often trips up new developers: The Spot and Perp engines are legally distinct states.

If you have 798 USDC in your Spot account, your Perp account is still mathematically zero. You cannot simply “open a long” using your Spot balance. To move capital between these two engines, you must execute a specific L1 transaction called a usdClassTransfer.

Think of it as an internal bridge between two high-frequency servers. When you move USDC from Spot to Perps:

1. The Spot engine debits your balance and marks the transaction as final.
2. The Perp engine credits your collateral and updates your marginSummary in the next block.

This isn’t just a UI quirk, it’s a safety feature. By requiring an explicit transfer, the protocol ensures that a massive liquidation in your high-leverage Perp account can never “leak” into your Spot account and sweep your long-term asset holdings. (you will see code examples in next blog)

The portfolio: a direct window into L1 state

If you were building this dashboard for a traditional Ethereum DEX, populating this page would be an infrastructural nightmare. You would need to query a centralized indexing server (like The Graph), run dozens of asynchronous RPC calls to different smart contracts to fetch balances, and ping external oracles just to calculate the USD value of your holdings.

But because Hyperliquid is a specialized App-Chain, this Portfolio UI is essentially just a visual wrapper around the exact curl commands we ran earlier.

The frontend does not query a backend database; it queries the validator node directly. When you load this page, the UI hits the /info endpoint, grabs your clearinghouseState and spotClearinghouseState, and does the basic arithmetic we just walked through:

1. It matches the internal Asset IDs (like 0 for USDC and 1242 for UETH) to their human-readable tickers.
2. It checks the native oracle prices (explained later) to calculate the USDC Value of your volatile assets.
3. It checks the tokenToAvailableAfterMaintenance array to display the Available Balance, natively hiding any capital locked in open limit orders.

There are no smart contracts acting as middlemen. What you see on this screen is the exact, millisecond-accurate state of your account sitting in the RAM of the network’s validators.

The architecture of sub-accounts: programmatic risk isolation

If you are a trader running five different algorithmic strategies, you do not want your high-leverage momentum bot sharing the same margin pool as your low-risk statistical arbitrage bot. In a standard EVM environment, you would have to generate five completely different Wallet seed phrases and fund them all separately, incurring massive UX friction and gas fees for every internal transfer.

Hyperliquid solves this natively at the protocol level. Your Master Account can programmatically spawn Sub-Accounts.

What exactly is a Sub-Account? A sub-account is a unique 0x address that acts as an isolated sandbox for your capital. To the L1 state machine, a sub-account is treated as a first-class citizen. This means it has its own independent clearinghouseState and spotClearinghouseState.

If we wanted to check the health of a specific bot, we wouldn’t query the Master Account and filter through the mapping. We simply fire the exact same curl request we used earlier, but swap in the sub-account’s unique address.

Sub-accounts do not have private keys.

You cannot “log in” to a sub-account via MetaMask because it doesn’t have its own EOA credentials. Instead, its authority is derived strictly from your Master Account.

When a trading bot submits an order for a sub-account via the API, it uses the Master Account’s Agent Key to sign the payload, but includes a specific field: vaultAddress (the sub-account’s address). The L1’s execution engine sees the Master signature, verifies the ownership, and then executes the trade against the sub-account’s isolated margin pool.

ℹ️ Note: Before you start spawning bots, there is a specific protocol guardrail you need to know about: You can create up to 10 sub-accounts only after your Master Account reaches $100,000 in trading volume.

Anatomy of a trade: a microsecond lifecycle

We have officially proved that our isolated Spot wallet has 798.0 USDC of free capital ready to deploy. Now, let’s put it to work.

To execute a trade, you navigate to the trading interface.

When you look at this trading module, you aren’t just looking at a UI, you are looking at a real-time visualization of the L1 State Machine constraints.

• The “Available to Trade” Logic: Notice the value 725.74 USDC. As we saw in our spotClearinghouseState curl command, this isn’t just a balance pulled from a wallet. This is the tokenToAvailableAfterMaintenance value. The UI is subtracting any capital currently “locked” in other open limit orders.

From click to Consensus

When you hit that teal Buy button, a specific chain of events is triggered in microseconds:

1. Signing: Your browser (or API agent) signs a localized transaction. Unlike Ethereum, this isn’t an “approve” and “swap” two-step dance. It is a single, signed instruction.
2. Ingestion: The transaction hits a validator. Because of HyperBFT, it doesn’t wait in a public mempool to be “sniped.” It is sequenced immediately.
3. Matching vs. Settlement: The matching engine checks if there is a resting “Sell” order at your price.
   • If matched: The L1 atomically updates the balances (the total field in our JSON) for both parties.
   • If not matched: Your USDC is moved from total to hold, and your order is published to the book.
4. Finality: Within one block, the trade is immutable. There is no “pending” state, the moment the UI updates, the state transition on the blockchain is already history.

Output

The confirmation: L1 state verification

If you recall from Part 1, we defined a blockchain as a shared state machine. This image, taken from the “Order History” tab, is a visual serialization of that state. It confirms multiple architectural truths we’ve just discussed.

Let’s dissect this snapshot:

1. Status: Open. This confirms that the custom consensus mechanism we analyzed (HyperBFT) has achieved finality. This isn’t a “pending” transaction waiting for confirmation or a mempool ingestion notification. This means the L1 state has been updated, and the Central Limit Order Book (CLOB) now recognizes your buy bid at 0.60212.
2. Order ID: 51953570647: This isn’t a hash. It is a unique L1 Order ID. As we learned during our curl command analysis, string lookups are expensive for a high-performance exchange. The HyperCore matching engine uses this integer ID as the index for all future operations, such as cancels or partial fills.
3. Order Value and Capital Management. While entered a size of 120 USDT, the next column: Order Value 72.25 USDC.
   • This confirms that USDC is the native settlement asset for the Spot engine.
   • This is the transaction: this transaction offering exactly 72.25 USDC to buy 120.00 USDT at the defined price.

Summary

We have spent this section using the Hyperliquid UI and raw API calls as a “visual debugger” to prove a fundamental point: this is not just a website, it is a direct window into a specialized L1 state machine. Every balance, every equity calculation, every available capital figure you see on screen is a live serialization of validator RAM — no smart contracts, no indexers, no oracles in between.

For production systems querying this state at high frequency, the public testnet endpoint won’t cut it — it’s rate-limited and shared. On Chainstack, you get a private Hyperliquid endpoint with dedicated throughput, 99.9% uptime SLA, and WebSocket support for real-time streaming. The same curl commands we ran throughout this article work out of the box against your Chainstack endpoint.

What’s Next?

Now that we understand the architectural “why” and the intuitive “how,” it is time to peel back the another layer. In Part 3, we are leaving the browser behind and diving straight into the low-level code.

We will dissect the HyperEVM precompiles that bridge Solidity to the matching engine, and start building custom agents using the SDKs.

FAQ

Related Reading

• What is Hyperliquid? RPC, API, and trading infrastructure
• Hyperliquid architecture: Clearinghouse and Agent Keys
• How to build a Hyperliquid trading bot
• Best Hyperliquid RPC providers in 2026
• Mastering Hyperliquid — full guide series