Fastest free Hyperliquid RPC, live no-key HyperEVM endpoint latency
HTTP round-trip latency for `eth_getBlockByNumber("latest", false)` against every free, no-key public HyperEVM endpoint, audited every 60 seconds from 3 regions.
TL;DR. As of , dRPC leads rpc latency at 16 ms (p50, 24h) on Fastest free Hyperliquid RPC, live no-key HyperEVM endpoint latency. Source: OpenChainBench, https://openchainbench.com/benchmarks/hyperliquid-rpc.
Companion page
Comparing free RPC endpoints across every chain we measure? Open the cross-chain RPC matrix →
Hyperliquid's HyperEVM (chain id 999) is the EVM execution layer bolted onto the HyperCore perps engine. Standard Ethereum JSON-RPC wire, so the probe is `eth_getBlockByNumber("latest", false)` , the same call the Ethereum, Base, Arbitrum and 20+ other chain benches use. Provider cohort at launch: Hyperliquid Labs's official `rpc.hyperliquid.xyz/evm`, dRPC, Stakely, Purroof Group and Hypurrscan. Alchemy demo path (rate-limited dead), Grove/Pocket public LB (needs an app id at the public LB path), thirdweb (returns "Invalid chain" on HyperEVM) and the AllThatNode / Blast API guesses (DNS not resolving to a public HyperEVM endpoint) were audited alongside and excluded. Each will be revisited when a stable no-key path reappears.
Methodology
Per-chain member of the RPC latency cluster, extended to HyperEVM. We measure the round-trip latency of a single, identical JSON-RPC call (`eth_getBlockByNumber("latest", false)`) against every no-key public HyperEVM endpoint that sustains continuous probing, 5 providers at launch, every 60 seconds, from us-east, eu-west and Singapore. The harness classifies every response (ok / http_err / jsonrpc_err / stale / timeout) with the standard EVM staleness gap (block gap = 25 blocks ≈ 50 seconds at HyperEVM's ~2 s block time). The cross-chain view lives on the parent `rpc-capabilities` benchmark; this page is the Hyperliquid-scoped answer with per-region breakdowns as a first-class dimension.
Frequently asked
What is the fastest free Hyperliquid RPC right now?
dRPC currently leads at 16 ms (eth_getBlockByNumber p50 over the last 24h), measured against 5 no-key providers probed every 60 seconds from us-east, eu-west and Singapore. The leaderboard re-sorts continuously against fresh Prometheus samples, so the answer on this page is the answer right now, not a quarterly snapshot. Use the region tabs to see the leader from the origin closest to your deployment.
Which HyperEVM RPCs work without an API key?
Five endpoints sustain continuous keyless probing at launch: Hyperliquid Labs's `rpc.hyperliquid.xyz/evm`, dRPC (`hyperliquid.drpc.org`), Stakely (`hyperliquid-json-rpc.stakely.io`), Purroof Group (`rpc.purroofgroup.com`) and Hypurrscan (`rpc.hypurrscan.io`). Every listed endpoint was live-verified with an `eth_getBlockByNumber` POST returning a parsable hex head before inclusion. Excluded by the audit: Alchemy's demo key path is rate-limited dead, thirdweb returns `Invalid chain` on HyperEVM, Grove/Pocket public LB requires an app id at the LB path, and AllThatNode / Blast API / Chainstack / Gelato / Imperator HyperEVM paths either DNS-fail or 401 without a key. HyperEVM is a young chain so this list will shift as providers stand up dedicated endpoints.
Does the fastest Hyperliquid RPC change by region?
Often. HyperEVM provider infra is heavily weighted toward Europe and the US; a gateway that wins from Amsterdam can lose from Singapore by multiples, especially for community-run providers with a single data centre. The region tabs at the top of the page re-scope every number on the page to a single origin; pick the one closest to where your requests actually originate.
How is Hyperliquid RPC latency measured here, technically?
One identical JSON-RPC POST (`eth_getBlockByNumber("latest", false)`) every 60 seconds against each provider from each of 3 regions, using the same plain HTTP client the rest of the EVM cluster uses. Wall-clock round-trip is recorded at millisecond precision; p50/p90/p99 are computed via Prometheus `quantile_over_time` over 24 hours. Responses are classified (`ok` / `http_err` / `jsonrpc_err` / `stale` / `timeout`) so an endpoint stuck on an old head or returning errors behind HTTP 200 is never ranked as fastest.
Why is the probe `eth_getBlockByNumber` and not `eth_blockNumber`?
Two reasons. First, `eth_getBlockByNumber("latest", false)` forces the node to actually assemble the block header (timestamp, hash, gas metrics) which a polite CDN cannot synthesise from a stale integer , `eth_blockNumber` on its own can be answered from an edge cache without touching a node, defeating the point of a latency probe. Second, the returned header lets the harness populate the `latest_block_hash` and `timestamp` fields the cross-provider tip machinery uses to detect stale endpoints. Both together mean the number on this page is what your app actually pays when it fetches a fresh head.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-capabilities