Skip to main content
Connect your own Hyperliquid non-validating node to a dedicated upstream gossip peer in Tokyo, allowlisted to your egress addresses. You operate your node. 0xArchive operates the peer it connects to. Peering is separate from the 0xArchive REST API, WebSocket, and Data Catalog. It carries no 0xArchive data surface: your node receives blocks over Hyperliquid’s own peer-to-peer protocol and writes its own output files.

​
Public seeds and a dedicated peer

  • Slot availability. Public seed nodes are shared and rotated, and refuse connections once a node reaches capacity. A dedicated peer is reserved for your allowlisted addresses.
  • Address stability. Public seed lists change without notice. A dedicated peer uses fixed addresses issued at onboarding.
  • Placement. A public seed runs wherever its operator runs it. The dedicated peer runs in Tokyo, near the Hyperliquid validator set.
  • Metering. The dedicated 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. Dedicated peering removes that failure mode.

​
Pricing

$200 per connecting node address per month. Flat rate, with no usage metering and no egress charges. 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.

​
What you need

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

1

Send your egress addresses

Email support@0xarchive.io with the public egress address of every node you want to connect, and the region each one runs in.
2

Receive your peer address

0xArchive allowlists your addresses and returns the peer address assigned to your account.
3

Pin your node to it

Put the assigned 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.
4

Restart and confirm

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

​
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
After restarting, confirm the node attached to the assigned address rather than a public seed:
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. Mempool forwarding and split_client_blocks input streaming are not part of this offering.

​
Availability

99.9% monthly gossip reachability, measured on whether the peer accepts and serves a connection from your allowlisted address. Announced maintenance windows are excluded from the measurement. One peer address is issued per connecting node, so a maintenance window or a node binary update is visible to a node pinned to it. Maintenance is announced ahead of the window. Unannounced downtime counts against the figure above.

​
Scope

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.

​
Next step

Email support@0xarchive.io with the public egress address and region of each node you want to connect.
Last modified on October 6, 2026