> ## 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

> Tokyo Hyperliquid peering for non-validating nodes. Flat $200 monthly per allowlisted connecting node address, with no usage metering or egress charges.

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

| 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

<Steps>
  <Step title="Send your egress addresses">
    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.
  </Step>

  <Step title="Receive your peer address">
    0xArchive allowlists your addresses and returns the peer address assigned to your account.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Restart and confirm">
    Restart the node, then confirm it reaches the chain tip and that the assigned address appears among its established connections.
  </Step>
</Steps>

## 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": "<peer address issued to you>" }
  ],
  "reserved_peer_ips": ["<peer address issued to you>"],
  "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
```

<Warning>
  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.
</Warning>

## 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. For custom capacity and delivery on the hosted 0xArchive data surfaces, see [Enterprise delivery](/enterprise-delivery).

## Next step

Email [support@0xarchive.io](mailto:support@0xarchive.io) with the public egress address and region of each node you want to connect.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.