> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Peering
> Connect your Hyperliquid non-validating node to a dedicated 0xArchive upstream gossip peer in Tokyo. Flat $200 per connecting node address per month, allowlisted by address, no usage metering and no egress charges.
Peering gives teams running their own Hyperliquid non-validating node a dedicated upstream gossip peer, allowlisted to their 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.
## Why Dedicated Peering
| Behavior | Public seed nodes | Dedicated peer |
| ----------------- | ------------------------------------------------------------------------ | --------------------------------------------- |
| Slot availability | Shared and rotated. Connections are refused once a node reaches capacity | Reserved for your allowlisted addresses |
| Address stability | Seed lists change without notice | Fixed addresses issued at onboarding |
| Placement | Wherever the operator runs it | Tokyo, near the Hyperliquid validator set |
| Metering | Not applicable | Flat monthly rate, 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.
Contact [support@0xarchive.io](mailto:support@0xarchive.io) to start.
## 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 |
| Network | Static public egress address, with inbound TCP 4000 to 4010 reachable |
| 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
Email [support@0xarchive.io](mailto:support@0xarchive.io) with the public egress address of every node you want to connect, and the region each one runs in.
0xArchive allowlists your addresses and returns the peer address assigned to your account.
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.
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.
```json override_gossip_config.json theme={"theme":"github-dark"}
{
"root_node_ips": [
{ "Ip": "" }
],
"reserved_peer_ips": [""],
"try_new_peers": false,
"chain": "Mainnet"
}
```
After restarting, confirm the node attached to the assigned address rather than a public seed:
```bash theme={"theme":"github-dark"}
ss -tnp | grep hl-node
```
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
| Included | Not included |
| -------------------------------------------------------- | ------------------------------------------------- |
| A dedicated upstream gossip peer, allowlisted by address | Operation, tuning, or monitoring of your node |
| One peer address per connecting node | 0xArchive REST, WebSocket, or Data Catalog access |
| Committed-block gossip | Mempool or pre-execution input streaming |
| Engineer contact for peering faults | Order submission or transaction relay |
Peering does not change what your node writes. Output files, their format, and their retention stay under your control.
## Related
Custom delivery paths, capacity, and commercial terms for the hosted 0xArchive surfaces.
Freshness, coverage, and incident surfaces for the hosted data products.