Hyperliquid RPC Node Setup Guide (2026) | QuiverCrypto

Hyperliquid has established itself as one of the most actively traded on-chain perpetuals platforms, consistently recording multi-billion-dollar daily volume on its own Layer 1 chain. For developers building on top of the network—or power users who want a trustless, low-latency connection to chain data—running a self-hosted RPC node is the gold standard. This guide covers what an RPC node does, what hardware you need, how to get the node software running, how to sync, and how to expose a secure endpoint for your applications.

If you are new to the project, start with our primer Hyperliquid Explained: HYPE, Vaults and How It Works before continuing here.

What Is an RPC Node?

A Remote Procedure Call (RPC) node is a full participant in a blockchain network that exposes an API endpoint. Applications—wallets, bots, dashboards, smart contract frontends—send JSON-RPC (or HTTP/WebSocket) requests to this endpoint to read chain state, broadcast transactions, and subscribe to events, without trusting a third party.

Unlike a validator node, which actively participates in consensus by proposing and signing blocks, an RPC node is read-heavy and non-validating. It syncs every block, maintains a full copy of the ledger, and answers queries. This distinction matters for hardware sizing and operational responsibility—validating carries slashing risk and requires near-continuous uptime; an RPC node can be restarted without protocol-level penalties.

For teams that prefer a managed solution, our guide to the Best RPC Node Providers for Web3 Developers (2026) covers hosted alternatives. But self-hosting gives you full data sovereignty, no rate limits, and a private endpoint that cannot be censored or throttled by a third-party provider.

Why Run Your Own Hyperliquid RPC Node?

Zero rate limits. Public endpoints are shared infrastructure. A self-hosted node handles only your traffic.
Lower latency. Co-locating your node close to your application eliminates a network hop to an external provider.
Privacy. Every query you send to a third-party RPC leaks metadata about your addresses and strategies.
Trustlessness. You verify chain state yourself rather than relying on a provider’s attestation.
Arbitrage and MEV research. High-frequency strategies require sub-second block data and mempool access that only a local node reliably provides. Hyperliquid’s non-validating node supports a split_client_blocks option in the gossip config for streaming uncommitted mempool transactions.

Hardware and OS Requirements

Hyperliquid’s L1 is designed for high throughput, processing order-book trades with sub-second latency while settling on-chain. The chain accumulates state quickly, so storage planning is critical. The following specifications reflect community node-operator experience; always check the official Hyperliquid node documentation for any authoritative updates:

Component	Minimum	Recommended
CPU	8 cores (x86-64)	16+ cores, high single-thread clock
RAM	32 GB	64–128 GB
Storage	4 TB NVMe SSD	8 TB+ NVMe SSD with log pruning
Network	1 Gbps	2.5–10 Gbps, low latency
OS	Ubuntu 22.04 LTS	Ubuntu 22.04 LTS or Debian 12

Storage note (critical): With default settings, the Hyperliquid node can generate on the order of 100 GB of data per day (per the hyperliquid-dex/node README). A 4 TB drive fills in roughly five to six weeks without pruning configured. Set up log rotation and data pruning before starting the node, and use a storage solution that supports online expansion—RAID or a cloud block device—to avoid a forced resync.

Hyperliquid nodes are distributed as pre-compiled Linux binaries. Windows and macOS are not officially supported for production deployments.

Before You Begin: Prerequisites

Before downloading the node software, ensure the following are in place:

A provisioned bare-metal or VPS server meeting the specs above. Popular choices among node operators include Hetzner dedicated servers, OVHcloud, and AWS i4i instances for NVMe throughput.
A non-root user with sudo access. Running blockchain software as root is a security anti-pattern.
UFW or iptables firewall configured. Open only the ports your node needs and nothing else.
System clock synchronisation via NTP or chrony. Consensus protocols are sensitive to clock drift; Hyperliquid’s HyperBFT-based consensus engine is no exception.
Sufficient swap space (optional but recommended). 16–32 GB of swap reduces the risk of OOM kills during peak sync load.

# Verify NTP is running
timedatectl status

# Install chrony if not present
sudo apt install chrony -y
sudo systemctl enable --now chrony

Step-by-Step: Setting Up Your Hyperliquid RPC Node

1. Download the Node Binary

Hyperliquid distributes its node software through the official GitHub repository at github.com/hyperliquid-dex/node. The primary binary is called hl-visor—a supervisor process that downloads and manages the underlying node software. Always fetch binaries from the official source and verify checksums before executing anything.

# Create a dedicated working directory
mkdir -p ~/hl-node && cd ~/hl-node

# Download the hl-visor binary
# Check the releases page at github.com/hyperliquid-dex/node for the current download URL
wget <official-download-url-from-releases-page> -O hl-visor

# Verify the SHA256 checksum against the release notes
sha256sum hl-visor

# Make executable
chmod +x hl-visor

Always check github.com/hyperliquid-dex/node for the current release and download URL before proceeding. Do not rely on community-re-hosted binaries.

2. Configure the Node

Hyperliquid’s non-validating node is primarily driven by command-line flags rather than a monolithic config file. Advanced options—such as enabling split_client_blocks to stream uncommitted mempool transactions—are applied via an optional override_gossip_config.json file placed in the working directory. Consult the official documentation for supported keys and current defaults.

For a standard RPC node, no config file is required to get started.

3. Provision the Data Directory

sudo mkdir -p /data/hyperliquid
sudo chown $USER:$USER /data/hyperliquid

Store chain data on your NVMe volume. If your NVMe is mounted at /data, you are already set. If not, mount it there before proceeding.

4. Run the Node and Begin Syncing

The command to start a non-validating RPC node is:

./hl-visor run-non-validator

To enable the EVM-compatible JSON-RPC endpoint—required for tooling such as ethers.js or viem—pass the --evm flag:

./hl-visor run-non-validator --evm

Log entries such as applied block X confirm the node is receiving and processing live blocks. The node may take a few minutes to locate a suitable peer before syncing begins.

For production, wrap the process in a systemd unit so it restarts automatically on failure:

# /etc/systemd/system/hyperliquid.service
[Unit]
Description=Hyperliquid RPC Node
After=network-online.target

[Service]
User=hlnode
WorkingDirectory=/home/hlnode/hl-node
ExecStart=/home/hlnode/hl-node/hl-visor run-non-validator --evm
Restart=on-failure
RestartSec=5s
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now hyperliquid
journalctl -u hyperliquid -f   # Follow logs

Syncing the Chain

Initial sync downloads and verifies every historical block. Depending on network speed and disk throughput, full sync can take anywhere from several hours to a few days on mainnet. Monitor progress by tailing the logs and watching the block height increment.

Many node operators use a snapshot to accelerate sync. If the Hyperliquid team or community provides trusted snapshots—check the official Discord and documentation—you can restore a recent snapshot to the node’s working data directory before starting the node, skipping months of historical sync. Always verify snapshot integrity via checksums before use.

For a comparable walkthrough on another high-throughput L1, see our guide How to Run an Avalanche (AVAX) Node, which covers similar patterns for snapshot-assisted syncing and systemd process management.

Exposing and Securing the RPC Endpoint

Never expose a raw RPC port directly to the internet. Instead, place Nginx or Caddy in front of your node as a reverse proxy with TLS termination.

Nginx example (illustrative):

server {
    listen 443 ssl;
    server_name rpc.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/rpc.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rpc.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Consult the official Hyperliquid documentation for the exact port your build listens on, as it can differ between releases.

Additional hardening steps:

Rate limiting at the proxy layer (limit_req_zone in Nginx) to prevent abuse.
Firewall rules that restrict the RPC port to localhost only; all external traffic enters through port 443.
API key authentication if you are sharing the endpoint across a team—Nginx’s auth_request module or a lightweight API gateway can enforce this.
OS hardening. An RPC node does not hold private keys, but a compromised host could serve manipulated data. Use fail2ban, disable password SSH login, and keep packages updated.

Security hygiene for infrastructure is not unlike the attack surfaces covered in our guide DeFi Bridge Exploits Explained: How They Happen—trust assumptions at the infrastructure layer can be just as dangerous as protocol-level vulnerabilities.

Validator vs. RPC Node: Key Differences

	RPC Node	Validator Node
Participates in consensus	No	Yes
Signs blocks	No	Yes
Slashing risk	None	Yes (double-sign, downtime)
Stake required	None	Yes (HYPE tokens bonded)
Uptime criticality	High (for your apps)	Extremely high (protocol-level)
Hardware intensity	High (storage/RAM)	Very high (storage/RAM + CPU)

Running a validator requires bonding HYPE, maintaining near-100% uptime, and operating with redundant infrastructure. If your goal is simply to query chain data reliably, a non-validating RPC node is the right choice. Hyperliquid’s official documentation also notes that successfully running a non-validating node is a prerequisite for any operator who later wishes to run a validator.

Monitoring and Maintenance

A production RPC node is not a set-and-forget deployment. Build monitoring around:

Block height lag — alert if your node falls more than a handful of blocks behind the chain tip.
Disk usage — given the aggressive data growth rate, set alerts at 60% and 75% capacity so you have adequate lead time to expand storage before the node crashes.
Log rotation — configure a log rotation strategy before starting the node. With default settings, data accumulates at roughly 100 GB per day; without rotation this will exhaust even large disks within weeks.
Process health — systemd restarts the node on crash, but you want to know when restarts happen.
Prometheus + Grafana — check the official repository for whether your node version exposes a metrics endpoint, then scrape it for RPC response latency, peer count, and memory usage.

Run apt upgrade regularly and subscribe to the Hyperliquid GitHub repository’s release notifications so you apply node software updates promptly. Client bugs and security patches are released without warning.

Key Takeaways

An RPC node gives your application trustless, rate-limit-free access to Hyperliquid chain data without participating in consensus or risking slashed stake.
Hardware requirements are substantial: plan for at least 32 GB RAM and 4 TB NVMe SSD with log pruning configured; storage can grow by roughly 100 GB per day with default settings.
Download the official hl-visor binary from the hyperliquid-dex/node repository and verify checksums before running.
Start a non-validating node with hl-visor run-non-validator; add --evm to enable the EVM-compatible RPC endpoint.
Use systemd to manage the node process and ensure automatic restarts.
Never expose the raw RPC port to the internet; always front it with a TLS-terminating reverse proxy.
Snapshot-assisted sync can dramatically reduce initial sync time; verify snapshot integrity before restoring.
Monitor disk usage continuously—chain history grows fast on a high-throughput L1 like Hyperliquid.
If self-hosting is too operationally intensive, managed providers are a viable alternative (see our Best RPC Node Providers for Web3 Developers (2026) guide).

Last updated: June 2026