RPCsLive

Fastest free public RPC for Ethereum, BNB, Polygon and 23 more chains (plus Solana and Polkadot)

HTTP round-trip latency for eth_getBlockByNumber against free, no-key public RPC endpoints across 25 chains (23 EVM plus Solana and Polkadot), audited every 60 seconds.

TL;DR. As of , Binance posts the lowest RPC latency at 32 ms (p50, 24h) across 12 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/rpc-capabilities.

Companion page

Comparing free RPC endpoints across every chain we measure? Open the cross-chain RPC matrix →

Read this carefully

Latency is conditional on success: the harness times only calls returning a valid fresh block, so a mostly-failing endpoint can post a fast p50. Rows below 50 percent success are degraded; unresponsive probes pin below the table. The All chains aggregate favours single-chain foundation endpoints (Base, Binance, Arbitrum, Optimism, Avalanche officials) since they rank on one chain only; use a chain tab for honest comparison. Dead endpoints (cloudflare-eth POST returns -32603) are excluded.

This benchmark answers the question every developer reaching for a free public RPC asks before pasting a URL into their dapp. which no-key endpoint is actually fast and reliable right now, on the chain my product runs on. Alchemy and Infura own the keyed-tier market; the free public side of the question lives elsewhere, in the RPC services dapps hit when a contributor's free quota is the budget. We probe `eth_getBlockByNumber` every 60 seconds against audited providers across 25 chains (23 EVM plus Solana and Polkadot). PublicNode, dRPC, MeowRPC, Tenderly Gateway, Nodies (POKT), Lava Network, Flashbots Protect, bloXroute, OnFinality and chain-official foundation endpoints (Base, Binance BSC, Avalanche, Arbitrum, Optimism, Sonic, Gnosis, Celo, Taiko, Moonbeam, Berachain, zkSync, Cronos, Fraxtal, Unichain, Soneium, Monad, MegaETH, Parity for Polkadot, Solana Labs). Chain footprint spans the L1/L2 majors down to long-tail chains. The headline question is per chain, not cross-chain. Five providers are single-chain by design (the foundation endpoints above), so a cross-chain aggregate mechanically rewards whichever single-chain endpoint happens to be fastest on its one chain. Current per-chain leaders. Ethereum dRPC at 33 ms, Base PublicNode at 85 ms, BNB Binance at 32 ms, Arbitrum dRPC at 42 ms. Use the chain tab above to filter the leaderboard. Latency is the headline; the leaderboard also exposes call-result classification (`ok` vs `http_err` vs `jsonrpc_err` vs `stale` vs `timeout`, the Cloudflare-eth trap where a 200 OK hides a JSON-RPC error field) and archive-depth support so a fast endpoint that returned a state-pruned response at block (head, 5M) is not silently treated as a viable archive source.

Methodology

We measure the round-trip latency of a single, identical RPC call (`eth_getBlockByNumber` for EVM chains, `getSlot` for Solana, `chain_getHeader` for Polkadot) against every major no-key public RPC endpoint, across 25 chains (23 EVM plus Solana and Polkadot). The harness emits three metric families from one binary because they share the same (provider × chain) client matrix and same 15 s scrape interval: (a) `rpc_latency_milliseconds` for the speed leaderboard, (b) `rpc_call_total{result}` for the reliability and silent-failure analysis, (c) `rpc_archive_depth_supported{depth}` for an honest read on which endpoints actually serve historical state. The depth set covers Geth's default pruned cap (~5760 blocks) up through genesis-era archive (5M blocks). Stale-head detection compares each provider's reported block against the cross-provider tip and flags anything more than 20 blocks behind so a dead endpoint stuck on an old number is not silently ranked as the fastest. Latency is recorded only for successful calls, so every percentile is conditional on success; the `rpc_call_total` counters are the companion signal that keeps a mostly failing endpoint from reading as fast.

  • Cadence: every 60 seconds per (provider, chain) pair, from each of 3 Railway replicas (us-east Virginia, eu-west Amsterdam, sgp Singapore). The harness stamps a `region` label on every metric from `$RAILWAY_REPLICA_REGION`. Headline p50/p90/p99 are the mean of per (chain, region) `quantile_over_time` cells: all 3 regions, and on the All chains tab every chain the provider serves. Per-region breakdowns are on the time-series chart.
  • Payload: `{"jsonrpc":"2.0","id":<rotating>,"method":"eth_getBlockByNumber","params":["latest",false]}`. Plain HTTP POST, identical for every endpoint, no API key in any request. The request id rotates, but that does not guarantee a cache miss: many caches normalise `id` away. Measured 2026-10-08, fixed and rotating ids answer within 2 to 4 percent of each other.
  • Latency: client-side `time.Now()` delta around the round-trip, in milliseconds. Exposed as both a gauge (`rpc_latency_milliseconds`) and a histogram (`rpc_latency_milliseconds_histogram`) with buckets 50 ms → 10 s, so p50/p90/p99 are computed via Prometheus `histogram_quantile` / `quantile_over_time`. Latency is recorded only for calls classified `ok`; failed calls never enter the latency distribution, so every percentile is conditional on success.
  • Call-result classification: `ok` (HTTP 200 + non-empty result), `http_err` (status ≠ 200 or transport failure), `jsonrpc_err` (HTTP 200 with an `error` field, the Cloudflare-eth trap), `stale` (returned block more than 20 behind the cross-provider tip for that chain), `timeout`. Counter `rpc_call_total{result}` powers the reliability leaderboard.
  • Success gating: because failed probes record no latency, a mostly failing endpoint can post a fast p50 from its rare successes. The ledger pairs every latency figure with a Success column computed as ok calls over total calls in the same 24h window; read rows below 50 percent success as degraded. Providers with under 5 percent success lose their latency series to Prometheus staleness and are pinned below the table as unresponsive instead of being ranked.
  • Archive depth: every 5 minutes we issue `eth_getBalance` at (head, depth) for `depth` in {300, 7200, 216_000, 1_296_000, 5_000_000}. Gauge `rpc_archive_depth_supported{depth}` is 1 when the response is non-pruned, 0 otherwise. The 300/7200 thresholds cover Geth's default pruned-cap range; 216k ≈ 1 month; 1.3M ≈ 6 months; 5M ≈ genesis-era full archive.
  • Chain coverage: 25 chains (23 EVM plus Solana and Polkadot). EVM majors: Ethereum, Arbitrum, Base, Optimism, Avalanche, BNB, Polygon, Linea, Scroll, Mantle. EVM long-tail: Sonic, Gnosis, Celo, Taiko, Moonbeam, Berachain, zkSync, Cronos, Fraxtal, Unichain, Soneium, Monad, MegaETH. Non-EVM: Solana (getSlot probe), Polkadot (chain_getHeader probe). Provider matrix per chain is documented in `harnesses/rpc-capabilities/cmd/script/config.go`.
  • Excluded: 1RPC (delisted 2026-07-09, under 13% success even at two chains and one probe per minute), Ankr (key-gated), gateway.fm (29 req/IP budget too tight for 15s polling), LlamaRPC + BlockPI + OmniaTech (Cloudflare 521 region-blocked), Alchemy demo (rate-limited dead), NodeReal + GetBlock + Chainstack (key-gated). Blink, formerly Merkle (no public eth_getBlockByNumber) + Lava and MeowRPC outside ETH/Arb excluded. Every (provider, chain) was live-verified no-key before inclusion.

Results: 12 providers ranked by RPC latency (p50, 24h)

Fastest free public RPC for Ethereum, BNB, Polygon and 23 more chains (plus Solana and Polkadot): RPC latency per provider (p50, 24h).
№Providersp50p90p99Success
1Binance32 ms41 ms162 ms100.00% (n=4351)
2Avalanche89 ms130 ms243 ms99.93% (n=4349)
3PublicNode89 ms143 ms409 ms97.99% (n=243424)
4Base105 ms113 ms170 ms100.00% (n=4356)
5Tenderly120 ms129 ms165 ms93.10% (n=126129)
6Arbitrum140 ms158 ms473 ms99.86% (n=4353)
7Nodies147 ms236 ms396 ms99.72% (n=17397)
8Optimism151 ms157 ms208 ms100.00% (n=4354)
9MeowRPC208 ms346 ms720 ms99.64% (n=8701)
10dRPC209 ms349 ms610 ms93.24% (n=321627)
11NOWNodes229 ms301 ms476 ms98.68% (n=17399)
12Flashbots344 ms438 ms544 ms100.00% (n=4354)

Frequently asked

What is the fastest free public RPC right now?

The question is per chain because several providers are single-chain by design (Base official, Binance, Arbitrum Foundation, Optimism Foundation, Avalanche) and a cross-chain aggregate mechanically rewards whichever single-chain endpoint happens to be fastest on its one chain. Current per-chain leaders. Ethereum dRPC at 33 ms, Base PublicNode at 85 ms, BNB Chain Binance at 32 ms, Arbitrum dRPC at 42 ms. The leaderboard re-sorts every 60 seconds against fresh Prometheus samples averaged across us-east, eu-west and sgp probes. Switch the chain tab to see the leader on the network your product runs on.

Which public RPCs work without an API key in 2026?

Audited providers across 25 chains (23 EVM plus Solana and Polkadot). Universal multi-chain: PublicNode, dRPC, Tenderly Gateway (`gateway.tenderly.co/public/<slug>`), Nodies (POKT at `*-pokt.nodies.app`). Ethereum-specific or limited footprint: MeowRPC (ETH + Arbitrum only), Flashbots Protect, Lava Network (ETH + Arbitrum + Sonic + Solana no-key). Chain-official foundation RPCs: Arbitrum, Optimism, Base, Avalanche, BNB, Sonic, Gnosis, Celo, Taiko, Moonbeam, Berachain, zkSync, Cronos, Fraxtal, Unichain, Soneium, Monad, MegaETH, Parity for Polkadot, Solana Labs, plus regional gateways like OnFinality and bloXroute. Excluded: Ankr (key-gated), gateway.fm (29 req/IP), LlamaRPC / BlockPI / OmniaTech (Cloudflare 521 region-blocked), Alchemy demo (rate-limited dead), NodeReal / GetBlock / Chainstack (key-gated), cloudflare-eth (POST returns -32603).

Does Cloudflare still have a free Ethereum RPC that works?

Partially, and the trend is the wrong way. Cloudflare's public Ethereum gateway (cloudflare-eth) switched to a permissioned mode for many JSON-RPC methods. The endpoint still answers HTTP 200 quickly, but the body is increasingly a JSON-RPC error (`-32046 Cannot fulfill request`) rather than a block. This benchmark catches the trap by classifying a call as `ok` only when the HTTP status is 200 AND the JSON-RPC body has a usable `result` field, so Cloudflare's real success rate is visible in the Success column instead of hiding behind fast error responses. Latency without reliability is a misleading ranking signal for a public RPC.

Why can an RPC with a low success rate still show a fast latency?

Latency percentiles are computed only from successful calls. The harness records a round-trip time when a probe returns a valid, fresh block; HTTP errors, JSON-RPC error bodies, timeouts and stale responses increment the `rpc_call_total` counter but never enter the latency distribution. An endpoint failing 60 percent of its calls is therefore timed only on the 40 percent that succeed, which can make it look faster than a healthy provider doing real work on every request. That is why the leaderboard pairs every latency figure with a Success column computed as ok calls over total calls in the same 24h window. Read rows below 50 percent success as degraded regardless of their p50. Providers under 5 percent success are dropped from the ranking and pinned below the table as unresponsive.

Which free RPC supports Ethereum archive node calls?

Most free public RPCs are state-pruned, so `eth_getBalance` at block (head, 5,000,000) returns an error rather than the historical balance. This benchmark probes five depths (300, 7,200, 216,000, 1,296,000, 5,000,000 blocks) every five minutes and exposes a gauge per provider per depth. The page surfaces a per-provider archive-depth badge: a green tick at the 5M tier means full historical state is available for free without a key. Anything pruned at 7200 confirms the endpoint is on a Geth default config and only serves the last ~24 hours.

How is RPC latency measured on OpenChainBench?

The harness issues a single `eth_getBlockByNumber` JSON-RPC POST every 60 seconds against each (provider, chain) pair from each of 3 regions (us-east, eu-west, sgp), using the same plain HTTP client for every endpoint. Wall-clock delta around the round-trip is recorded with millisecond precision and pushed to both a gauge and a histogram. p50/p90/p99 are computed via Prometheus `quantile_over_time` over the last 24 hours. Stale-head detection compares each response against the cross-provider tip and flags anything more than 20 blocks behind as `stale`, so a dead endpoint stuck on yesterday's block cannot rank as the fastest.

Are public RPCs production-grade for a dapp?

Read the success-rate column before deciding. A median latency under 100 ms is irrelevant if the endpoint silently returns a JSON-RPC error 5% of the time or stalls during an L1 reorg. Free public RPCs share rate-limit budgets with the entire internet and have no SLA. They are good for read-heavy demos, local development and fallback paths; production dapps usually graduate to a keyed tier (Alchemy, QuickNode, Infura) for `eth_sendRawTransaction`, websocket subscriptions and archive queries beyond Geth's pruned cap. This benchmark measures the no-key tier specifically because that is the unmeasured part of the market.

Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-capabilities