How to Run a Hyperliquid Non-Validating Node: Costs, Setup, and When to Rent Peering

A Hyperliquid non-validating node is only as current as the peer that feeds it. On Mainnet it will not start syncing until you give it at least one peer IP in ~/override_gossip_config.json, and the free community peers it can use are shared, change often, and fill up. Below: what a node gives you and costs, how peering works, a step-by-step setup, and when to rent peering or skip the node.

Every command below comes from the official hyperliquid-dex/node README (checked at commit 405cc08b1, 10 August 2026). If the README has changed since, follow the README.

The short answer

If you only need RPC access and no node of your own, start with how to get a Hyperliquid RPC node. This guide is for teams that want to run the node themselves.

If you want the node's raw files on your own disk, run a node and give it a peer you can rely on. If you want the data and not the node, a managed endpoint is cheaper once you count engineering time.

Why run a Hyperliquid non-validating node

A non-validating node streams committed blocks from peers and executes them locally. It does not vote in consensus, and anyone can run one.

Raw protocol data on your own disk

The node writes blocks to ~/hl/data/replica_cmds and state snapshots every 10,000 blocks to ~/hl/data/periodic_abci_states. Output flags add more: --write-fills for fills and TWAP statuses, --write-order-statuses for every order status, --write-raw-book-diffs for every L1 order diff, plus trades, misc events, HIP-3 oracle updates and CoreWriter actions.

A local Info server without public rate limits

--serve-info starts a server at http://localhost:3001/info. The public API allows an aggregate weight of 1,200 per minute per IP, and most Info requests weigh 2 or 20 (Hyperliquid rate limits). The local server answers clearinghouseState, openOrders, meta, spotClearinghouseState, userFees, exchangeStatus and 23 more request types from local state. It does not serve l2Book, historical time series or WebSockets. --serve-eth-rpc adds a HyperEVM JSON-RPC at http://localhost:3001/evm, against the public 100 requests per minute.

Order book reconstruction

hl-node compute-l4-snapshots builds full L4 books (every resting order) from a state snapshot, and the Info server can write a fresh l4Snapshots file from current state. Hyperliquid's latency guide recommends building the book on the same machine as the node, and points to its order_book_server example, which it notes is not actively maintained.

The mempool

With split_client_blocks: true, the node writes uncommitted transactions to ~/hl/data/mempool_txs/{date}. Hyperliquid puts the gain at 70 to 150 ms on input reads, but only if every peer between your node and the validators has the setting enabled.

Lower read latency

With --disable-output-file-buffering, the node flushes each line as soon as it writes it, and a bot on the same host reads the files or the local server directly.

What a node costs to run

Hardware

A production-grade Hyperliquid node on AWS Tokyo costs at least $3,500 a month all-in, by Dwellir's estimate from running Hyperliquid nodes. That covers an instance with the cores, RAM and fast NVMe a production node needs, plus bandwidth, storage and monitoring. An instance priced near the minimum spec above runs the node, but it is not production grade, and the instance is only part of the bill. The disk growth and bandwidth sections below explain why the other lines are large.

If you use NVMe instance storage, it is lost when the instance stops, so the node resyncs from peers after a stop.

Bare metal

Rented bare metal has no single price. The monthly figure depends on:

• The provider and the data center. For the lowest latency the node belongs in Tokyo, and not every provider has capacity there.
• The CPU and RAM. The latency guide's 32 cores cost more than the README's 16 vCPUs.
• Disk. Retention for raw output files can need several TB of NVMe, not 500 GB.
• Bandwidth. Some providers include transfer and some meter it, and a node with every feed enabled moves terabytes a day.
• Monitoring and redundancy. A second node for failover doubles the server line.

Get quotes for the exact spec and transfer volume you plan to run, and compare them with the AWS all-in figure, not the instance price.

A validator node

A validator has a capital cost on top of the server. Hyperliquid requires each validator to self-delegate 10,000 HYPE to become active, and that self-delegation is locked for one year (Hyperliquid staking docs). The active set is the top 27 validators by stake (Running a validator), so 10,000 HYPE makes a validator eligible. It does not guarantee a place in the set. If you only need data, a non-validating node needs no stake.

Disk growth

The README says that on default settings the node writes about 100 GB of logs a day. Output flags multiply that. With every data type written to disk, a Dwellir node writes about 2.6 TB a day (Dedicated Node Clusters), and QuickNode reports about 1.1 TB a day of raw mempool output alone. At those rates a 500 GB disk fills within hours, so set up pruning before the node goes live.

Bandwidth

With ports 4001 and 4002 open, your node also serves other peers. Mempool delivery alone is about 1.1 TB a day of inbound gossip, by QuickNode's measurement. Check what your host charges for transfer before you enable every feed.

Operations time

Engineering time never shows up on the server invoice. hl-visor upgrades the node binary automatically, and a network upgrade restarts every non-validator at the same block height. The public issue tracker shows what operators hit in the months up to November 2026:

• A node stays pinned to a peer that delivers blocks far below chain rate, with no timeout, and falls behind indefinitely (#156).
• Crashes 6 to 12 times a day on one binary, each costing 15 to 25 minutes of output gaps (#160).
• Memory growing 10 to 12 GiB an hour until the visor restarts the node (#173).
• A Tokyo node stuck for 3 days because every peer answered Peer full to its state request (#179).
• After the 31 October 2026 upgrade, two nodes stalled for about an hour while every non-validator asked the same peers for a 1.32 GB snapshot at once (#185).

Three of the five (#156, #179 and #185) are peer problems, which is the part a reserved peering slot addresses.

How Hyperliquid gossip peering works

Validators run HyperBFT consensus. Non-validating nodes receive blocks by gossip on ports 4001 and 4002. If those ports are not open to the public, peers deprioritize your node's IP.

Your node finds its upstream through ~/override_gossip_config.json:

Where peers come from

There are four sources.

Community root peers. The README lists 25 root IPs run by validator teams such as ASXN, Nansen x HypurrCollective, Hypurrscan, Luganodes and others. 20 of the 25 are in Japan, with the rest in South Korea, Singapore and Germany. Hyperliquid also returns a current list from the API:

curl -X POST --header "Content-Type: application/json" \
  --data '{ "type": "gossipRootIps" }' \
  https://api.hyperliquid.xyz/info

These are free and shared, and the list changes: the two most recent commits (30 July and 10 August 2026) removed inactive root peers.

Validator sentries. A validator can connect up to two non-validator peers by listing them as sentry_ips in its node config. The README says sentries should be run by the validator themselves, and can serve as public root peers, API servers and EVM RPCs. You do not become a sentry by buying peering. Your node stays an ordinary non-validator.

The Hyper Foundation non-validating node. The Foundation runs a best-efforts node in AWS apne1-az1 for peers that want fewer hops to validators. To qualify you must have 10,000 HYPE staked, be Tier 1 or above in maker rebate tiers (more than 0.5% of 14-day weighted maker volume), and keep 98% time-weighted uptime. There is no availability guarantee.

Peering providers. The Foundation lists 16 infrastructure providers that sell peering, including Dwellir, QuickNode, Alchemy and Hydromancer. To be listed, a provider commits to 99.9% uptime, open access with non-discriminatory pricing (the current benchmark is under $1,000 a month), and no preferential treatment of specific clients such as market makers.

Why Tokyo

The README: "For lowest latency, run the node in Tokyo, Japan." The Foundation node is in AWS Tokyo, and 20 of 25 community root peers are in Japan. A node in Frankfurt or Virginia adds network distance to every block it receives, and a bot reading from it inherits that delay.

Set up a non-validating node with peering

This walkthrough runs Mainnet on a fresh Ubuntu 24.04 host in Tokyo, with a static public IPv4 address.

1. Open the gossip ports

sudo ufw allow 4001:4002/tcp

Open the same ports in your cloud provider's firewall or security group.

2. Configure the chain and download the visor

hl-visor spawns and manages the hl-node process, and handles binary upgrades.

echo '{"chain": "Mainnet"}' > ~/visor.json
curl https://binaries.hyperliquid.xyz/Mainnet/hl-visor > ~/hl-visor && chmod a+x ~/hl-visor

3. Verify the binary signature

Import Hyperliquid's public key from the node repo, then check the signature:

curl -sSL https://raw.githubusercontent.com/hyperliquid-dex/node/refs/heads/main/pub_key.asc -o ~/pub_key.asc
gpg --import ~/pub_key.asc
cd ~ && curl https://binaries.hyperliquid.xyz/Mainnet/hl-visor.asc > hl-visor.asc
gpg --verify hl-visor.asc hl-visor

After this, hl-visor verifies every hl-node binary it downloads and refuses to upgrade if verification fails.

4. Point the node at its peers

With community peers, take IPs from the README table or the gossipRootIps call above:

{
  "root_node_ips": [{ "Ip": "<ROOT_PEER_1>" }, { "Ip": "<ROOT_PEER_2>" }],
  "try_new_peers": true,
  "chain": "Mainnet",
  "reserved_peer_ips": []
}

With rented peering, use the peer IPs your provider sends you and turn off discovery so the node never falls back to a random public peer. This is the Dwellir configuration from the peering docs:

{
  "root_node_ips": [{ "Ip": "<DWELLIR_PEER_1>" }, { "Ip": "<DWELLIR_PEER_2>" }, { "Ip": "<DWELLIR_PEER_3>" }],
  "try_new_peers": false,
  "chain": "Mainnet",
  "reserved_peer_ips": [],
  "split_client_blocks": true
}

Save it as ~/override_gossip_config.json. Leave out split_client_blocks if you do not need the mempool, since it adds a large daily write volume.

5. Start the node

The minimal command is:

~/hl-visor run-non-validator

For a trading setup, add the outputs your bot reads and the local servers:

~/hl-visor run-non-validator \
  --write-fills \
  --write-order-statuses \
  --disable-output-file-buffering \
  --serve-info \
  --serve-eth-rpc

To run it as a service, the repo's README_misc.md gives a systemd unit. Create /etc/systemd/system/hl-visor.service, replacing USERNAME:

[Unit]
Description=HL-Visor Non-Validator Service
After=network.target

[Service]
Type=simple
User=USERNAME
WorkingDirectory=/home/USERNAME
ExecStart=/home/USERNAME/hl-visor run-non-validator
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Add your flags to ExecStart, then:

sudo systemctl enable hl-visor.service
sudo systemctl start hl-visor

The repo also ships a Dockerfile and docker-compose.yml. Note that the Dockerfile is configured for Testnet by default.

6. Verify the node is syncing and connected

The first sync takes a while. The node has to find a peer that accepts it and receive a state snapshot before it can follow the chain.

Watch for applied blocks. Logs such as applied block X mean the node is streaming live data:

journalctl -u hl-visor -f

Check that block files are fresh. The newest file under replica_cmds should be seconds old:

find ~/hl/data/replica_cmds -type f -newermt '-1 minute' | tail -5

Compare local and L1 time. If you run --serve-info, the README suggests polling exchangeStatus and comparing the L1 timestamp with your local one:

curl -s -X POST --header "Content-Type: application/json" \
  --data '{"type": "exchangeStatus"}' http://localhost:3001/info

Confirm which peers you are connected to. List established gossip connections and check the remote IPs against your peer list:

ss -tn state established '( dport = :4001 or dport = :4002 or sport = :4001 or sport = :4002 )'

With try_new_peers: false, you should see only the peers you listed, plus any inbound connections from other nodes.

Check the mempool. If you set split_client_blocks, new files should appear under ~/hl/data/mempool_txs/.

If the node does not advance, read the crash logs in ~/hl/data/visor_child_stderr/{date}/ and the status logs in ~/hl/data/node_logs/status/.

7. Prune before the disk fills

The repo's pruner container runs daily at 03:00 and deletes files in ~/hl/data older than 48 hours, except visor_child_stderr. If you run without Docker, a cron job with the same find ... -mmin +2880 -delete logic does the job. Pick the retention window from your disk size and from whether your consumers have already read the files.

Run your own, rent peering, or use a provider

Self-hosted figures use the all-in AWS Tokyo minimum of $3,500 a node (instance, bandwidth, monitoring and storage) and exclude engineering time. Bare metal can cost more or less, depending on the provider and setup.

Pick your own node with rented peering when you need the raw files locally (fills, order statuses, book diffs, mempool) at the lowest latency your hardware allows, and you already have someone on call for the node. The $500 removes the most common failure, a lost or degraded peer, but not the rest of the list above.

Pick a Dedicated Node Cluster when the feed matters to your business but you do not want to run nodes. One self-hosted node on AWS with peering already costs at least $4,000 a month all-in, the price of a 2-node cluster, before anyone's time. Firms that need the lowest possible latency and the best p99 in the industry can move to a high-performance dedicated cluster at $10,000 to $20,000 a month. See when a cluster pays off.

Pick a shared API when you want HyperCore data, order books or HyperEVM RPC and your volume fits a plan. Dwellir's Order Book WebSocket had a median of 177 ms against 282 ms for the public API on the L2 book in the Tokyo latency benchmark.

Peering providers side by side

QuickNode's figures are from its peering page and setup guide, checked 3 November 2026. The setup guide also ships a Docker Compose repository with verification and pruning scripts, which is a good reference even if you peer elsewhere.

Where Dwellir fits

Dwellir's three Hyperliquid peers run in Tokyo, and they are the same peers Dwellir's own nodes use. Dwellir sells slots on them as Hyperliquid Peering.

You send the static public IP of your node. Dwellir adds it to reserved_peer_ips on all three peers and returns three peer addresses. Your node connects to one at a time and fails over to the others. One slot costs $500 a month, billed monthly, and each extra node needs its own slot and its own static IP.

The peers carry blocks and the full mempool, the same stream Dwellir's own nodes consume, with no bandwidth or egress charges. The SLA is 99.9% uptime per calendar month, measured on gossip reachability from outside Dwellir's network, and maintenance is announced at least 48 hours ahead. Every subscriber gets the same peers, configuration and priority, and Dwellir's own infrastructure runs on the same terms.

All three peers are in Tokyo on separate hosts. A single host failure leaves you two peers, but there is no peer outside Tokyo to fail over to.

Dwellir is on the Hyper Foundation's list of peering providers. To request a slot, email support@dwellir.com or DM @dwellirgrowth on Telegram with your node IP and region. Subscribers get a shared Telegram or Slack Connect channel with the team.

If you only need the mempool and not a node, StreamMempoolTxs over gRPC delivers it on a Dwellir API key. In a 15-minute Tokyo test, it showed 95.7% of 427,020 matched orders before the public WebSocket, with a median lead of 357 ms.

Frequently asked questions

What is Hyperliquid peering?

Peering is the gossip connection your Hyperliquid non-validating node uses to receive blocks and, if configured, mempool transactions. You list peer IPs in ~/override_gossip_config.json. Paid peering means a provider reserves a slot for your node's IP on peers it operates, so your node does not compete for oversubscribed public root peers.

Do I need peering to run a Hyperliquid non-validating node?

You need at least one peer. On Mainnet, the hl-node README requires at least one IP in ~/override_gossip_config.json. You can use free community root peers from the README or the gossipRootIps API, apply for the Hyper Foundation's node if you meet its staking and maker-volume requirements, or rent a reserved slot from a peering provider.

How much does Hyperliquid peering cost?

Dwellir and QuickNode both charge $500 a month per peering slot. Dwellir's slot allowlists one node IP on three Dwellir peers in Tokyo with a 99.9% uptime SLA. QuickNode's includes three sentry peer IPs with a 99.99% SLA and requires an active QuickNode plan. Community root peers are free, and the Hyper Foundation's benchmark price for listed peering providers is under $1,000 a month.

What hardware does a Hyperliquid non-validating node need?

The official README lists 16 vCPUs, 128 GB RAM, a 500 GB SSD and Ubuntu 24.04, with ports 4001 and 4002 open to the public. For latency-sensitive reads, Hyperliquid's latency guide recommends at least 32 logical cores, 128 GB RAM and 500 MB/s disk throughput. Plan disk for about 100 GB of logs a day on default settings, and much more with extra output flags.

How do I run my trading bot next to a Hyperliquid node?

Run a non-validating node in Tokyo, enable the outputs your bot reads (for example --write-fills and --disable-output-file-buffering), and run the bot on the same machine or in the same datacenter so it reads node files or the local Info server at localhost:3001. Give the node a reliable peer, because the bot can only be as current as the node.

Where should I run a Hyperliquid node for the lowest latency?

In Tokyo. The hl-node README says to run the node in Tokyo for the lowest latency, the Hyper Foundation's own non-validating node runs in AWS apne1-az1, and 20 of the 25 community root peers listed in the README are in Japan.

How much does it cost to run a Hyperliquid node?

On AWS in Tokyo, a production-grade node costs at least $3,500 a month all-in, including the instance, bandwidth, monitoring and storage. On rented bare metal the cost depends on the provider, hardware, disk and transfer pricing. Rented peering adds $500 a month per node IP. A validator also needs 10,000 HYPE of self-delegated stake. Dwellir's Dedicated Node Cluster costs $4,000 a month for 2 nodes, and high-performance dedicated clusters cost $10,000 to $20,000 a month.

Does peering make my Hyperliquid node faster than other traders?

No. Peering gives your node a stable, reserved upstream and, with split_client_blocks enabled on every hop, the mempool. Dwellir's peering terms state that every subscriber gets the same peers, configuration and priority. Your latency still depends on where your node runs and how fast your hardware executes blocks.

What is the difference between peering and a Dedicated Node Cluster?

With peering you run the node yourself and Dwellir supplies the peers, for $500 a month per node IP on top of your own server costs. With a Dedicated Node Cluster, Dwellir runs the nodes for you, for $4,000 a month with 2 nodes, and includes HyperEVM JSON-RPC, Info endpoints, unmetered gRPC and Order Book access, and the same peering. High-performance dedicated clusters, built for firms that need the lowest possible latency and the best p99 in the industry, cost $10,000 to $20,000 a month.

Next steps

• Hyperliquid Peering docs: requirements, setup and SLA
• Hyperliquid pricing: API plans, add-ons, peering and clusters
• Hyperliquid architecture: consensus, API servers and non-validating nodes
• hyperliquid-dex/node: the official node README

Running your own node already and losing sync to public peers? Request a peering slot. Want the data without the node? Talk to the Dwellir team about a Dedicated Node Cluster.