How to set up a Hyperliquid non-validator node

How data propagates on Hyperliquid

Gossip propagation in the Hyperliquid network works differently than you might expect. Validators are responsible for verifying the transactions included in a block. Every validator node has two slots for running a non-validator node directly connected to the validator; these are called sentry nodes.

From the sentry nodes, data propagates to the rest of the non-validator network. The validator network consists of 5 validators run by the Hyperliquid Foundation and 22 validators run by various parties in the community. The sentry nodes linked to the Foundation validators have an advantage and receive data ~100 ms earlier than the sentries of community validators.

The Foundation runs two sentry nodes that are available to the public if you meet certain requirements. These requirements are that you are either a high-volume trader (>0.5% of 14-day weighted maker volume) or a reputable infrastructure provider. From there, infrastructure providers can offer Hyperliquid peering services to the public.

Finding the right peers for a Hyperliquid non-validator node

Hyperliquid gossip propagation works in such a way that you are always receiving gossip from a single parent at a time. This means the parents you choose matter. If a connection drops, the node will stall for 10–30 seconds while finding and reconnecting to a new peer, assuming it can find one that is available.

You can find all Foundation-sentry-peered non-validators and normal validator sentries on Flowscan. In addition, there are infrastructure providers that offer reserved Hyperliquid sentry peering downstream of the Foundation sentry, which can significantly improve the latency and stability of your non-validator node.

Choosing the right machine for a Hyperliquid node

There are many different options for different types of use cases. In general, if you expect a lot of egress, you probably want to set up a server with a provider other than AWS. If latency in the single-digit milliseconds is critical to you, you will want to colocate in apne1-az1 with a peering provider that is also located there, as the Foundation sentry is in the same availability zone. This is particularly relevant for low-latency Hyperliquid data infrastructure.

The Hyperliquid Foundation recommends 16 vCPU / 128 GB RAM / 500 GB SSD for running a non-validator. This can be sufficient for simple use cases, but if you run heavy software alongside it, you should probably consider upgrading these requirements. Also, make sure the machine you choose supports Ubuntu 24.04, as that is the only version supported by the node binary.

This is a non-exhaustive list to give you an idea of the costs and setups available from different providers in Tokyo:

Notes

• Prices as of 15 Aug 2026 and subject to change. This is a non-exhaustive list.
• A 1-year commitment often gives a 30–40% discount.
• AWS egress to external IPs: ~$0.104/GB. Acting as an upstream peer for one non-validator ≈ 3 TB/mo ≈ $300/mo. You can, of course, select which IPs to open ports to.
• If sub-millisecond to low-single-digit-millisecond latency matters, colocate downstream of the Foundation sentry in apne1-az1 — and confirm that your provider hosts its non-validator in the same AZ.

System setup

• Open ports 4001 and 4002 for inbound and outbound traffic for the parent and child nodes you want to connect to.
• Sync your clock so your latency measurements are trustworthy.
• Symlink ~/hl to the drive you prefer, as this is where the Hyperliquid node writes all its logs. It is beneficial to use a fast disk such as NVMe with enough disk space. 500 GB is enough if you prune multiple times a day.
• Turn off unattended upgrades, as they can cause unwanted restarts of your node, which results in delays.

Set up override_gossip_config.json

The location of this file should be ~/override_gossip_config.json. You have to create this file; otherwise, your Hyperliquid non-validator node will not work.

{
 "root_node_ips": [
   { "Ip": "0.0.0.0" }
   
 ],
 "try_new_peers": false,
 "chain": "Mainnet",
 "reserved_peer_ips": ["0.0.0.0", "1.1.1.1"],
 "split_client_blocks": true
}

root_node_ips are the parents your node will try to connect to. It does this on a round-robin basis, meaning it first tries to connect to the first IP specified. If that connection drops or the peer is unavailable, it will switch to the next one.

Therefore, for stable performance, it is important that you either have one reliable IP that will always host you or, if stable latency is less important, put multiple IPs in the list and set try_new_peers to true. This means the node will try connecting to the children of your root_node_ips if the root_node_ip is unavailable.

In reserved_peer_ips, you can specify which IPs are always allowed to connect to your node. This is how a Hyperliquid infrastructure provider can always allow you to connect. If you add an IP to this list, it will always be allowed to connect to your node.

The last part of this config is split_client_blocks. If you set this to true, you enable mempool streaming. Note that mempool streaming will only work if all upstream links also have this enabled. This can also be an advantage of peering with an infrastructure provider, because you can ensure the settings used by all nodes in your link.

The node binary hot-reloads the override_gossip_config, so there is no need to restart the node after changes to reserved_peer_ips, root_node_ips, or try_new_peers. split_client_blocks is determined during the connection greeting with your peer. Therefore, you can force the change by restarting the node, or wait until a connection drop or network upgrade — usually on Saturdays — for it to enable automatically.

If you rely on reserved_peer_ips because you are peering with an infrastructure provider, make sure to use an elastic IP.

Set up log pruning

With all log flags enabled, the logs produce about 80 GB/h. Therefore, it is important to set up a service that prunes the logs every couple of hours. The cloned Hyperliquid node GitHub repository includes a pruner that can be used for this.

Set up alerts

If alerting is important to you, you can create ~/hl/api-secrets.json for built-in Slack alerts.

{
"mainnet_slack_channel": "C0...", // if testnet you would name it testnet_slack_channel
"slack_key": "Bearer xoxb-.."
}

If you need more control over your alerts, you can consume the raw logs from stdout.

Ignoring alerts

Use ~/hl/file_mod_time_tracker/crit_msg_ignore.json to suppress specific alerts:

[
   {
       "until": "2025-04-30T00:00:00",
       "required_matches": [
           "example",
           "data"
       ]
   }
]

Every alert is checked against each rule in the list. An alert is ignored — not sent and not logged — if:

• the current time is before until
• all strings in required_matches appear somewhere in the alert text

Otherwise, the alert is sent as normal. With the rule above, example alert: data is ignored, but example alert is not, as it is missing data.

• Make sure to keep until short, as rules are meant to be temporary.
• Match strings that are specific enough to catch only the alert you mean. Broad matches can silence more than intended.
• An empty required_matches list matches everything and will silence all alerts.

Setting up the Hyperliquid node

First, clone the Hyperliquid node repository:

git clone <https://github.com/hyperliquid-dex/node.git>

Configure the chain

Choose whether you are running Mainnet or Testnet.

Mainnet

echo '{"chain": "Mainnet"}' > ~/visor.json

Testnet

echo '{"chain": "Testnet"}' > ~/visor.json

Download the visor

hl-visor manages the underlying hl-node process and upgrades.

Mainnet

curl <https://binaries.hyperliquid.xyz/Mainnet/hl-visor> > ~/hl-visor
chmod a+x ~/hl-visor

Testnet

curl <https://binaries.hyperliquid-testnet.xyz/Testnet/hl-visor> > ~/hl-visor
chmod a+x ~/hl-visor

Verify the binaries

The binaries are signed, and the signing public key is available in the Hyperliquid node repository.

Import the public key:

gpg --import pub_key.asc

Download the matching signature and verify it.

For Mainnet:

curl <https://binaries.hyperliquid.xyz/Mainnet/hl-visor.asc> > hl-visor.asc
gpg --verify hl-visor.asc hl-visor

Run the Hyperliquid non-validator node

The basic command to test that everything is set up properly is:

~/hl-visor run-non-validator

The node can take some time to navigate the Hyperliquid P2P network and find a parent.

Once you start seeing logs similar to:

applied block X

The node is receiving and processing live Hyperliquid L1 data.

‍