Hyperliquid (HyperEVM) RPC Nodes & Endpoints

HyperEVM RPC URLs you can use right now

Third-party endpoints, free and shared. They serve HyperEVM, not the order book, and they are shared with every other bot running the same polling loop as you.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://rpc.hyperliquid.xyz/evm");
const blockNumber = await provider.getBlockNumber();
console.log("Hyperliquid (HyperEVM) block:", blockNumber);

HyperCore and HyperEVM are two different surfaces

The most common wrong assumption about Hyperliquid is that its EVM RPC exposes the exchange. It does not. HyperCore is the native order book where spot and perps actually trade, and it is reached through Hyperliquid's own info and exchange APIs with their own request formats and their own websocket feed. HyperEVM is a general-purpose EVM environment on chain ID 999 that speaks standard JSON-RPC. A bot that needs live order book depth, funding rates, or its own fills is talking to HyperCore, and no amount of eth_call will get it there.

Most serious strategies end up straddling both, which is the part worth planning for. Positions, funding, and liquidations come from the HyperCore API; the contracts, tokens, and DeFi built around them live on HyperEVM and are read over JSON-RPC. That means two connections with two different latency profiles and two different failure modes, and a strategy is only as fast as whichever one is lagging. Dedicated HyperEVM capacity fixes one half of that equation, and it is worth being clear that it is one half rather than both.

Why a market-making loop cannot share an endpoint

HyperEVM exists in the orbit of a perps exchange, so its RPC traffic looks like trading: market makers polling positions and funding, liquidation bots re-checking accounts every block, dashboards streaming fills. That read loop runs continuously, and on a shared endpoint it competes with every other bot running the same loop. The result is jitter, and jitter in a market-making loop is money.

A dedicated HyperEVM RPC node gives the loop a floor: consistent read latency, no shared quota deciding when your liquidation check runs, and throughput for the analytics that funding and liquidation tracking require. On BLAZED.sh the strategy itself runs in a container on the node host, reading over a local socket instead of the public internet.

On a trading chain, jitter is the metric that costs you money

Trading on Hyperliquid is a latency sport by design, and the RPC path is the part of the stack you can actually control. A remote gateway adds tens to low hundreds of milliseconds of public-internet round trip per call; a co-located container adds almost nothing. On our live Ethereum product, that architecture delivers sub-10ms calls over a local socket, and dedicated HyperEVM nodes will run the same way.

What dedicated HyperEVM node hosting will cost

BLAZED.sh prices node access in per-request credits granted monthly by your subscription, with a deliberately narrow weight spread: most RPC methods cost a single credit, and only a handful of heavy operations cost more. Dedicated Hyperliquid (HyperEVM) nodes will launch on the same credit model, with the waitlist deciding rollout priority.

Market-making read loops are single-credit calls, so the cost of running a strategy around the clock is a straightforward multiplication rather than a method-weighted estimate.

Perfect for

What is Hyperliquid?

Hyperliquid pairs a purpose-built, on-chain order book (HyperCore) with HyperEVM, an EVM environment that lets developers deploy standard Solidity contracts that can interact with the exchange state. HyperEVM uses chain ID 999 and HYPE for gas, so EVM tooling connects normally, while the order-book side is accessed through Hyperliquid's own APIs. The platform's reason for existing is high-frequency perps trading, which means market makers and bots treat every millisecond of RPC and submission latency as edge. As HyperEVM's contract ecosystem grows, indexers and dashboards tracking positions, funding, and liquidations need consistent RPC throughput, the classic case for a dedicated, co-located node rather than a shared public endpoint.

Hyperliquid RPC: frequently asked questions