Fastest free Polkadot RPC, live no-key endpoint latency
HTTP round-trip latency for chain_getHeader against every free, no-key public Polkadot relay-chain endpoint, audited every 60 seconds from 3 regions.
TL;DR. As of , OnFinality leads rpc latency at 50 ms (p50, 24h) on Fastest free Polkadot RPC, live no-key endpoint latency. Source: OpenChainBench, https://openchainbench.com/benchmarks/polkadot-rpc.
Companion page
Comparing free RPC endpoints across every chain we measure? Open the cross-chain RPC matrix →
Polkadot is the first non-EVM, non-Solana chain in the RPC latency cluster. Substrate-based relay chain, JSON-RPC 2.0 wire but a different method set: the probe is `chain_getHeader` (returns the latest header with a hex-encoded block number) rather than `eth_getBlockByNumber`. Everything else on this page is the same bench pattern used on Ethereum, Base, Solana and the 20+ other chains: identical POST every 60 seconds from three regions, latency measured client-side at millisecond precision, per-region breakdowns first class. Provider cohort at launch: Parity's official `rpc.polkadot.io`, OnFinality's public gateway, and PublicNode (Allnodes). Dwellir + 1RPC audited alongside and excluded (Dwellir 503 during the launch sweep; 1RPC filters `chain_getHeader` on its privacy relay); both will be revisited when a stable no-key path reappears.
Methodology
Per-chain member of the RPC latency cluster, extended for Substrate. We measure the round-trip latency of a single, identical JSON-RPC call (`chain_getHeader`) against every no-key public Polkadot relay-chain endpoint that sustains continuous probing, 3 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 a relay-chain-scaled staleness gap (40 blocks ≈ 4 minutes at Polkadot's ~6 s block time), so the leaderboard rewards sustained, honest availability rather than a fast error message. The cross-chain view lives on the parent `rpc-capabilities` benchmark; this page is the Polkadot-scoped answer with per-region breakdowns as a first-class dimension.
Frequently asked
What is the fastest free Polkadot RPC right now?
OnFinality currently leads at 50 ms (`chain_getHeader` p50 over the last 24h), measured against 3 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 Polkadot RPCs work without an API key?
Three endpoints sustain continuous keyless probing at launch: Parity's official `rpc.polkadot.io`, OnFinality's public gateway and PublicNode (operated by Allnodes). Every listed endpoint was live-verified with four consecutive `chain_getHeader` probes returning a parsable hex block number before inclusion. Excluded by the audit: 1RPC filters `chain_getHeader` as "Not Allowed" on its privacy relay, Dwellir returned 503 Service Unavailable during the sweep (will be revisited once stable), Ankr requires a paid Polkadot key, Chainstack is key-gated on Substrate, and RadiumBlock rejects requests without a referral header.
Does the fastest Polkadot RPC change by region?
Frequently, and often more sharply than EVM chains. Polkadot's public infra is heavily weighted toward Web3 Foundation grantees whose primary data centers sit in Europe; a gateway that wins from Amsterdam can lose from Singapore by multiples. 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 Polkadot RPC latency measured here, technically?
One identical Substrate JSON-RPC POST (`chain_getHeader`) every 60 seconds against each provider from each of 3 regions, using the same plain HTTP client the EVM cluster uses. The response is a header object containing a hex-encoded relay-block number and the parent-block hash; the harness parses the number (`strconv.ParseUint(strings.TrimPrefix(hdr.Number, "0x"), 16, 64)`, same rule as EVM). 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 `chain_getHeader` and not `system_health`?
Two reasons. First, `chain_getHeader` returns the head block number, which lets the harness plug into the cluster's cross-provider tip machinery for staleness classification without adding a chain-specific code path. Second, `system_health` returns a small object about peer count and sync state that any polite CDN can synthesize without touching the underlying node, defeating the point of a latency probe on the RPC path. `chain_getHeader` forces the endpoint to actually read the head from the runtime, which is what integrators care about.
Why is there no archive-depth or hash-quorum column for Polkadot?
Polkadot's state model accesses historical state via `state_getStorage` keyed by a Blake2-hashed storage key, which has no chain-agnostic depth analog for the EVM `eth_getBalance(address, height)` probe the cluster uses on other chains. Similarly, `chain_getHeader` returns the parent-block hash (not the current-block hash: the current hash is derived by Blake2 over the SCALE-encoded header), so the cross-provider height-hash quorum check from bench 083 cannot be run against Polkadot without adding a Substrate-native encoder to the harness. Both columns are omitted honestly rather than filled with a proxy that would misrepresent the chain.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-capabilities