BlogDeveloper

Hyperliquid Mempool: Guides and Best Streaming Practices

The Hyperliquid mempool is the set of transactions waiting for the next block. What it holds, who can see it, and how a node streams it to disk.

HydromancerTeam
What Is the Hyperliquid Mempool and How Do You Stream It?

The mempool is the waiting room. When a trader sends an order, a cancel or a transfer, it's passed from node to node before the validators commit it into a block, and those in-flight transactions are the mempool. On Hyperliquid the wait is short, since a new block lands about every 70 milliseconds, but if you trade on speed, a transaction you can see before its block is the earliest view of the market there is.

Market makers and latency-sensitive traders want it to know what's about to hit the book. Teams running their own flow use it to time their own path from broadcast to block. Researchers use it because pending transactions show intent, including cancels and orders that never fill.

Three practices make the difference between a mempool feed that works and an empty folder: turn on split_client_blocks on your own node, peer with a node that has it on as well, and match every pending transaction to its committed block before you act on it. The rest of this guide walks through each.

One thing to say up front: we didn't run a node for this article, so we have no measurement of the mempool itself. What we did measure, and where every number here comes from, is in Test and Validation near the end.

Who can see the Hyperliquid mempool

Not the public APIs. Hyperliquid's info endpoint has no request for pending transactions, and nothing in its documented request or stream lists covers them. Hydromancer's REST and stream APIs serve committed data only and have no mempool endpoint either. Hydromancer is a data API; orders always go through Hyperliquid.

The only route is a node. Hyperliquid's node README describes it under "Streaming mempool transactions": set split_client_blocks: true in ~/override_gossip_config.json, and your non-validator node writes uncommitted transactions to ~/hl/data/mempool_txs/{date} as they arrive. The README adds that a future network upgrade could turn this setting on for every node.

Best practices: what the mempool file does and doesn't tell you

The file is useful and limited in equal measure. You see intents, not outcomes: the README says the transactions "are eagerly broadcasted by nodes before they are committed, so the file does not contain responses." An order in the mempool can still be rejected, canceled or only partly filled when its block arrives.

Order is random by default. Nodes stream mempool transactions to their peers in random order, and setting {"enabled": true} in ~/hl/file_mod_time_tracker/node_gossip_priority_config.json makes your node pass them on in the priority order the network sets on-chain (the gossip auction) instead.

And it depends on everyone above you. The README is explicit: "all peers between the node and the validating network must have split_client_blocks enabled." Peer with a public node that has it off and your mempool file stays empty, and there's nothing you can do about it from your side. That's why mempool streaming usually comes up in the same breath as choosing a peer. Your peer decides whether you get it at all.

How to stream the Hyperliquid mempool: step by step

  1. Run a non-validator node. Hyperliquid recommends 16 vCPUs, 128 GB of RAM, 500 GB of SSD and a machine in Tokyo. Our node setup guide walks through it.
  2. Turn on mempool streaming. Add "split_client_blocks": true to ~/override_gossip_config.json, next to your root_node_ips, then check that files start appearing under ~/hl/data/mempool_txs/.
  3. Peer with a node that has it on. Ask your peer provider whether mempool streaming is enabled on its node and on everything upstream of it. With a public peer you take your chances.
  4. Read the files. Transactions appear in ~/hl/data/mempool_txs/{date}. Treat each one as a pending action, and match it to the committed result in your node's block data or the API when the block lands.

How far ahead is it?

We can't put a number on the mempool's lead without a node, and we'd rather say so than guess. What we can show is the timeline it sits in front of. Hyperliquid produced 842 blocks in our 60-second test, one every 71 milliseconds. The public trade feed delivered each trade a median 336 milliseconds after its block time on our connection, and that figure includes our own network path from Singapore.

A transaction in the mempool is broadcast before its block exists, so a node that receives it sees it earlier than that, but how much earlier depends on the node's peers and its position in the network. Measuring it properly means matching the same transactions in a node's pending files and its committed blocks with synchronized clocks, which we haven't done yet.

Three stages from broadcast to screen: the mempool (lead not measured, visible only to your own node), the block (one every 71 ms, 842 in 60 seconds), and the public trade feed (a median 336 ms after block time, measured from Singapore)

Hydromancer peering

Hydromancer runs a node in AWS Tokyo, zone apne1-az1, and offers dedicated peering to teams running their own node: $500 a month, with mempool streaming included, a 99.99% node uptime SLA and a direct line to the engineers on Telegram or Slack. There's a free 7-day trial so you can measure latency and stability from your own server before paying.

The node is on the Hyperliquid Foundation's list of infrastructure providers. Peering is separate from the Hydromancer API plans.

Test and Validation

On 9 November 2026, from a machine in Singapore, we measured two things on the public side of the pipeline and nothing on the mempool side.

  • Block cadence. Hydromancer's perpPrices stream, which sends one message per block, delivered 842 block messages in 60 seconds: one every 71 milliseconds.
  • Delivery delay. Hyperliquid's public trades stream for BTC over the same 60 seconds. Each trade arrived a median 336 milliseconds after its block time on our connection. That includes our own network path from Singapore and is not a property of Hyperliquid's servers.
  • Negative checks. mempool, pendingTxs and mempoolTxs sent to Hyperliquid's info endpoint each returned the same 422 a made-up type gets. That rules out those three names, nothing more. The claim that there's no public mempool request rests on Hyperliquid's documented request and subscription lists, and on Hydromancer's docs index for its side.

Not measured: anything inside ~/hl/data/mempool_txs/, how far ahead of its block a pending transaction becomes visible, or how the peer path changes that. Everything about the mempool files, the config flags and the hardware sizing comes from Hyperliquid's node README as read on the test date. The peering terms are from Hydromancer's peering page.

FAQ

Does Hyperliquid have a public mempool API?

No. The public info endpoint returns committed data only. Pending transactions are available from a node with split_client_blocks turned on.

Can I see Hyperliquid pending transactions without running a node?

Not today. The mempool is streamed between nodes, and the only documented way to read it is your own node's mempool_txs files.

Does the mempool show whether an order filled?

No. It holds the transactions as broadcast, without responses. You see that an order was sent, not what happened to it. Match it to the committed block for the result.

Why is my mempool_txs folder empty?

Either split_client_blocks is off on your node, or a peer between your node and the validators has it off. Every peer in the chain needs it on.

Sources

All posts
Continue

Read next