A Hyperliquid RPC provider gives your application hosted access to Hyperliquid’s two execution layers — HyperCore and HyperEVM — so a trading bot, wallet, or smart contract can read on-chain data and submit orders without running a node yourself. NOWNodes, QuickNode, Chainstack, Alchemy, Dwellir, and dRPC all offer this, and the right pick depends on whether your app needs raw HyperCore order-book data, standard HyperEVM smart-contract calls, or both at once.
Hyperliquid isn’t a typical EVM chain wearing a different name. It runs a Rust-based order book (HyperCore) and an Ethereum-compatible smart-contract layer (HyperEVM) side by side under one consensus process, and that split changes what “an RPC endpoint” even means here. Below is what a Hyperliquid RPC node actually does, who needs one, and how the main providers compare this year.
Why Do You Need a Hyperliquid RPC Provider?
You need one because Hyperliquid’s public endpoint is built for prototyping, not production traffic, and running your own node is a heavier commitment than it looks.
The Public Endpoint Is Rate-Limited by Design
Hyperliquid’s own /evm endpoint caps HyperEVM JSON-RPC calls at 100 requests per minute per IP, and the REST /info API enforces an aggregated weight limit of 1,200 per minute, according to Hyperliquid’s official rate-limit documentation. Address-based trading limits add another layer: an account gets a 10,000-request buffer, then earns one additional request per USDC traded.
Here’s the catch that trips up new integrations: the official RPC currently has no WebSocket JSON-RPC support for HyperEVM, so an app that needs live contract events has to poll or find a provider that fills the gap.
Running Your Own Node Takes Real Hardware
A non-validator Hyperliquid node needs 16 vCPUs, 128 GB of RAM, and 500 GB of SSD storage on Ubuntu 24.04, per the official node repository. The network also generates roughly 100 GB of logs per day, which means active pruning or archiving just to keep the disk from filling up.
Trading operations add a further wrinkle: the /exchange endpoint that places and cancels orders only works by routing through Hyperliquid’s own validator infrastructure — a self-hosted non-validator node, much like the non-validator node types covered elsewhere, can serve reads but can’t originate order flow on its own. A provider absorbs both problems: the hardware, and the routing.
Who Actually Uses Hyperliquid RPC Providers?
Almost any application that touches Hyperliquid programmatically ends up behind an RPC provider somewhere in its stack, though the specific need shifts by use case.
- Perp trading bots and market makers need low-latency access to
l2Book,allMids, and order-placement endpoints, since Hyperliquid’s matching engine processes roughly 200,000 orders per second with sub-second finality — the same kind of speed requirement covered in what MEV and MEV protection actually mean for on-chain trading. - HyperEVM dApps — lending markets, perps aggregators, vaults — call smart contracts through standard
eth_callandeth_sendRawTransaction, the same methods any EVM chain uses. - Wallets and portfolio trackers read HyperCore account state (
clearinghouseState,spotClearinghouseState) to show balances and open positions. - Analytics platforms and explorers query historical trades and funding data, which usually means archive access rather than a standard node.
- Cross-layer protocols use HyperEVM precompiles to read HyperCore order-book prices and positions directly from a smart contract, without an external price oracle — the DEX landscape where Hyperliquid’s perpetuals volume now rivals the entire spot market depends on exactly this kind of infrastructure.
Jeff Yan, Hyperliquid’s founder, has framed the project’s ambition in terms that explain why this cross-layer design matters: “Are you building a financial super-app — like Robinhood — or a financial system?” he asked in a profile by TechFlow. A financial system needs contracts, order books, and settlement to share state — which is exactly what HyperCore and HyperEVM are built to do.
HyperCore vs. HyperEVM: What to Compare Between Providers
Once you move past “does it support Hyperliquid,” the real differences show up in which layer a provider actually covers, and how completely.
| Layer | Handles | Typical Methods | Who Needs It |
|---|---|---|---|
| HyperEVM | Smart contracts, standard JSON-RPC | eth_call, eth_getBalance, eth_sendRawTransaction | dApps, wallets, DeFi protocols |
HyperCore /info | Market data, account state, order books | l2Book, allMids, clearinghouseState | Bots, trackers, analytics |
HyperCore /exchange | Order placement and cancellation | order, cancel | Trading engines, market makers |
| Archive / historical | Past trades, funding, blocks | candleSnapshot, userFills | Analytics, tax and compliance tools |
Coverage genuinely varies here in a way it doesn’t for single-layer chains. Chainstack, for instance, documents native support for 129 of Hyperliquid’s 212 total methods, with the remaining /info and /exchange trading actions still routed through Hyperliquid’s own public infrastructure. Confirm which layer — or layers — a provider actually proxies before you build against it.
Best Hyperliquid RPC Providers in 2026
The six providers below span multi-chain generalists and Hyperliquid-focused specialists. Pricing and method coverage change often, so treat the figures here as a starting point to verify on each provider’s current page.
| Provider | Best For | Standout Feature |
|---|---|---|
| NOWNodes | Multi-chain products that include Hyperliquid | 120+ networks under one account |
| QuickNode | Full-stack HyperCore + HyperEVM access | gRPC streaming with 13 data streams |
| Chainstack | Cost-predictable production workloads | Simple 1-request-1-unit pricing |
| Alchemy | Teams already standardized on Alchemy | Large free compute-unit tier |
| Dwellir | Deep order-book data needs | 100-level order-book depth vs. 20 on public |
| dRPC | Redundancy-focused routing | Aggregates multiple backend node operators |
NOWNodes
NOWNodes provides Hyperliquid RPC and WebSocket access alongside coverage for 120+ other blockchain networks, from Bitcoin to Ethereum to Solana — one account and API key instead of a separate provider per chain. It offers shared and dedicated Hyperliquid nodes, archive access, and Debug/Trace methods for transaction inspection, with dedicated nodes carrying no predefined requests-per-second cap.
The trade-off is the same one every multi-chain provider faces: a team building Hyperliquid-only tooling around deep order-book indexing may find a specialist offers more out of the box. NOWNodes fits best when Hyperliquid is one piece of a broader multi-chain product rather than the entire product.
QuickNode
QuickNode splits Hyperliquid access into dedicated paths — /evm for recent HyperEVM data, /nanoreth for full archive and tracing, and separate HyperCore endpoints covering 71 of 73 /info methods plus gRPC streaming across 13 data channels. That breadth suits teams that need both layers at production scale.
It’s built for volume, and a small prototype checking balances occasionally won’t use most of it. For a trading application pulling both contract state and live order-book data, the coverage is the point.
Chainstack
Chainstack prices Hyperliquid access simply — one request equals one unit, with archive queries as the main exception — and documents its method coverage in detail: 83 HyperEVM methods and 46 HyperCore /info queries, with the remaining trading actions routed to public infrastructure. It also publishes one of the more thorough public explainers of Hyperliquid’s dual-layer design.
That transparency helps with cost modeling, but it doesn’t cover /exchange order placement directly. Teams that need to submit orders through their provider, not just read data, should confirm that gap before committing.
Alchemy
Alchemy added Hyperliquid support recently, focused on HyperEVM rather than HyperCore, and pairs it with the same account infrastructure teams already use for Ethereum and other EVM chains. Its free tier is among the more generous entry points for testing.
The limitation is direct: no native HyperCore support means an app needing order-book or trading data still needs a second source. For contract-only integrations, that’s not a problem.
Dwellir
Dwellir runs a specialized HyperCore order-book server with roughly five times the depth of the public endpoint — 100 price levels instead of 20 — aimed at market makers and quant desks that need a fuller view of liquidity. It offers both shared and dedicated infrastructure.
Its HyperCore gRPC product carries enterprise-tier pricing, which puts it out of reach for a small prototype. For a team whose entire edge depends on order-book depth, that cost is the trade-off for the data.
dRPC
dRPC takes a different approach: instead of running its own Hyperliquid infrastructure exclusively, it routes requests across multiple backend node operators and fails over automatically when one underperforms. That model trades a single point of failure for redundancy by design.
The catch is less control over exactly which backend serves a given request, which can matter for applications sensitive to consistent latency rather than average latency. For most integrations, the redundancy outweighs that concern.
How to Choose the Right Hyperliquid RPC Provider
Work through these questions in order rather than starting from a pricing page:
- Identify which layer you actually need. A contract-only dApp needs HyperEVM; a trading bot needs HyperCore
/infoand often/exchange; many production apps need both. - Check whether the provider covers order placement. Several providers proxy HyperCore reads but still route
orderandcancelthrough Hyperliquid’s public infrastructure — confirm this before building a trading engine around it. - Decide if you need archive data. If your product only reads recent state, skipping archive access can meaningfully cut cost.
- Test WebSocket stability under your own load, since HyperCore’s live order-book and trade streams are where volatility-driven traffic spikes actually happen.
Risks and Limitations to Watch For
A single RPC provider is a dependency, and dependencies fail. If your application only points at one endpoint, an outage or rate-limit spike on that provider becomes your outage — the common mitigation is running a second provider as failover.
Hyperliquid’s own scale adds pressure here. The network carried roughly $245 billion in 30-day perpetuals volume and held about 36% of total perp-DEX volume as of mid-2026, per Coinlaw’s Hyperliquid statistics. That kind of traffic means shared endpoints — public or provider-hosted — see real congestion during volatile markets, exactly when your application needs them most.
Method coverage is the other recurring issue. Because HyperCore’s /exchange actions and some /info queries still depend on Hyperliquid’s own infrastructure at several providers, a trading application can’t always assume full independence from the public API just because it pays for a private RPC plan.
Conclusion
There’s no single best Hyperliquid RPC provider — only the one that matches which layer your application actually needs, how it handles order execution, and your tolerance for managing infrastructure yourself. A multi-chain wallet or exchange gets the most value from a provider like NOWNodes that covers Hyperliquid alongside 120-plus other networks under one account; a trading engine needs a provider with real /exchange coverage and gRPC streaming; a quant desk chasing order-book depth may lean toward a specialist like Dwellir.
What matters more than the brand name is verifying the specifics before you build on them: which HyperCore and HyperEVM methods a provider actually proxies, what still routes back to Hyperliquid’s public infrastructure, and what happens to your application the moment your provider has a bad day.
FAQ
What’s the difference between HyperCore and HyperEVM?
HyperCore is Hyperliquid’s native Rust-based order book and trading engine, handling perpetuals and spot markets with no gas fees. HyperEVM is the Ethereum-compatible smart-contract layer that runs alongside it under the same consensus, letting Solidity contracts read HyperCore’s live prices and positions through precompiles.
Can I place trades through a third-party Hyperliquid RPC provider?
Sometimes only partially. Several providers proxy HyperCore’s /info read endpoints in full but still route /exchange actions like order and cancel through Hyperliquid’s own public infrastructure — check a provider’s documented method coverage before building an execution engine on it.
Does Hyperliquid have a testnet?
Yes. HyperEVM testnet uses chain ID 998 with its own RPC endpoint, separate from mainnet’s chain ID 999, letting developers test contracts before deploying against live order-book data.
Is the public Hyperliquid RPC endpoint safe to use in production?
Not for meaningful traffic. It caps HyperEVM calls at 100 requests per minute per IP and REST /info calls at a 1,200 aggregated weight per minute, limits that a production trading application or active dApp will hit quickly.
