Polkadot RPC endpoints: free public URLs by 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 has the lowest median latency of the 3 free public Polkadot RPC endpoints measured, 53 ms (p50, 24h, 3 regions). Source: OpenChainBench, https://openchainbench.com/benchmarks/polkadot-rpc. 3 public endpoints, no key: polkadot.api.onfinality.io, polkadot-rpc.publicnode.com, rpc.polkadot.io. Full URLs with their 24h median are listed below.
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
Polkadot: 3 free public RPC endpoints answering `chain_getHeader` every 60 seconds from us-east, eu-west and Singapore, ranked by 24h median. OnFinality leads at 53 ms; the chain-official endpoint measures 131 ms. 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 live today, 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.
Results: 3 free public Polkadot RPC endpoints ranked by p50 latency (24h, 3 regions)
| № | Providers | p50 | p90 | p99 | Success |
|---|---|---|---|---|---|
| 1 | OnFinality | 53 ms | 116 ms | 1.51 s | 100.00% |
| 2 | PublicNode | 85 ms | 111 ms | 332 ms | 99.91% |
| 3 | Parity | 131 ms | 249 ms | 611 ms | 99.79% |
Public Polkadot RPC endpoints measured
The 3 no-key endpoints answering our probes today, with their current 24h median. Paste one into a wallet or a client as is: no signup, no key. Private providers (API key) are never listed with a URL.
OnFinalityhttps://polkadot.api.onfinality.io/public53 ms100.0%
PublicNodehttps://polkadot-rpc.publicnode.com85 ms99.9%
Parityhttps://rpc.polkadot.io131 ms99.8%
Median round-trip and success rate over the last 24 hours across the probe regions; the ranked table above carries p90, p99 and the per-region split.
Frequently asked
Which Polkadot RPCs work without an API key?
3 endpoints are probed on this chain: 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.
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