How to get a Hyperliquid RPC endpoint for perps trading (2026 guide)

TL;DR

Point a perps bot at the public Hyperliquid endpoint and it dies at the 101st request of the minute — HyperEVM caps shared RPC at 100 requests per minute, and on Hyperliquid that ceiling arrives in the time it takes to poll one order book twice. The deeper trap is structural: order submission lives on HyperCore’s /exchange API, which non-validator nodes physically cannot serve, so a single endpoint never covers a trading stack. This guide shows how to wire low-latency market data and order flow across HyperCore and HyperEVM the way a profitable perps bot actually needs them.

What is a Hyperliquid RPC endpoint

A Hyperliquid RPC endpoint is not one thing — it is the entry point into two execution layers that share one consensus. HyperCore is a Rust-based order-book engine that settles perps, spot, margin, and liquidations with roughly 0.2-second finality, and it speaks a REST/WebSocket API model (/info for reads, /exchange for trading actions) rather than Ethereum JSON-RPC. HyperEVM is the EVM-compatible layer on chain ID 999, where Solidity contracts run against standard eth_* JSON-RPC and can read HyperCore state directly through precompiles. A perps trading endpoint, in practice, means routing the right call to the right layer.

For a Hyperliquid perps stack, the endpoint is what every part of the trade loop depends on:

• Reading L2 order book snapshots, mids, and funding rates from HyperCore /info
• Streaming live fills, order updates, and trades over the HyperCore WebSocket
• Submitting orders, cancels, and leverage changes through /exchange (validator-gated)
• Querying HyperEVM contract state with eth_call for vaults and on-chain strategy logic
• Pulling eth_getLogs and event history for HyperEVM DeFi positions built on top of perps

You can review the full request and subscription model in the Hyperliquid HyperEVM developer documentation.

On a perps venue clearing billions in daily volume, endpoint quality is the difference between a fill at your price and a fill at the next tick — a market-data feed that lags 300ms means your bot is trading against a book that no longer exists.

How Hyperliquid RPC differs from Ethereum RPC

Hyperliquid is EVM-compatible on HyperEVM, so the JSON-RPC surface will feel familiar — but the differences that matter for trading are exactly the ones that break naive ports from Ethereum tooling.

Property	Ethereum	Hyperliquid
Block model	Single ~12s blocks	HyperEVM dual blocks: fast small blocks (~1s) + infrequent big blocks (~1min) for gas-heavy deploys
Finality	~13 minutes (2 epochs)	Sub-second via HyperBFT (~0.2s on HyperCore)
Gas token	ETH	HYPE
Consensus	Gasper PoS	HyperBFT
Order book / trading	Off-chain or AMM contracts	Native on-chain order book on HyperCore, outside the EVM
WebSocket on JSON-RPC	Common	None on public HyperEVM JSON-RPC; real-time data lives on the HyperCore WS

The decisive difference is that the thing a perps bot cares about most — the order book — does not live in the EVM at all. On Ethereum you query one JSON-RPC node for everything; on Hyperliquid your market data and order flow come from HyperCore’s REST/WebSocket API while your contract reads come from HyperEVM JSON-RPC. A provider that only exposes HyperEVM covers half your stack. That split, plus the validator-gated /exchange endpoint, is why provider selection here is fundamentally different from picking an Ethereum node.

Hyperliquid RPC endpoint options

Public vs private Hyperliquid RPC endpoints

On most chains the public-vs-private decision is about reliability. On Hyperliquid it is about whether your bot can place an order at all once volume picks up — the public HyperEVM endpoint throttles at 100 requests per minute, and HyperCore reads compete for their own IP-based weight budget.

Official public endpoints:

• HyperEVM mainnet: https://rpc.hyperliquid.xyz/evm
• HyperEVM testnet: https://rpc.hyperliquid-testnet.xyz/evm
• HyperCore mainnet API: https://api.hyperliquid.xyz/info
• HyperCore testnet API: https://api.hyperliquid-testnet.xyz/info

⚠️ The public HyperEVM JSON-RPC endpoint is limited to roughly 100 requests per minute per IP, and HyperCore REST reads share a 1,200 weight-per-minute IP budget. A single perps bot polling the book and account state will blow through both during normal operation. For exactly this reason, the Hyperliquid API documentation directs production integrations toward dedicated infrastructure rather than the shared endpoint.

Feature	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
HyperEVM rate limit	~100 req/min per IP	No aggressive throttling
WebSocket	HyperCore only, public limits	Available on HyperEVM + HyperCore
Archive access	Not available	Available

For perps trading, a shared endpoint is not a throttling inconvenience — it is a hard ceiling that your strategy hits the moment it goes live, which is the case for moving to managed infrastructure from the first deployment rather than after the first missed fill.

Full node vs archive Hyperliquid node

For a perps stack, the question is whether you need to replay the past or only act on the present: live trading runs on current state, while backtesting and PnL reconstruction need historical fills and prices.

Full node access	Archive node access
Live order book and mids for execution	Historical fills and trade replay for strategy backtests
Current account margin and positions	Funding-rate history for carry and basis analysis
Real-time HyperEVM contract reads	Historical eth_getLogs backfills for HyperEVM vault accounting

Archive nodes and WebSockets are now live on Hyperliquid HyperEVM mainnet on Chainstack, so a perps team can backfill historical strategy data and stream realtime events from the same managed archive node infrastructure instead of stitching together third-party data dumps. For any bot whose edge depends on tuning against past market regimes, that historical access is not optional.

HTTPS vs WebSockets

For a perps bot, the transport decision is really a latency decision: polling the order book over HTTPS adds a full round trip per update, and at sub-second finality those round trips are where your edge leaks away. Persistent WebSocket subscriptions push fills and book changes the instant they happen.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Order submission via /exchange, contract reads, account snapshots	Live order book, fills, trades, and HyperEVM event streams
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Note that the public HyperEVM JSON-RPC endpoint offers no WebSocket — real-time data on the public side comes only from the HyperCore WebSocket (capped at 100 connections, 1,000 subscriptions, and 2,000 messages per minute per IP). Managed Global Nodes add WebSocket support on HyperEVM itself, so you can subscribe to contract events without polling.

Why latency is the only metric that matters for Hyperliquid trading

Hyperliquid finalizes in roughly 0.2 seconds and the engine clears around 200,000 orders per second. At that cadence, the spread between a profitable maker fill and an adverse one is measured in single-digit milliseconds. A bot reading the book over a congested shared endpoint is acting on a snapshot that is already two or three book updates stale — it quotes into liquidity that has moved, gets picked off, and bleeds on every cycle. The only way to compete is to minimize the path between the matching engine and your decision loop: dedicated nodes, WebSocket feeds instead of polling, and geographic proximity. Chainstack’s trader-focused infrastructure exists for precisely this class of workload.

Hyperliquid transaction lifecycle for perps bots

A perps order on Hyperliquid does not flow like an Ethereum transaction through a mempool. The lifecycle is: your bot reads the live book and account state from HyperCore /info or its WebSocket, computes a quote, signs an order action, and submits it to /exchange, which is served only by validator-backed infrastructure. HyperBFT orders the action, HyperCore matches it against the book in roughly 0.2 seconds, and the resulting fill streams back over the WebSocket. There is no public mempool to front-run in the Ethereum sense — the competition is latency to the validator and the freshness of your book. This is why a Hyperliquid trading stack splits cleanly: low-latency reads from a dedicated node, and order submission routed to the validator-gated /exchange gateway. Understanding that split before you build is the single biggest determinant of whether your fills land where you expect.

gRPC vs WebSocket vs HTTP for trading infrastructure

For Hyperliquid specifically, the transport hierarchy is straightforward. HTTP is correct for one-shot actions — submitting an order to /exchange, pulling a single account snapshot, calling a HyperEVM contract. WebSocket wins for everything continuous: the order book, your fills, trade prints, and HyperEVM event streams, because a persistent connection removes the per-request handshake that HTTP pays on every poll. gRPC streaming, where a provider exposes it, pushes the same real-time HyperCore feeds with lower framing overhead than WebSocket and is the right choice for the most latency-sensitive market-making loops. The practical rule: never poll over HTTP what you can subscribe to over WebSocket, and submit orders over the lowest-latency HTTP path you can buy.

How to get a private Hyperliquid RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Hyperliquid as your blockchain protocol
4. Choose network: Hyperliquid Mainnet or Hyperliquid Testnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

You can deploy a private Hyperliquid RPC node on Chainstack on both HyperEVM and HyperCore, and the same console exposes the /evm path (system transactions stripped) and the /nanoreth path (system transactions included) on every node.

Here is a minimal connection using the Hyperliquid Python SDK, the primary SDK for perps trading, to pull live market data through your Chainstack endpoint:

from hyperliquid.info import Info
from hyperliquid.utils import constants

# Point Info at your Chainstack HyperCore endpoint
# skip_ws=True for a one-shot REST query; set False to open the live feed
info = Info("YOUR_CHAINSTACK_ENDPOINT", skip_ws=True)

# Fetch the current L2 order book for a perp (e.g. BTC)
l2_book = info.l2_snapshot("BTC")
print(l2_book)

📖 For the full integration guide, see the Chainstack Hyperliquid tooling documentation.

You can also access Chainstack Hyperliquid RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Using Chainlist

HyperEVM (chain ID 999) is listed on Chainlist, so you can add the network to a wallet like MetaMask from there in one click. Chainlist is a network registry, not an infrastructure provider, though — any public RPC URL it lists carries the same 100 req/min ceiling, so replace it with a managed endpoint before pointing a trading bot at it. Chainlist also does not surface HyperCore at all, since the order book is non-EVM.

Chainstack pricing for Hyperliquid RPC

Chainstack bills on request units with a flat one-request-per-RU model, which makes a polling-heavy perps bot far easier to forecast than compute-unit pricing that multiplies cost by method weight. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3,000,000	25	$20
Growth	$49	20,000,000	250	$15
Pro	$199	80,000,000	400	$12.50
Business	$499	200,000,000	600	$10
Enterprise	from $990	400,000,000+	Unlimited	$5

For trading workloads that cannot tolerate per-request accounting at all, the Unlimited Node add-on provides flat RPS-based pricing with no request caps, and Dedicated Nodes start from $0.50/hour plus storage for isolated, co-locatable infrastructure.

How to estimate monthly cost

1. Count the read calls per second your bot makes against HyperCore /info and HyperEVM at steady state
2. Add WebSocket subscription load for live book and fills
3. Multiply by your active trading hours per month
4. Add headroom for HyperEVM contract reads if you run on-chain vault or strategy logic
5. On Hyperliquid, size for volatility: a single funding flip or liquidation cascade can multiply your order book read volume several times over in seconds — buffer for the spike, not the average, or your bot self-throttles exactly when the opportunity appears

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• Order submission routed to a validator-backed /exchange gateway, kept separate from your market-data node
• HyperEVM rate limiter in place so a fallback path never trips the 100 req/min public cap
• /evm vs /nanoreth path behavior confirmed for whether your tooling needs system transactions

Before committing to a provider, benchmark its endpoint latency against alternatives with the Chainstack performance dashboard.

Troubleshooting common Hyperliquid RPC issues

Issue	How to fix
429 Too Many Requests on HyperEVM	You hit the ~100 req/min public cap; move to a managed endpoint with dedicated RPS
HyperCore WebSocket disconnects	Add reconnect + resubscribe logic, then backfill the gap with an /info snapshot
Orders rejected / /exchange unavailable	You are calling /exchange on a non-validator node; route order submission to api.hyperliquid.xyz and use your node for /info reads only
Missing system transactions or unexpected nonce on HyperEVM	Switch from the /evm path to the /nanoreth path, which includes system transactions
Stale order book / fills arriving late	You are polling over HTTP; subscribe to the HyperCore WebSocket feed instead of polling
Address-based throttle (1 req/10s) after quota exhaustion	Respect the per-address weight budget; batch reads and avoid redundant /info calls

Conclusion

The failure mode that catches Hyperliquid perps teams is quiet and expensive: the bot works perfectly in testing against the public endpoint, goes live, and starts silently missing fills the moment its request rate crosses 100 per minute — or worse, it cannot submit a single order because it is pointed at a node that does not serve /exchange. Neither shows up as a clean error; both show up as a strategy that “just doesn’t perform like the backtest.” On a venue with sub-second finality and 200,000-order-per-second throughput, those leaked basis points compound fast.

The pattern that works is to stop treating Hyperliquid as a single endpoint. Run a dedicated node for low-latency HyperCore reads and HyperEVM contract calls, subscribe over WebSocket instead of polling, and route order submission to the validator-gated /exchange gateway as its own path. Do not deploy a perps bot against shared infrastructure — the 100 req/min cap is a hard production ceiling, not a soft limit you can retry your way around.

Start on the free Developer plan to wire up and test the full HyperCore + HyperEVM split, then move to Dedicated Nodes when your strategy goes live and latency becomes the metric that pays.

FAQ

Can I submit perps orders through a Chainstack node? Not directly through the node’s /exchange API — that endpoint is served only by validator-backed infrastructure, so order submission routes to api.hyperliquid.xyz. Your Chainstack node handles the high-volume side of the stack: low-latency /info reads, HyperCore WebSocket feeds, and HyperEVM contract calls. The split is intentional, and a well-built bot keeps these as separate code paths.

HyperCore or HyperEVM — which endpoint does my perps bot need? Both, for different jobs. HyperCore is where the order book, perps, margin, and fills live, so all your market data and trading reads go there. HyperEVM (chain ID 999) is only relevant if your strategy includes Solidity contracts — vaults, on-chain strategy logic, or DeFi positions built on top of perps. A pure execution bot leans almost entirely on HyperCore.

Why does the public HyperEVM endpoint throttle at 100 requests per minute? It is shared infrastructure protecting itself from abuse, and it has been capped at roughly that level since August 2025. For a perps bot that polls book and account state on a loop, 100 req/min is a few seconds of normal operation — which is exactly why a dedicated endpoint with its own RPS allocation is a day-one requirement, not an optimization.

Should I use the /evm or /nanoreth path for a trading bot? Use /evm (the default) for standard JSON-RPC where system transactions are stripped out. Switch to /nanoreth only if your tooling needs to see system transactions — for example, reconciling exact nonces or auditing cross-layer transfers. Most perps bots that touch HyperEVM are fine on /evm.

Do I need an archive node for a perps trading bot? For live execution, no — you trade on current state. You need archive access the moment you backtest: historical fills, funding-rate history, and eth_getLogs backfills for HyperEVM accounting all require it. Since Chainstack now runs archive on HyperEVM mainnet, you can keep backtesting and live trading on the same provider.

How do I get real-time fills instead of polling? Subscribe to the HyperCore WebSocket rather than polling /info over HTTP. The public WebSocket allows up to 100 connections and 1,000 subscriptions per IP with a 2,000 message-per-minute budget; a managed endpoint removes those ceilings and also adds WebSocket on HyperEVM for contract event streams.

Additional resources

• How to build a Hyperliquid trading bot — step-by-step Chainstack tutorial from RPC node to live strategy
• Mastering Hyperliquid — Chainstack developer guide to nodes, SDK setup, and cross-layer interaction
• Chainstack Hyperliquid tooling documentation — connection code for the Python, TypeScript, and Rust SDKs
• Understanding Hyperliquid infrastructure and RPC nodes — HyperCore vs HyperEVM, rate limits, and path behavior
• Hyperliquid HyperEVM documentation — official developer reference
• More Hyperliquid tutorials and articles on the Chainstack Blog