How to get a Hyperliquid RPC endpoint for market making and HFT (2026 guide)

TL;DR

A market-making loop that quotes both sides of a Hyperliquid book will silently hit the public HyperEVM endpoint’s ~100-requests-per-minute IP cap within seconds, and from that point your quotes go stale while the book moves against you. The cause is Hyperliquid’s split design: the same node serves both HyperEVM (chain ID 999) and a read-only slice of the HyperCore order-book engine, but the public tier is rate-limited for casual use, not for an HFT quoting cadence. This guide shows how to get a private Hyperliquid RPC endpoint that survives market-making and high-frequency workloads.

What is a Hyperliquid RPC endpoint

A Hyperliquid RPC endpoint is the connection your code uses to read state and submit transactions across Hyperliquid’s two coupled layers. HyperEVM speaks standard Ethereum JSON-RPC over HTTPS and WebSocket, so calls like eth_call, eth_getLogs, and eth_sendRawTransaction work as an EVM developer expects. HyperCore — the native, gas-free order-book engine that settles perps and spot in roughly 0.2 seconds — is reached through Hyperliquid’s /info query API and, for live trading, the /exchange API. A production endpoint usually fronts both: HyperEVM JSON-RPC plus the read-only /info methods of HyperCore.

On Hyperliquid, the endpoint is what a trading system leans on for:

• Live L2 order book snapshots and best bid/ask reads from HyperCore via /info
• Open positions, fills, funding, and margin state for a given address
• HyperEVM contract reads (eth_call) and event scans (eth_getLogs) for on-chain DeFi
• Broadcasting HyperEVM transactions with eth_sendRawTransaction
• WebSocket subscriptions for streaming book and fill updates

You can review the full list of supported methods and their behavior in the Hyperliquid JSON-RPC developer documentation.

For market making and HFT, endpoint quality is not a nicety; it is P&L. Every millisecond of round-trip latency on a book read shows up as worse fills, and the moment a shared endpoint throttles your reads, you are quoting against information the rest of the market already has. That read-latency-plus-throttle exposure, sitting on top of the HyperCore/HyperEVM split, is the whole reason endpoint selection matters on this chain.

How Hyperliquid RPC differs from Ethereum RPC

HyperEVM is EVM-compatible, so the JSON-RPC surface is familiar — but several behaviors that a market maker relies on are different enough to break naive ports from Ethereum.

Property	Ethereum	Hyperliquid (HyperEVM + HyperCore)
Block model	Single ~12s blocks	Dual-block: 1s small blocks (2M gas) + ~1/min big blocks (30M gas)
Gas token	ETH	HYPE
Consensus	PoS (Gasper)	HyperBFT, ~0.2s finality
Chain ID	1	999 mainnet / 998 testnet
Native order book	None (DEX via contracts)	HyperCore L1 order book, readable via /info and EVM precompiles
Historical state	Widely available on archive nodes	Default RPC serves only the latest block for several state reads
Fee methods	Real priority-fee data	eth_maxPriorityFeePerGas returns 0; eth_syncing returns false

These differences change provider selection in two concrete ways. First, the dual-block architecture means a market maker’s time-sensitive transactions live on the 1-second small blocks — so you need a provider whose small-block propagation is fast and reliable, not one tuned for generic throughput. Second, because the default HyperEVM RPC only answers state reads for the latest block, any strategy that backtests or reconstructs historical book context needs a provider that explicitly runs archive-capable infrastructure.

Hyperliquid RPC endpoint options

Public vs private Hyperliquid RPC endpoints

The public-versus-private decision on Hyperliquid comes down to one thing for an HFT desk: the public endpoint is rate-limited for exploration, and a real quoting loop is not exploration. The instant two strategies (or two users of your dApp) hammer the same IP, you are sharing one throttled bucket.

Official public endpoints:

• Mainnet: https://rpc.hyperliquid.xyz/evm
• Testnet: https://rpc.hyperliquid-testnet.xyz/evm

⚠️ The public HyperEVM endpoint enforces roughly 100 requests/minute per IP, and WebSocket access is capped at 100 connections / 1,000 subscriptions / 2,000 messages per minute. Critically, the /exchange trading endpoint is not served by third-party nodes at all — order placement and cancellation must route to Hyperliquid’s own API. The Hyperliquid HyperEVM documentation recommends professional infrastructure for anything beyond light development.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~100 req/min per IP	No aggressive throttling
WebSocket limits	100 conn / 2,000 msg/min	High, dedicated limits
Historical reads	Latest block only	Archive-capable nodes available

For market making, the dominant constraint is read throughput at low latency: you are not placing the order through the RPC node, you are pulling book and fill state through it constantly, and a shared 100-req/min bucket cannot carry that. A private endpoint is what keeps your view of the book current.

For a detailed, perps-specific provider breakdown, see Chainstack’s comparison of the best Hyperliquid RPC providers for perps trading in 2026.

Full node vs archive Hyperliquid node

On Hyperliquid, “historical access” specifically means being able to read state and book context from blocks older than the latest one — something the default HyperEVM RPC deliberately does not serve.

Full node access	Archive node access
Live L2 book snapshots and current quotes	Backtesting strategies against historical book state
Real-time position and fill monitoring	Reconstructing past funding and margin events
HyperEVM contract calls against latest block	Historical eth_getLogs backfills for HyperEVM DeFi

Because HyperEVM’s default endpoint answers state reads only for the latest block, any quant workflow that replays historical conditions needs a provider running an archive node. If your market-making research stack backtests fills or reconstructs book depth over time, treat archive access as a hard requirement rather than an add-on — you can run that workload on Chainstack archive data.

HTTPS vs WebSockets

For a market maker, the question is not whether to use WebSockets — it is how much of your read path can move off request/response and onto a persistent stream before connection overhead at HFT cadence starts costing you fills.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	One-off position/margin reads, HyperEVM eth_call, transaction broadcast	Streaming L2 book updates, live fills, and trade events
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

On Hyperliquid the public WebSocket tier is capped (100 connections, 2,000 messages/minute), so a streaming-heavy HFT setup will outgrow it quickly — a private endpoint with headroom is the practical path for live book and fill streams.

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 node on Chainstack on shared Global Nodes for general read load, or on Dedicated Nodes when latency-critical trading bots need isolated resources. Once your endpoint is live, point the Hyperliquid SDK at it:

from hyperliquid.info import Info

# Point the Hyperliquid SDK at your private Chainstack HyperCore/HyperEVM node.
# skip_ws=True keeps it on HTTPS; set False to also open the WebSocket feed.
info = Info("YOUR_CHAINSTACK_ENDPOINT", skip_ws=True)

# Pull a live L2 order book snapshot - the read a market maker hits constantly.
book = info.l2_snapshot("BTC")
print(book["levels"])

📖 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.

HyperEVM (chain ID 999) can be added to wallets through Chainlist, but Chainlist is not an infrastructure provider: any URL it surfaces is a public, rate-limited endpoint you should swap for a managed one before production. It also never exposes HyperCore, so it cannot serve the order-book reads a market maker depends on.

Chainstack pricing for Hyperliquid RPC

Chainstack bills in request units rather than opaque compute units, which makes a market maker’s read budget straightforward to model: one API call is one request unit, with no per-method multipliers. See the full Chainstack pricing page for plan details and overage rates.

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

Advanced options relevant to trading workloads:

• Dedicated Nodes: from $0.50/hour compute (plus storage), for isolated, latency-tuned infrastructure
• Archive add-on: archive reads consume 2 RU per request versus 1 RU for full-node reads
• For low-latency transaction delivery on supported chains, Chainstack’s Trader Node routes through bloXroute for faster inclusion

How to estimate monthly cost

1. Count the markets you quote and the reads each requires per cycle
2. Multiply by your quoting frequency to get reads per minute
3. Extrapolate to a monthly request-unit total
4. Add headroom for WebSocket fan-out and HyperEVM contract calls
5. Hyperliquid market-data load is bursty — a single volatility event can multiply your book-read rate, so size your RPS ceiling for the spike, not the average, or your quoting loop self-throttles exactly when spreads are widest

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
• Rate limiter in place so your quoting loop never self-throttles against the provider
• Order execution wired directly to Hyperliquid’s /exchange API, separate from your read endpoint
• Small-block confirmation latency benchmarked before going live on HyperEVM

Benchmark candidate endpoints against the Chainstack performance dashboard before committing capital.

Troubleshooting common Hyperliquid RPC issues

Issue	How to fix
429 Too Many Requests on book reads	Move off the public IP-limited endpoint to a private one with dedicated RPS
WebSocket disconnects mid-session	Add reconnect + heartbeat logic and backfill missed book/fill events on resume
Order placement fails on your RPC node	/exchange is not served by third-party nodes — route trading actions to api.hyperliquid.xyz directly
Historical state query returns latest-block data only	Use an archive-capable node; the default HyperEVM RPC serves only the latest block for those reads
HyperEVM tx not landing in expected time	Confirm you are on 1-second small blocks; large transactions flagged for big blocks settle ~1/min
eth_maxPriorityFeePerGas returns 0	Expected on HyperEVM — do not derive tips from it; use HYPE base-fee logic instead

Conclusion

The failure mode that bites Hyperliquid market makers is not a loud error — it is a 429 your quoting loop swallows while it keeps running on stale book data. Your spreads look fine in the logs, but you are quoting against a book the market has already moved, and the adverse fills only show up later in the P&L. It is hard to diagnose precisely because the strategy never crashed; the public endpoint just quietly stopped feeding it fresh state.

The pattern that works is simple and non-negotiable: pull all your reads through a private endpoint with dedicated RPS and WebSocket headroom, keep order execution on Hyperliquid’s /exchange API, and put a client-side rate limiter in front of both so a volatility burst never throttles you at the worst possible moment. Run reads on a dedicated node when latency is the constraint, and confirm archive access before any strategy that backtests against historical book state.

Spin up a free endpoint, then scale to dedicated infrastructure when your quoting cadence demands it.

FAQ

Do I need a separate endpoint for HyperCore and HyperEVM? Not necessarily — a production Hyperliquid endpoint typically fronts HyperEVM JSON-RPC plus the read-only /info methods of HyperCore from one node. But order execution is the exception: the /exchange API is not served by third-party RPC nodes, so trading actions always route to Hyperliquid’s own API regardless of which provider serves your reads.

Why isn’t the public Hyperliquid endpoint enough for a market-making bot? The public HyperEVM endpoint caps you at roughly 100 requests per minute per IP, with similarly tight WebSocket limits. A market maker quoting multiple books reads state far faster than that, so you hit the throttle within seconds and start operating on stale data — exactly the condition that produces adverse fills.

Which SDK should I use to connect to a Chainstack Hyperliquid endpoint? The official Hyperliquid Python SDK and the community TypeScript SDK both let you point an Info client at your endpoint; for HyperEVM contract work, standard EVM libraries like ethers.js and viem connect to the chain-ID-999 JSON-RPC like any other EVM chain.

How does the dual-block architecture affect my transactions? HyperEVM produces 1-second small blocks (2M gas) and ~1-per-minute big blocks (30M gas). Time-sensitive trading transactions belong on small blocks; only large transactions like contract deployments use big blocks. If a HyperEVM transaction is taking ~a minute to land, check whether it has been flagged for big blocks.

Can I backtest strategies against historical Hyperliquid book state? Only with an archive-capable node. The default HyperEVM RPC answers several state reads for the latest block only, so reconstructing historical book depth, funding, or margin events requires a provider that explicitly runs archive infrastructure.

What should I monitor on a Hyperliquid RPC endpoint for HFT? Track read latency (p99), throttling/429 rate, and WebSocket disconnect frequency above all — these are the metrics that directly translate into quote staleness and missed fills on this chain.

Additional resources

• Understanding Hyperliquid infrastructure and RPC nodes — Chainstack docs on HyperCore vs HyperEVM and node behavior
• Chainstack Hyperliquid tooling documentation — SDK setup and code examples
• How to build a HIP-4 trading bot on Hyperliquid
• Hyperliquid API guide: endpoints, SDK, and WebSocket
• More Hyperliquid tutorials and articles on the Chainstack Blog
• Hyperliquid JSON-RPC reference — official developer documentation