How to migrate Hyperliquid node peering

0xArchive guide · Hyperliquid

A Hyperliquid non-validating node takes its blocks from one upstream peer at a time. Moving that peer to 0xArchive's allowlisted peer in Tokyo, from public seeds or from another peering provider, takes one config file and one restart.

0xArchive peering is $200 per node address per month, flat, with no usage or egress charges. The mempool is included. It needs no 0xArchive account or data plan, and you pay through Stripe Checkout on the peering page.

Before you switch: a static IPv4 address and ports 4000 to 4010 open

The peer allowlists your node by its public IPv4 address. Check the node against this list before you pay, because an address that cannot be allowlisted delays everything after it.

Requirement	What the peer needs
Node	A non-validating node run with `hl-visor run-non-validator`
Address	A static public IPv4 egress address. IPv6 cannot be allowlisted
Network	Inbound TCP 4000 to 4010 reachable
Machine	Ubuntu 24.04, 16+ cores, 128 GB RAM, NVMe
Clock	NTP or chrony running

Open the whole 4000 to 4010 range, not only 4001 and 4002. The node binds several ports across it, and with only two open the TCP handshake completes and the gossip session then fails above it.

If your node sits behind a NAT pool, or on a host that gets a new egress address on restart, fix that first. The allowlist matches one exact address.

The 0xArchive peer runs in Tokyo, where Hyperliquid recommends running a node for the lowest latency. The latency test runs on the same machine as the peer, so running it from the server that hosts your node measures the round trip your node will see.

No account or API key is needed.

Subscribe from the peering page or the pricing page. In checkout, set the quantity to the number of nodes you are connecting, then enter each node's public IPv4 address and the provider and region it runs in.

1. Billing starts at checkout. Each address is then reviewed and allowlisted by hand.

2. The peer address arrives by email at the address you used in checkout, once allowlisting is complete.

3. Change nothing on the node until then. A node pinned to a peer that has not allowlisted it has nowhere to stream from.

If you are leaving another provider, keep that subscription running through the switch, and cancel it once the checks further down pass.

Back up your gossip config, then point it at the 0xArchive peer

The node reads its peers from override_gossip_config.json, read relative to its working directory, so it sits beside hl-visor in the account home. Copy it before you edit it. The copy is your rollback.

cp ~/override_gossip_config.json ~/override_gossip_config.json.bak

A node on public seeds or another provider has a file shaped like this, with its old roots listed:

{
  "root_node_ips": [
    { "Ip": "<old peer 1>" },
    { "Ip": "<old peer 2>" }
  ],
  "try_new_peers": true,
  "chain": "Mainnet"
}

Replace it with the 0xArchive peer address from your email:

{
  "root_node_ips": [
    { "Ip": "<peer address>" }
  ],
  "reserved_peer_ips": ["<peer address>"],
  "try_new_peers": false,
  "split_client_blocks": true,
  "chain": "Mainnet"
}

What each line does:

Key	What it does
`root_node_ips`	The upstream your node streams from
`reserved_peer_ips`	Always accepts incoming connections from the peer
`try_new_peers`	`false` keeps the node off public seeds it discovers
`split_client_blocks`	`true` turns on the mempool. Leave it out for committed blocks only

Set try_new_peers to false. Left on true, the node can discover and attach to public seeds, including ones outside Tokyo. A node on a distant seed can sit hundreds of milliseconds further from the chain tip while every process-level health check stays green.

Pinned this way, your node depends on the peer. Maintenance and Hyperliquid node software updates can briefly interrupt delivery, and a pinned node resumes when the peer is back.

Restart the node to load the new peer

Restart the node the way you normally run it, your systemd unit or hl-visor run-non-validator. Startup can take a while as the node finds the peer to stream from.

Confirm the node streams from the 0xArchive peer, not a public seed

A node that lands on the wrong upstream still passes process-level health checks. Check three things after the restart.

1. The connection to the peer is established.

ss -tn dst <peer address>

A line in ESTAB state means the node is attached. If it is established but the node does not advance toward the chain tip, check that inbound TCP 4000 to 4010 is reachable.

2. The node is applying blocks. The node log shows applied block lines while it streams live data.

3. New block files keep arriving. The node keeps writing new files under ~/hl/data/replica_cmds while it streams:

find ~/hl/data/replica_cmds -type f -newermt '-1 minute' | tail -5

No files in the last minute means the node is not streaming. Check the address in the config against the one in your email, then the firewall.

Turn on the mempool with split_client_blocks, and budget 0.5 TB a day of writes

With split_client_blocks set to true, the node writes pending transactions under ~/hl/data/mempool_txs/ ahead of the block that commits them.

Every peer between your node and the validators has to have the flag on for the mempool to reach you. Most public root peers do not, so a node on public seeds that sets it gets committed blocks only. The 0xArchive peer forwards it.

The cost is disk. The mempool adds roughly 0.4 to 0.5 TB of writes per day, so prune those files on a schedule.

If the peer falls back to a backup upstream, committed blocks keep arriving and pending transactions can pause until it returns.

Roll back by restoring the old config and restarting

If the checks fail and you cannot fix them, put the old file back and restart the node:

cp ~/override_gossip_config.json.bak ~/override_gossip_config.json

Then email support@0xarchive.io with the node's address and what the checks showed. Peering faults go to an engineer.

Tell support before your node's IP address changes

The allowlist matches one address. Moving the node to a new server, region or provider changes its egress address, and the peer then refuses it.

Email support@0xarchive.io with the new address before the move. The same address handles more than five node addresses, at the same price per address, and cancellation. After you cancel, peering stays on until the end of the period you paid for.

Common questions about Hyperliquid node peering

What is Hyperliquid node peering? A non-validating Hyperliquid node takes its blocks from an upstream gossip peer. Peering gives your node a dedicated, allowlisted peer instead of the shared public seeds, which rotate and refuse connections once they reach capacity.

How much does 0xArchive peering cost? $200 per node address per month, flat, with no usage or egress charges, as of October 2026. The mempool is included.

Do I need a 0xArchive account or data plan? No. Peering is billed separately through Stripe Checkout and can run alongside any data plan.

Does 0xArchive claim rights over the data my node receives? No. Data your node receives through the peer is not 0xArchive Data, and the Data License does not apply to it.

Does 0xArchive run or monitor my node? No. You operate your node, and 0xArchive operates the peer it connects to.

Peering references

For requirements, configuration and scope, use the peering docs. To read the mempool without running a node, use the live mempool stream on the Pro plan and above.

For current availability and plan details, use the peering page, pricing, and status.