Peering

Connect your own Hyperliquid non-validating node to an upstream gossip peer in Tokyo that accepts connections only from allowlisted customer addresses. You operate your node. 0xArchive operates the peer it connects to.

An allowlisted Tokyo peer for your Hyperliquid node

$200 per node address per month

Subscribe Pricing and terms

Mempool included
Flat rate, no usage or egress charges
Same peer, price and terms for every customer
No 0xArchive account needed

Pay by card through Stripe. Enter each node’s public IPv4 address at checkout. Cancel by email to [email protected].

Peering is separate from the 0xArchive REST API, WebSocket, and Data Catalog. It carries no 0xArchive data surface: your node receives blocks, and pending transactions if you turn them on, over Hyperliquid’s own peer-to-peer protocol and writes its own output files.

Public seeds and an allowlisted peer

Slot availability. Public seed nodes are shared and rotated, and refuse connections once a node reaches capacity. The 0xArchive peer accepts connections only from allowlisted customer addresses.
Address stability. Public seed lists change without notice. The peer uses a fixed address issued at onboarding.
Placement. A public seed runs wherever its operator runs it. The peer runs in Tokyo, where Hyperliquid recommends running a node for the lowest latency.
Metering. The peer has a flat monthly rate, with no usage or egress charges.

A node pinned to public seeds will periodically lose its upstream and fall back to whichever address accepts it next, which shows up as a rising tail on block arrival rather than a clean outage. Pinning your node to an allowlisted peer avoids that drift. While pinned, your node depends on that peer (see Availability).

Pricing

$200 per connecting node address per month. Flat rate, with no usage metering and no egress charges. To subscribe, select Subscribe at the top of this page or in the Node peering section of the pricing page. Both open Stripe Checkout. The quantity is the number of node addresses you connect, and checkout asks for the public IPv4 egress address of each node. Peering is billed separately from the data plans: it needs no 0xArchive account, and a team can hold a data plan and peering at the same time. Every customer receives the same peer configuration at the same price. There are no preferential slots, no priority tiers, and no separate arrangement for trading firms. Data your node receives through the peer is not 0xArchive Data. 0xArchive claims no rights over it and places no limits on how you use it, and the Data License does not apply to it. Data from the 0xArchive API, WebSocket, or Data Catalog stays under the Data License.

What you need

Requirement	Detail
Node	Hyperliquid non-validating node run with `hl-visor run-non-validator`
Operating system	Ubuntu 24.04
Machine	16 or more logical cores, 128 GB RAM, NVMe storage
Storage	Size for the write flags you enable. `--write-order-statuses` alone runs several hundred GB per day. The mempool (`split_client_blocks`) adds roughly 0.4 to 0.5 TB of writes per day
Network	Static public IPv4 egress address, with inbound TCP 4000 to 4010 reachable. IPv6 addresses cannot be allowlisted
Clock	NTP or chrony. Block timestamps are only as useful as the host clock behind them

The node binds several ports across the 4000 to 4010 range, not only 4001 and 4002. Opening the range avoids a handshake that completes at the TCP layer and then fails above it.

Onboarding

Subscribe and enter your node addresses

Select Subscribe at the top of this page or on the pricing page to open Stripe Checkout. In checkout, set the quantity to the number of node addresses you are connecting, then enter the public IPv4 egress address of each node and the provider and region it runs in.

Address review

0xArchive reviews each address by hand, then allowlists it on the peer. Billing starts at checkout. If an address cannot be allowlisted, 0xArchive asks you for a replacement. If you have none, the subscription is reduced to the addresses that can be allowlisted and the difference is refunded.

Receive your peer address

Once your addresses are allowlisted, the peer address is emailed to the address used at checkout.

Pin your node to it

Put the peer address in override_gossip_config.json and set try_new_peers to false so the node stays on it instead of drifting onto public seeds.

Restart and confirm

Restart the node, then confirm it reaches the chain tip and that the peer address appears among its established connections.

If you are moving a running node from public seeds or another provider, the peering migration guide covers backing up the config, confirming the switch, and rolling back. For questions, an address change, cancellation, or more than five node addresses (at the same price per address), email [email protected].

Configuration

override_gossip_config.json is read relative to the node’s working directory, so it belongs beside the binary in the account home.

override_gossip_config.json

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

split_client_blocks turns on the mempool, which adds roughly 0.4 to 0.5 TB of disk writes per day (see below). Leave it out to receive committed blocks only. After restarting, confirm the node attached to the peer address rather than a public seed:

ss -tn dst <peer address>

An established connection to the peer address means the node is attached to it. If it is established but the node does not advance toward the chain tip, check that inbound TCP 4000 to 4010 is reachable (see What you need).

Leaving try_new_peers set to true lets the node discover and attach to public seeds, including addresses outside Tokyo. A node that wanders onto a distant seed can sit hundreds of milliseconds further from the chain tip while every process-level health check stays green.

What the peer forwards

The peer forwards committed-block gossip, which is what your node needs to execute blocks and hold the chain tip. It also forwards the mempool: pending transactions the peer receives before they are in a block. Most orders arrive this way; some reach a block without being gossiped first. Your node receives them when split_client_blocks is true in override_gossip_config.json, and writes them under ~/hl/data/mempool_txs/ ahead of the block that commits them. At recent activity that adds about 5 MB per second of disk writes, so prune those files on a schedule. If the peer falls back to a backup upstream, blocks keep arriving, and pending transactions can pause until it returns. To read the mempool without running a node, the live mempool stream is available on the Pro plan and above.

Availability

The peer runs in Tokyo. Maintenance and Hyperliquid node software updates can briefly interrupt delivery; a node pinned to the peer resumes when it is back.

Scope

Included	Not included
An upstream gossip peer, allowlisted by address	Operation, tuning, or monitoring of your node
One peer address, the same for every customer	0xArchive REST, WebSocket, or Data Catalog access
Committed-block gossip and the mempool	Stored or historical mempool data
Engineer contact for peering faults	Order submission or transaction relay

Apart from the mempool files you choose to turn on, peering does not change what your node writes. Output files, their format, and their retention stay under your control. For custom capacity and delivery on the hosted 0xArchive data surfaces, see Enterprise delivery.

Start

Concepts

Plans and limits

Policies

Guides

Public seeds and an allowlisted peer

Pricing

What you need

Onboarding

Configuration

What the peer forwards

Availability

Scope

Next step

​Public seeds and an allowlisted peer

​Pricing

​What you need

​Onboarding

​Configuration

​What the peer forwards

​Availability

​Scope

​Next step

Public seeds and an allowlisted peer

Pricing

What you need

Onboarding

Configuration

What the peer forwards

Availability

Scope

Next step