Peering connects a Hyperliquid non-validating node that you operate to Quicknode's sentry nodes. Your node receives blocks and the full mempool over three dedicated peer IPs instead of shared public root peers. Quicknode runs the sentries. You run the node.

Peering or a managed endpoint

Peering changes the upstream connectivity contract, not the data interface. Your node writes raw files to disk. It does not return a prebuilt order book, normalized events, or filtered payloads.

Access model	Who runs the node	What you get	Best fit
Public peers	You	Whatever the peer path supports, no SLA	You can operate the full stack and accept public-peer availability
Quicknode Peering	You	Full blocks and raw mempool, three sentry IPs, 99.99% SLA	You need continuous raw local data and a contracted upstream path
Managed Quicknode endpoint	Quicknode	Filterable gRPC and WebSocket datasets, SQL tables	You want APIs or normalized datasets without operating a node

If you want Hyperliquid blocks, trades, or transactions delivered to your application without running a node, use a managed endpoint instead: gRPC streams, WebSocket, or SQL Explorer.

The two are not exclusive. Run Peering for raw local files and add managed gRPC when you also need a normalized L2 or L4 book.

What you get

• Three dedicated sentry peer IPs across multiple datacenters in the Tokyo region, all returned at activation
• Full mempool delivery with no usage meter. Quicknode sentries run with split_client_blocks enabled, which most public peers do not
• 99.99% uptime SLA on your sentry peer connections, monitored by the engineers who operate them
• No staking or volume requirement. Peering to the Foundation non-validating node requires 10,000 HYPE staked and Tier 1 maker rebate status

The peers are sentries, not validators. Every validator runs two sentry peers, and Quicknode's own non-validating nodes peer through the same sentry layer. Your peers take no part in consensus, and peering involves no staking or delegation.

How the three peers work

The Hyperliquid node client streams blocks from one upstream peer at a time. On startup it works through the addresses in ~/override_gossip_config.json, picks one, and streams from it until that connection is lost. It does not aggregate or race multiple peers, and adding more peers does not make blocks arrive faster.

The three IPs exist so the node always has somewhere to go. You list all three as roots and as reserved peers, and disable public discovery so the node never silently falls back to a random public peer that may not carry mempool:

{
  "chain": "Mainnet",
  "root_node_ips": [
    { "Ip": "x.x.x.x" },
    { "Ip": "x.x.x.x" },
    { "Ip": "x.x.x.x" }
  ],
  "reserved_peer_ips": ["x.x.x.x", "x.x.x.x", "x.x.x.x"],
  "try_new_peers": false,
  "split_client_blocks": true
}

root_node_ips is the list the node bootstraps and streams from. reserved_peer_ips tells the node to always accept connections from those addresses. try_new_peers: false stops the node from discovering other peers on its own.

Who handles what when a peer misbehaves:

Situation	Handled by	How
The active peer disconnects	The node	Reconnects through another address in root_node_ips. No action needed from you.
A peer stays connected but falls behind the chain	You	The node does not detect this on its own. Watch your applied block height against chain head and restart or re-pin roots when it lags. Quicknode gives you three roots so that logic has somewhere to switch to.
A sentry has packet loss or connectivity trouble	Quicknode	Sentry health, connectivity, and load are monitored and logged on the Quicknode side, including around US market open. Support can confirm whether a lag originated on the Quicknode path.
Your host is undersized or misconfigured	You	Node setup, sizing, and application-side logic are outside the peering support scope.

To test each peer in isolation, pin a single root, confirm it streams and writes mempool, then restore all three. The node guide ships a readiness script and a peer isolation check that fails if public discovery is on or an unexpected peer is connected.

Node requirements

Hyperliquid publishes a minimum spec and a higher one for latency-sensitive reads. The Quicknode reference host is what the node guide was written against.

Component	Hyperliquid minimum	Latency-optimized	Quicknode reference host
CPU	16 vCPUs	32 logical cores or more	16 dedicated vCPUs
Memory	128 GB	128 GB	128 GiB
Storage	500 GB SSD	500 MB/s disk throughput	2,340 GiB local NVMe
Operating system	Ubuntu 24.04 only	Ubuntu 24.04 only	Ubuntu 24.04
Inbound firewall	TCP 4001 and 4002 open to the public	Same	Same, plus your cloud firewall
Region	Tokyo for lowest latency	Tokyo	Tokyo

Ports 4001 and 4002 must be publicly reachable. A node without them is deprioritized by the peer network. More CPU cores execute blocks faster, which lowers the latency of every file the node writes. Start the node with --disable-output-file-buffering if you read its output files in real time.

Storage planning

The 500 GB minimum is a boot figure, not a retention target.

• Raw mempool output: about 1.1 TB per day observed, higher in volatile periods
• Default node logs: about 100 GB per day per Hyperliquid's estimate
• Optional outputs such as fills and order statuses add more, and the volume depends on the flags you enable

Set a retention policy before the disk fills. Benchmark the exact flag combination you need under catch-up load, not just steady state.

Mempool

Raw mempool delivery needs split_client_blocks: true on every peer between your node and the validator network. Quicknode sentries provide that path. With the same flag set on your node, pending transactions are written to ~/hl/data/mempool_txs/{date}. The file holds actions only, not responses, because these transactions are broadcast before they are committed.

Mempool delivery is randomly ordered by default. The onchain gossip priority auction is a separate, optional node setting and does not change what Peering delivers.

Evaluation and pricing

$500 per month for three dedicated sentry peer IPs and full mempool with no usage meter. An active Quicknode plan is also required. Crypto payment is supported.

You have 7 days from activation to test latency, disconnect recovery, uptime, and sustained mempool delivery. Contact support within that window for a prorated refund if stability does not meet your requirements.

Managed gRPC and WebSocket streaming bill on post-filter bytes received and are priced separately on the Pricing & Plans page.

Activation

1. Subscribe to the Hyperliquid Peering add-on from your Quicknode account. The $500 monthly fee is charged at checkout.
2. Email support@quicknode.com with your Quicknode account email and your node's public IPv4 address.
3. An engineer allowlists your node and returns the three root and reserved peer addresses with configuration guidance. Provisioning is usually same day.
4. Write the addresses into ~/override_gossip_config.json as shown above and start the node.

Allowlisting is per IP. If your node's public IP changes, email support with the new address before a planned migration.

Support

Peering support covers the path between your node and the sentries: peer instability, packet loss, connectivity, and confirming whether a lag originated on the Quicknode side. It is handled by the engineers who operate the sentry layer, by email with APAC coverage, and a shared channel with a named engineer is available for setup and ongoing operations.

It does not cover setting up your node, sizing your host, or your application's failover logic.

Frequently asked questions

Do I need to run my own Hyperliquid node?▼

Yes. Peering is only useful if you already operate a Hyperliquid non-validating node. Quicknode does not run the node for you. If you want blocks, trades, or transactions delivered to your application without node infrastructure, use a Quicknode Hyperliquid endpoint over gRPC or WebSocket instead.

Will three peers make my node faster?▼

No. The node streams from one peer at a time, so the three IPs are for redundancy, not throughput. Actual latency depends on where your node runs and your network path to Tokyo.

Is there automatic failover between the three peers?▼

If the active peer disconnects, the node reconnects through another root on its own. If a peer stays connected but falls behind, the node does not notice. Detecting that and rotating roots is client-side logic you own, and the three IPs give that logic somewhere to switch to.

Will I actually get the full mempool?▼

Yes. Mempool streaming is included with no usage meter. Getting mempool from a peer requires that peer to run with split_client_blocks enabled, which is why arbitrary public peers often do not deliver it. Quicknode sentries do.

Where are the peers located?▼

Across multiple datacenters in the Tokyo region. The IPs are shared after you subscribe and your node is added to the allowlist.

What does the 99.99% uptime cover?▼

Availability of your sentry peer connections, monitored and alerted by the team that operates them. It does not cover the uptime of your own node.

Does the 7-day evaluation start at purchase or at activation?▼

At activation, once your node is allowlisted and the three peer IPs are live. Provisioning is usually same day.

Do I still need a Quicknode plan?▼

Yes. Peering is an add-on and requires an active Quicknode plan alongside the monthly peering fee.

Next steps

• Run a Hyperliquid Node with Quicknode Peering, the eight-step deployment guide with readiness and peer isolation checks
• Hyperliquid node README for the upstream machine specs and gossip configuration
• Mempool Transactions stream if you want the mempool without running a node