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

TL;DR

Your DeFi contract deploy on Hyperliquid reverts with “out of gas” even though you set the gas limit high — because it landed in a 2M-gas small block instead of a 30M-gas big block, and nothing told you. HyperEVM’s dual-block architecture and its 50-block eth_getLogs ceiling are the two infrastructure realities that decide whether a DeFi protocol ships on Hyperliquid or stalls in debugging. This guide shows you how Hyperliquid RPC actually behaves and how to get an endpoint that handles both.

What is a Hyperliquid RPC endpoint

A Hyperliquid RPC endpoint is your DeFi application’s connection into HyperEVM, the Ethereum-compatible execution layer that runs on Chain ID 999. HyperEVM speaks a subset of the standard EVM JSON-RPC API, so your contract calls, balance reads, and transaction broadcasts use the same method names you already know — eth_call, eth_getBalance, eth_sendRawTransaction. What makes Hyperliquid different is that HyperEVM does not stand alone: it shares HyperBFT consensus with HyperCore, the Rust-based order-book engine that runs Hyperliquid’s perps and spot markets. Your DeFi contracts can read live HyperCore state — order books, mark prices, positions — through precompiles, which means an RPC endpoint here is the gateway to both a smart-contract chain and a high-performance exchange at once.

On Hyperliquid, the actions your DeFi protocol depends on the endpoint for include:

• Reading token and vault balances with eth_getBalance and eth_call
• Querying swap, mint, burn, and liquidation events via eth_getLogs (capped at 50 blocks per query, up to 4 topics)
• Calling HyperCore precompiles from HyperEVM contracts to pull oracle-free order-book and position data
• Broadcasting transactions with eth_sendRawTransaction, routed into either small or big blocks
• Subscribing to newHeads and logs over WebSocket with eth_subscribe
• Tracing and simulating transactions through the debug_* and trace_* namespaces

You can review the full list of supported JSON-RPC methods and the per-method limits in the Hyperliquid HyperEVM JSON-RPC documentation.

Endpoint quality on Hyperliquid is not an abstract reliability concern — it determines whether your transactions even reach the right block type. A naive endpoint that doesn’t expose the big-block toggle will silently route a contract deployment into a 2M-gas small block, where it reverts, and you’ll spend hours blaming your Solidity before you blame your infrastructure.

How Hyperliquid RPC differs from Ethereum RPC

HyperEVM is EVM-compatible, so the method surface is familiar, but several behaviors diverge in ways that directly affect DeFi infrastructure choices.

Property	Ethereum	Hyperliquid (HyperEVM)
Block model	Single block type (~12s)	Dual blocks: small (1s, 2M gas) + big (1min, 30M gas)
Gas token	ETH	HYPE
eth_getLogs range	Provider-dependent, often thousands of blocks	Hard cap of 50 blocks per query, max 4 topics
Consensus	Gasper (PoS)	HyperBFT
Cross-engine reads	N/A	HyperCore order-book/oracle data via precompiles
Trading actions	Standard contract calls	/exchange actions only via Hyperliquid’s own API, not third-party nodes

These differences matter for provider selection because two of them — the dual-block gas split and the 50-block log window — break tooling that assumes Ethereum defaults. A DeFi indexer written for Ethereum will request 2,000-block log ranges and get rejected; a deploy script will target a single block type and stall. You need a provider that exposes the big-block path and an endpoint stable enough to chunk thousands of 50-block log queries without throttling you mid-backfill.

Hyperliquid RPC endpoint options

Public vs private Hyperliquid RPC endpoints

For DeFi on Hyperliquid, the public-vs-private decision comes down to a single question: can your endpoint survive chunked log backfills and route deployments into big blocks under load? The public endpoint can do neither at production scale.

Official public endpoints:

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

⚠️ The public HyperEVM endpoint is rate-limited to 100 requests per minute per IP. A DeFi indexer backfilling event history 50 blocks at a time will exhaust that budget in seconds — at 1-second small blocks, covering a single day of history is roughly 1,700 sequential eth_getLogs calls. The Hyperliquid dual-block architecture documentation describes the small-block 2M-gas constraint that makes a managed endpoint with big-block routing necessary for any real contract work.

Factor	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
Big-block routing	Not exposed	Available
Archive access	Not available	Available

For a DeFi protocol that lives or dies on event indexing and reliable contract execution, the 100 req/min public ceiling isn’t a starting constraint you grow out of — it’s a wall you hit on day one of your first backfill.

📖 For a detailed comparison of Hyperliquid RPC providers, see Best Hyperliquid RPC providers in 2026.

Full node vs archive Hyperliquid node

For Hyperliquid DeFi, historical data access means being able to reconstruct the full event trail of every swap, liquidation, and vault deposit beyond the recent window a full node retains — exactly the data a 50-block log cap makes painful to collect in the first place.

Full node access	Archive node access
Live vault balances and current positions	Historical liquidation reconstruction for risk models
Real-time swap and price-feed reads	Complete eth_getLogs backfills beyond recent blocks
Current HyperCore precompile state	Point-in-time state for DeFi accounting and audits

Because HyperEVM caps each log query at 50 blocks, the cost of historical work compounds fast, and archive availability becomes the difference between a feasible analytics pipeline and an impossible one. Chainstack supports archive nodes for Hyperliquid, so you can run those deep historical queries against a managed archive node rather than stitching together thin slices from a full node that has already pruned the data you need.

HTTPS vs WebSockets

For DeFi protocols watching for liquidations and price moves, the question isn’t whether to poll — it’s whether you can afford to. Polling eth_getLogs every second against a 50-block window burns request budget; a WebSocket subscription pushes new events to you as blocks finalize.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Contract deploys, balance reads, on-demand backfills	Live liquidation alerts, swap-event streams, newHeads for block-type tracking
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Hyperliquid supports WebSocket subscriptions through eth_subscribe for logs, newHeads, and syncing. The public WebSocket caps you at 100 connections and 2,000 messages per minute, so production DeFi event pipelines belong on a managed WSS endpoint.

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

When you deploy a Hyperliquid RPC node on Chainstack, you get both the /evm (default, hl-node-compliant) and /nanoreth (system transactions included) paths. Here’s a minimal connection check with ethers.js against HyperEVM:

const { ethers } = require("ethers");

// HyperEVM runs on Chain ID 999; pass it explicitly so ethers
// does not auto-detect against a network it does not recognize
const provider = new ethers.JsonRpcProvider(
  "YOUR_CHAINSTACK_ENDPOINT",
  { chainId: 999, name: "hyperliquid" }
);

async function main() {
  const block = await provider.getBlockNumber();
  console.log("Latest HyperEVM block:", block);

  // Reads honor the 50-block eth_getLogs ceiling — keep ranges tight
  const balance = await provider.getBalance("0xYourAddress");
  console.log("HYPE balance:", ethers.formatEther(balance));
}

main();

📖 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

Hyperliquid (Chain ID 999) can be added to wallets through Chainlist, but Chainlist is a network registry, not an infrastructure provider. Any public RPC URL you pull from Chainlist inherits the same 100 req/min ceiling and no big-block routing — swap it for a managed endpoint before you put any DeFi traffic through it.

Chainstack pricing for Hyperliquid RPC

Chainstack bills on request units rather than per-method compute multipliers, so a heavy eth_getLogs backfill costs the same per call as a simple balance read — a meaningful difference when your DeFi indexer fires thousands of log queries against the 50-block window. See the full Chainstack pricing page for plan details and overage rates.

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

Advanced options relevant to Hyperliquid DeFi workloads:

• Archive queries consume 2 RU per request (vs 1 RU for full-node calls) — relevant for historical liquidation and accounting backfills, billed through archive node access
• Unlimited Node add-on for flat-fee, high-RPS event streaming
• Dedicated Nodes from $0.50/hour per node (+ storage) for isolated, predictable performance

How to estimate monthly cost

1. Estimate your steady-state RPS from baseline reads and contract calls
2. Add WebSocket subscription volume for live event streams
3. Add backfill load — every 50-block eth_getLogs chunk is one request
4. Multiply by your retention window to project monthly RU
5. On Hyperliquid specifically, the 50-block log cap is the silent cost driver: indexing a busy DeFi contract over any meaningful history multiplies your request count far faster than on a chain with wide log ranges, so size your plan around backfill volume, not live traffic

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
• Big-block routing confirmed: eth_usingBigBlocks enabled before deploying or calling contracts above the 2M small-block gas limit
• eth_getLogs chunking logic in place that never requests more than 50 blocks or 4 topics per call
• HyperCore precompile reads validated against the /evm path, with /exchange trading actions routed through Hyperliquid’s own API

Benchmark candidate endpoints with the Chainstack performance dashboard before committing to a provider.

Troubleshooting common Hyperliquid RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Exceeded the 100 req/min public ceiling	Move to a managed endpoint with no aggressive throttling
Contract deploy reverts “out of gas” with high limit set	Transaction landed in a 2M-gas small block	Send {"type":"evmUserModify","usingBigBlocks":true} via HyperCore to route into 30M-gas big blocks
eth_getLogs query rejected or returns empty	Requested more than 50 blocks or 4 topics	Chunk queries into ≤50-block ranges and ≤4 topics
“Failed to deserialize the JSON body”	Called a HyperCore-only method on the HyperEVM path	Route HyperCore queries (l2Book, userFills, allMids) through Hyperliquid’s public API, not /evm
WebSocket disconnects	Connection drop or message-rate limit	Implement reconnect logic plus event backfill for the gap
Block-shaped responses include unexpected system txs	Using the /nanoreth path	Switch to /evm for hl-node-compliant responses with system transactions stripped

Conclusion

The failure that costs Hyperliquid DeFi teams the most time isn’t dramatic — it’s a contract deployment that reverts “out of gas” while your gas limit reads 10 million, or an indexer that silently falls behind because every eth_getLogs call past 50 blocks comes back empty. Both look like application bugs. Neither is. They’re the dual-block gas split and the 50-block log ceiling surfacing as symptoms you can’t diagnose without knowing they exist — and now you do.

The pattern that works: develop against the public endpoint, but before you deploy a single DeFi contract, move to a managed endpoint that exposes big-block routing and run your event pipeline against an archive-capable node that won’t throttle your backfills. Build the 50-block chunking and the eth_usingBigBlocks toggle into your code from the start, not after the first failed deploy. These aren’t optimizations — on Hyperliquid they’re the baseline for anything that touches contracts or logs.

Spin up a Hyperliquid endpoint on the free Developer plan to test against, then move to dedicated infrastructure when your DeFi traffic and backfill volume demand it.

FAQ

Can I use ethers.js and Hardhat with Hyperliquid? Yes. HyperEVM is EVM-compatible on Chain ID 999, so ethers.js, Hardhat, Foundry, and Remix all work for reading state and deploying contracts. The one Hyperliquid-specific step is routing large transactions into big blocks — standard EVM tooling assumes a single block type, so you must enable eth_usingBigBlocks at the HyperCore level before deploying contracts that exceed the 2M-gas small-block limit.

Why does my DeFi contract deploy fail even with a high gas limit? Because HyperEVM produces two block types, and by default your transaction goes into a small block with a 2M gas ceiling. A contract deploy that needs more gas reverts regardless of the limit you set in your transaction. Send the evmUserModify action with usingBigBlocks: true to route into the 30M-gas big block, then deploy.

How do I index DeFi events when eth_getLogs only returns 50 blocks? You chunk. Every query must span 50 blocks or fewer and use no more than 4 topics, so a backfill becomes a loop of sequential 50-block requests. At 1-second small blocks, this generates a large request volume quickly — which is why production indexing needs a managed endpoint that won’t rate-limit you mid-backfill and an archive node for history beyond the recent window.

Can I place trades on HyperCore through my RPC endpoint? No. HyperEVM read methods and contract calls work over your /evm endpoint, but HyperCore trading actions on /exchange are only available through Hyperliquid’s own API at api.hyperliquid.xyz — they’re not exposed on third-party nodes. Your DeFi contracts can still read HyperCore data (order books, prices) via precompiles on the EVM path.

Is a public Hyperliquid endpoint enough for a DeFi protocol? Only for development. The 100 req/min per-IP limit, the lack of big-block routing, and no archive access make it unusable for production DeFi — you’ll hit the ceiling on your first event backfill and have no way to deploy contracts that need big blocks reliably.

What metrics should I monitor on a Hyperliquid DeFi endpoint? Track latency and error rate as usual, but add two Hyperliquid-specific signals: eth_getLogs rejection rate (a sign your chunking is requesting more than 50 blocks) and big-block inclusion for deploy transactions (to confirm the usingBigBlocks toggle is taking effect).

Additional resources

• Hyperliquid: Bridging USDC between HyperCore and HyperEVM — Chainstack Docs tutorial
• Fork Hyperliquid EVM with Foundry — test DeFi contracts against mainnet state
• Chainstack Hyperliquid tooling documentation
• Hyperliquid HyperEVM JSON-RPC reference — official docs
• Reliable RPC infrastructure for DeFi — the blockchain infra DeFi runs on
• More Hyperliquid tutorials and articles on the Chainstack Blog