Hyperliquid Sentry Peering, Explained: How Dedicated Peers Change Node Operations
What Hyperliquid sentry peering is, why node operators need dedicated peers, how to configure your node, and how Quicknode's $500/month peering works.

August 19, 2026 — 9 min read

Hyperliquid sentry peering is a direct connection between a self-operated Hyperliquid non-validating node and dedicated sentry nodes, so the node receives blocks and the full mempool over stable, allowlisted peers instead of variable public root peers. It is the piece of running a Hyperliquid node that most teams struggle with, and the piece that determines whether your node's data is consistent enough to trade on.
This guide covers what sentry nodes are, why peering matters for market makers and node operators, every option for peering a node in 2026, and how Quicknode Hyperliquid Peering works at $500/month.
Hyperliquid's network has three tiers of participants:
Validators run HyperBFT consensus. They propose and vote on blocks. The active set is the top validators by stake, and validator IPs are not exposed to arbitrary peers.
Sentry nodes are non-validating nodes operated alongside validators. In the official node software, each validator can register up to two non-validator peers as sentry_ips. Sentries sit one hop from consensus, absorb public traffic, and shield the validator. They can serve as root peers, API servers, and EVM RPCs.
Non-validating nodes are permissionless. Anyone can run one by following the Hyperliquid node repository. A non-validating node replays every block, exposes local data streams, and can power a local API server for real-time fills, orders, and book state.
The catch: a non-validating node is only as good as its peers. Your node learns about new blocks and pending transactions through gossip, and gossip quality depends entirely on who you are connected to.
Standing up the node itself is well documented. Per the official requirements, a non-validating node needs 16 CPU cores, 128 GB RAM, a 500 GB SSD, Ubuntu 24.04, ports 4001 and 4002 open to the public, and ideally Tokyo placement, since that is where the validator set concentrates. The operational grind starts after applied block shows up in your logs.
Out of the box, your node connects to public root peers. You can query the current list at any time:
curl -X POST --header "Content-Type: application/json" \
--data '{ "type": "gossipRootIps" }' \
https://api.hyperliquid.xyz/infoPublic root peers are free, and they come with three problems:
They are shared and variable. Root peers rotate, saturate, and disconnect. Your block delivery inherits whatever load they happen to be under. The result is inconsistent latency, and in particular fat tail latency: the occasional block that arrives seconds late, which is exactly the block a trading system cannot afford to miss.
Most do not pass the mempool. Receiving pending transactions from a peer requires that peer to be configured to forward them. Arbitrary public peers usually are not. If your strategy needs pre-confirmation visibility, public gossip alone will not deliver it.
Recovery after disconnects is slow. When a public peer drops you, your node has to rediscover a healthy peer through gossip before block flow resumes.
The alternative the docs point to is the Foundation non-validating node, which offers a reliable peer with fewer hops to validators. Direct peer access to it, however, has required staking 10,000 HYPE and holding Tier 1 maker rebate status, defined as more than 0.5% of 14-day weighted maker volume, and it is offered on a best-efforts basis with no availability guarantees. For most teams, that is a non-starter.
That leaves dedicated sentry peering: a paid, allowlisted connection to professionally operated sentry nodes.
Sentry peering does not make your node faster than the rest of the network, and any provider claiming it puts you ahead of other participants is overselling. What it changes is the consistency of your connection:
Tight block delivery. A dedicated peer one hop from a validator delivers blocks on a predictable path. The improvement shows up most in tail latency: the worst-case delays that public gossip produces largely disappear when your peers are stable and unsaturated.
Full mempool delivery. Dedicated sentries can be configured to forward pending transactions, giving your node the raw mempool that public peers typically withhold.
Fast recovery. With multiple allowlisted peers across datacenters, a single disconnect does not interrupt block flow, and reconnection does not depend on gossip discovery.
Someone to call. Peering to operated infrastructure means a team monitors the sentry side of your connection.
For market makers, HFT systems, and any mempool-driven strategy on Hyperliquid, this is the difference between a node you can trade on and a node you babysit.
Quicknode Hyperliquid Peering is a flat-priced sentry peering service for teams running their own non-validating node.
Specification | Detail |
|---|---|
Sentry peer IPs | 3, dedicated |
Regions | Multiple datacenters, Tokyo |
Mempool | Full, no separate usage meter |
Observed mempool volume | ~1.1 TB/day, varies with activity |
Node type supported | Non-validating |
A few details worth calling out:
The peers are sentries, not validators. You connect to non-validating sentry nodes that are themselves connected to a validator. Your peers do not participate in consensus, and peering involves no staking or delegation. Quicknode’s own non-validating nodes, the ones behind its managed Hyperliquid endpoints, peer through the same sentry layer.
The mempool is unmetered. At roughly 1.1 TB/day of observed raw mempool volume, per-GB pricing gets expensive fast. Quicknode includes full mempool delivery in the flat $500 with no separate usage meter.
Provisioning is manual by design. Allowlisting is per IP. A Quicknode engineer reviews each request, allowlists the node, and returns all three peer IPs with configuration guidance. There is no staking requirement, no volume threshold, and no application review of whether your firm is large enough.
Public root peers | Foundation non-validating node | Quicknode Hyperliquid Peering | |
|---|---|---|---|
Cost | Gratuit | Free, with requirements | $500/month plus active plan |
Requirements | Aucun | 10,000 HYPE staked, Tier 1 maker rebates | Active Quicknode plan |
Subscribe. Create a Quicknode account, then open Add-ons in your Quicknode dashboard and select the Hyperliquid Peering add-on to subscribe at $500/month. The subscription is charged at checkout, with a 7-day evaluation window from activation.
Send your node details. Email support@quicknode.com with your account email and your node's public IP.
Receive your peers. An engineer allowlists your node and returns all three sentry peer IPs with configuration guidance.
Configure and verify. Add the peer IPs to ~/override_gossip_config.json and set split_client_blocks: true. Pending transactions then stream to ~/hl/data/mempool_txs/ on your server. This is the standard Hyperliquid node mechanism, not a custom interface, so nothing about your tooling changes.

During the 7-day window, measure what matters: block latency distribution including p95 and p99, recovery time after forced disconnects, and sustained mempool delivery during volatile periods. If stability does not meet your requirements, contact support within the window for a prorated refund.
Before enabling mempool delivery, check three things on the node host: inbound bandwidth headroom for 1.1+ TB/day, disk capacity and a retention policy for ~/hl/data/mempool_txs/, and log rotation, since a Hyperliquid node already produces heavy daily log output on its own.
The honest question is whether you want a node, or the data from a node.
Running your own non-validating node means a serious server, Tokyo placement, heavy daily log management, and a 24/7 operations commitment. If your team has already made that commitment, peering solves the hardest remaining problem. If you have not, a managed Quicknode Hyperliquid endpoint delivers blocks, trades, and transactions over JSON-RPC, WebSocket, gRPC, and Streams with instant self-serve setup and no node to operate.
Hyperliquid Peering | Managed Hyperliquid endpoint | |
|---|---|---|
You run the node | Oui | Non |
You connect to | 3 dedicated sentry peer IPs | Managed API endpoint |
Mempool | Full, unmetered | Via gRPC |
Setup |
Hyperliquid sentry peering is a direct, allowlisted connection between a Hyperliquid non-validating node you operate and dedicated sentry nodes, delivering blocks and the full mempool over stable peers instead of variable public root peers. Quicknode offers it at $500/month for 3 dedicated peer IPs across multiple Tokyo datacenters.
Yes. Peering only helps if you already operate a Hyperliquid non-validating node. If you want Hyperliquid data without running infrastructure, use a managed Hyperliquid endpoint instead.
Per the official repository: 16 CPU cores, 128 GB RAM, a 500 GB SSD, and Ubuntu 24.04, with ports 4001 and 4002 open to the public. Tokyo placement is recommended for lowest latency to the validator set.
Your node must peer with a sentry configured to forward pending transactions, with split_client_blocks: true set in ~/override_gossip_config.json. Transactions then stream to ~/hl/data/mempool_txs/. Public root peers typically do not forward mempool data; Quicknode sentry peers are configured for it, with no separate usage meter.
Quicknode Hyperliquid Peering is $500/month flat, including 3 dedicated sentry peer IPs, full unmetered mempool delivery, and a 99.99% uptime SLA. An active Quicknode plan is required. Peering to the Foundation non-validating node is free but has required 10,000 HYPE staked and Tier 1 maker rebate status.
No. Peering gives you a reliable, redundant path to blocks and the full mempool. It does not put you ahead of other network participants, and actual latency depends on where your node runs and your network path to the peers.
Across multiple datacenters in the Tokyo region, where Hyperliquid's validator set concentrates. All three peer IPs are shared after activation.
Allowlisting is per IP, so email support with the new address, ideally ahead of a planned migration, and the allowlist gets updated.
If you operate a Hyperliquid non-validating node and need dedicated peers, full mempool, and an SLA someone actually monitors, Hyperliquid Peering is live now. Create an account, add the Hyperliquid Peering add-on, send your node’s public IP, and an engineer will have you peered with all three sentries. Not running a node? Start with a managed Hyperliquid endpoint instead.
Fondée en 2017, Quicknode une infrastructure blockchain de niveau institutionnel destinée aux développeurs et aux entreprises. Grâce à une disponibilité de 99,99 % et à la prise en charge de plus de 80 chaînes, les équipes peuvent développer et faire évoluer leurs applications sur la blockchain sans aucun compromis.
Les dernières actualités en matière d'ingénierie, les mises à jour sur les produits et les nouvelles du Web3, directement dans votre boîte mail.
99.99%, monitored and alerted |
Assistance | Direct engineer email, APAC coverage |
Price | $500/month, active Quicknode plan required |
Activation | Manual, engineer-provisioned |
Evaluation | 7 days from activation, prorated refund |
Variable, shared |
Best-efforts, no guarantees |
99.99% SLA, monitored |
Full mempool | Usually not forwarded | Depends on configuration | Included, unmetered |
Redundancy | Gossip discovery | Single peer target | 3 IPs across datacenters |
Assistance | Aucun | Aucun | Direct engineer, APAC hours |
Manual, engineer-provisioned
Self-serve, instant |
Idéal pour | Market makers, HFT, own-node operators | dApps, bots, analytics, indexers |
Vous exploitez un nœud « Hyperliquid » ?Activez un chemin direct pour les blocs et le mempool complet grâce au peering « Hyperliquid ».
En savoir plusCertifié SOC 2 Type II · ISO 27001