How Hyperliquid's Infrastructure Works
HyperBFT consensus, HyperCore and HyperEVM execution, API servers, non-validating nodes, and the public rate limits that shape production Hyperliquid infrastructure.
Hyperliquid is a Layer 1 blockchain built around a custom consensus protocol called HyperBFT. The chain has one state, split into two execution environments that HyperBFT secures together: HyperCore, the native trading engine, and HyperEVM, a general-purpose EVM. Neither layer is a separate chain, and there is no bridge between them. API clients never talk to validators directly. Reads and writes go through Hyperliquid's API servers, or through a non-validating node you run yourself.
This page describes each layer, what it exposes, and where the public endpoints stop being enough for production workloads.
HyperCore and HyperEVM side by side, each connected by an arrow to the HyperBFT consensus layer beneath them. Read precompiles and CoreWriter link the two layers. A One State label sits between the connectors. HyperCore: 200k orders per second, gas-free trading. HyperEVM: 1 second small blocks with 3M gas, 1 minute big blocks with 30M gas, chain ID 999. HyperBFT: 0.2 s median and 0.9 s 99th percentile end-to-end latency.
What consensus does Hyperliquid use?
Hyperliquid uses HyperBFT, a variant of HotStuff consensus. It is proof of stake: validators produce blocks in proportion to the HYPE staked to them. Every committed block is final. There is no probabilistic finality and no reorg window to handle in client code.
HyperBFT is the one thing both execution layers share. HyperCore and HyperEVM state live in the same blocks, ordered by the same validators, so a HyperCore fill and a HyperEVM contract call that land in the same block are final together. Hyperliquid is one state secured by one consensus.
| Measure | Value | Source |
|---|---|---|
| Median end-to-end latency, co-located client | 0.2 seconds | Hyperliquid docs |
| 99th percentile end-to-end latency, co-located client | 0.9 seconds | Hyperliquid docs |
| Mainnet throughput | About 200,000 orders per second | Hyperliquid docs |
End-to-end latency here means the time from sending a request to receiving the committed execution response. The current bottleneck is execution, not consensus or networking.
What is HyperCore?
HyperCore is the native execution environment. It holds the perpetual and spot order books, the clearinghouse that tracks margin, positions, and funding, the oracle, staking, and vaults. Every order, cancel, trade, and liquidation is on-chain and ordered by HyperBFT. There is no off-chain matching engine.
HyperCore is not an EVM. You cannot read the order book with eth_call or place an order from a Solidity contract directly. It has its own API surface:
| Surface | Public endpoint | What it does |
|---|---|---|
| Info endpoint | POST https://api.hyperliquid.xyz/info | Read market data, metadata, and account state |
| Exchange endpoint | POST https://api.hyperliquid.xyz/exchange | Submit signed actions: orders, cancels, transfers |
| WebSocket | wss://api.hyperliquid.xyz/ws | Stream trades, books, fills, and account updates |
Trading on HyperCore is gas-free. Users pay trading fees on filled volume and nothing per order or cancel.
Two other costs apply. Each address has a request budget for exchange actions. It starts with a buffer of 10,000 requests, earns one more request per 1 USDC traded, and can reserve extra actions at 0.0005 USDC each. New accounts also pay a one-time activation fee of 1 quote token on their first inbound transfer.
What is HyperEVM?
HyperEVM is a general-purpose EVM that runs as part of the same Hyperliquid execution, under the same HyperBFT consensus. It is not a separate chain or a rollup. HyperEVM blocks are built inside the same L1 execution as HyperCore, which is why contracts on HyperEVM can read HyperCore state with no bridging. Hyperliquid's docs put it directly: the HyperEVM "is not a separate chain, but rather, secured by the same HyperBFT consensus as HyperCore."
| Property | Value |
|---|---|
| Mainnet chain ID | 999 |
| Testnet chain ID | 998 |
| Gas token | HYPE, 18 decimals |
| EVM version | Cancun, without blobs |
| Fee model | EIP-1559. Base fees and priority fees are both burned |
| Official RPC | https://rpc.hyperliquid.xyz/evm, HTTP only, no WebSocket |
Dual-block architecture
HyperEVM throughput is split between two block types that interleave in one increasing sequence of EVM block numbers:
| Block type | Cadence | Gas limit | Use |
|---|---|---|---|
| Small block | Every 1 second | 3M gas | Normal transactions, fast confirmation |
| Big block | Every 1 minute | 30M gas | Large contract deployments |
Transactions go to small blocks by default. To target big blocks, the sender submits the HyperCore action evmUserModify with usingBigBlocks: true, and can use the bigBlockGasPrice JSON-RPC method to estimate the next big block's base fee. The on-chain mempool accepts only the next 8 nonces per address, and prunes transactions older than one day.
How do HyperCore and HyperEVM talk to each other?
Two mechanisms connect the layers, both exposed to Solidity as built-in calls.
Read precompiles live at addresses starting from 0x0000000000000000000000000000000000000800. They return HyperCore data such as perp positions, spot balances, vault equity, staking delegations, oracle prices, and the L1 block number. The values are guaranteed to match the latest HyperCore state at the time the EVM block is constructed. Each call costs 2000 + 65 * (input_len + output_len) gas.
CoreWriter is a system contract at 0x3333333333333333333333333333333333333333. A contract calls it to emit a log that HyperCore processes as an action, such as placing an order or moving funds. A basic call uses about 47,000 gas. Order actions and vault transfers sent through CoreWriter are delayed on-chain by a few seconds so that HyperEVM cannot be used to bypass the L1 mempool.
Native transfers between the layers use system addresses. Sending HYPE to 0x2222222222222222222222222222222222222222 on HyperCore credits the same address on HyperEVM. Error code 10055 marks failures at the HyperCore and HyperEVM boundary, such as nonce errors or insufficient funds.
What are API servers?
API servers are the public face of Hyperliquid. An API server listens to a node, keeps a local copy of chain state, and serves that state over REST and WebSocket. It does not validate.
Five steps: the client signs the action and sends it over REST or WebSocket; the non-validating API server keeps a local state copy and forwards to its node; the node gossips the transaction to validators on ports 4001 and 4002; HyperBFT orders and executes it in a committed block, final at once; the API server returns the L1 execution result, not an acknowledgement. The whole round trip is 0.2 s median and 0.9 s at the 99th percentile for a co-located client.
When you submit an action, the path is:
- Your client sends the signed action to an API server.
- The API server forwards it to its connected node.
- The node gossips the transaction into HyperBFT consensus.
- The transaction is included in a committed block.
- The API server responds with the execution result from that block.
The response you receive is the L1 execution outcome, not an acknowledgement that the request was queued. That is why the 0.2 second median figure above covers the full round trip. API servers may disconnect WebSocket clients periodically without announcement. Automated clients should reconnect and use the snapshot sent on reconnect to fill any gap.
What does a Hyperliquid node do?
Validators run HyperBFT and execute blocks. Anyone can run a non-validating node, which streams committed blocks from peers and executes them locally. The node binary is distributed through hl-visor, and started with hl-visor run-non-validator.
| Requirement | Non-validating node |
|---|---|
| Hardware | 16 vCPUs, 128 GB RAM, 500 GB SSD |
| Network | Ports 4001 and 4002 open to the public for gossip |
| Location | Tokyo for the lowest latency to validators |
| Disk write rate | About 100 GB of logs per day with default settings |
The Hyper Foundation runs a best-efforts non-validating node in AWS apne1-az1 that qualified traders and infrastructure providers can peer with. Dwellir is one of the listed peering providers. If you run your own node, Hyperliquid Peering reserves a slot on Dwellir's peers so your node has a stable upstream.
What a node writes to disk
A non-validating node is the only way to get some data. It writes protocol records under ~/hl/data:
| Path | Content | Flag |
|---|---|---|
replica_cmds/{start_time}/{date}/{height} | Blocks with signed actions, responses, and consensus metadata | Default |
periodic_abci_states/{date}/{height}.rmp | Full state snapshot every 10,000 blocks | Default |
node_fills/hourly/{date}/{hour} | Fills in API format | --write-fills |
node_twap_statuses/{date}/{hour} | TWAP lifecycle statuses | --write-fills |
node_order_statuses/hourly/{date}/{hour} | Every order status change | --write-order-statuses |
node_raw_book_diffs/hourly/{date}/{hour} | Every order-level book change | --write-raw-book-diffs |
misc_events/hourly/{date}/{hour} | Staking, validator rewards, ledger updates | --write-misc-events |
With --batch-by-block, each line is one block in the envelope {local_time, block_time, block_number, events}. The block_number in those envelopes is a sequential height. It is not the same value as the abci_block.round inside replica_cmds, because consensus rounds can skip.
Two flags turn a node into a local API: --serve-eth-rpc serves HyperEVM JSON-RPC on localhost:3001/evm, and --serve-info serves Info endpoint requests on localhost:3001/info. Neither replicates the historical time-series queries of the public API. The data catalog documents each feed's schema and how Dwellir exposes it live and historically.
What are the public rate limits?
The official API servers and RPC enforce per-IP limits. These are the numbers that decide when a project outgrows public infrastructure.
REST info and exchange: 1,200 weight per minute per IP, with weight 2 for l2Book and clearinghouseState, 20 for most info calls, and 60 for userRole. WebSocket: 10 connections per IP, 1,000 subscriptions, 2,000 messages per minute, 10 unique users on user streams. EVM JSON-RPC at rpc.hyperliquid.xyz: 100 requests per minute, HTTP only. Your own node or a managed provider: no per-IP API limits, 16 vCPUs, 128 GB RAM, 500 GB SSD, about 100 GB of node output per day.
| Surface | Limit |
|---|---|
| REST, info and exchange combined | 1,200 weight per minute per IP |
| Info request weight | 2 for l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus. 60 for userRole. 20 for everything else |
| Exchange request weight | 1 + floor(batch_length / 40) |
| WebSocket connections | 10 per IP, 30 new connections per minute |
| WebSocket subscriptions | 1,000 per IP, 10 unique users across user-specific subscriptions |
| WebSocket messages | 2,000 sent per minute, 100 in-flight post messages |
EVM JSON-RPC at rpc.hyperliquid.xyz/evm | 100 requests per minute |
Paginated info requests such as userFills add extra weight per 20 items returned, and candleSnapshot adds extra weight per 60 items. Hyperliquid's own guidance for large historical pulls is to use the S3 bucket rather than the API.
When does public infrastructure stop being enough?
The public endpoints are designed for interactive use and light automation. You have outgrown them when any of these are true:
- You poll faster than 1,200 weight per minute. A bot that reads
clearinghouseStateandl2Bookfor a handful of markets every second uses the whole budget on its own. - You need more than 10 WebSocket connections or 1,000 subscriptions per IP. Subscribing to trades and L2 books across every perp market already exceeds the ceiling. See WebSocket subscription limits.
- You index HyperEVM. An indexer or backfill at 100 requests per minute takes days for work that should take minutes, and the official RPC has no WebSocket for new heads.
- You need L4 order-level data or raw book diffs. These are only written by a node. They are not on the public API.
- You need history. The API returns at most 500 items per time-range query and keeps limited depth. Backtests and research need the archive.
At that point there are two paths. Run your own non-validating node, with peering for a reliable upstream, or use a provider that runs nodes for you.
Dwellir runs Hyperliquid nodes and exposes every layer described above through one platform: gRPC streams of the node-written feeds, a purpose-built Order Book WebSocket for L2, L4, and trades, HyperEVM JSON-RPC, the Info endpoint with limits that scale by plan, and an archive of the raw node files back to January 2025. In Dwellir's published benchmark from Tokyo, the Order Book WebSocket delivered a 212 ms median update latency against 263 ms on the public API. See pricing for plan limits and the Dedicated Node Cluster option.
Related
- Hyperliquid data catalog: what the node writes and how each feed is exposed
- Hyperliquid Peering: reserved gossip peers for your own node
- Hyperliquid latency explained: where the milliseconds go between node, API, and client
- Hyperliquid docs: HyperCore overview
- Hyperliquid docs: HyperEVM
- Hyperliquid docs: rate limits
- Hyperliquid node repository
Hyperliquid - High-Performance Trading Infrastructure
Complete guide to Hyperliquid integration with Dwellir. Access HyperEVM JSON-RPC endpoints and L1 gRPC streaming for order books and trading data.
Hyperliquid Pricing
Hyperliquid Unlimited Node: $1,500/month plus required gRPC or Order Book add-ons. Dedicated Node Cluster: $4,000/month with both add-ons included and unmetered.