We Tested 945 Public RPC Endpoints. Half Don't Work.

Public RPC lists are how most developers find an endpoint: open Chainlist, copy the first URL, paste it into a config. The lists tell you an endpoint was added at some point. They do not tell you whether it works today.

So we tested all of them. On 2026-09-24 we took every keyless endpoint listed on Chainlist and chainid.network for the 65 EVM chains we serve (945 third-party URLs: 800 HTTP and 145 WebSocket) and ran the same checks against each one. 395 of the 800 HTTP endpoints answered correctly: 49.4%. Of the 145 WebSocket endpoints, 76 actually streamed a new block: 52.4%.

The full results, endpoint by endpoint, are on our public RPC leaderboard, re-run every week.

How we tested

Every HTTP endpoint got the same sequence:

1. eth_chainId, which must return the chain the list says it serves.
2. eth_blockNumber three times, for median latency and the head.
3. How far that head trails the best head seen for the chain in the same run.
4. eth_getLogs over 1,000 and then 10,000 blocks, filtered to one address.
5. eth_getBalance 128 and 1,000,000 blocks back, to see how much history it keeps.

Every WebSocket endpoint: eth_chainId, then eth_subscribe("newHeads"), and it passes only if a new block actually arrives within 15 seconds. On chains that produce blocks less often than that, an accepted subscription with no block yet is counted as inconclusive, not as a failure.

A few things to keep in mind about the numbers:

• One server, one run. Latency is from a single location. Head lag, limits and pass/fail are not location-dependent in the same way, but a flaky endpoint can pass one day and fail the next.
• Rate limits count as failures only after backoff. Calls are paced, and a rate-limited call is retried three times with increasing waits before we give up. 98 endpoints still refused. A client sending a request every few seconds might get through where our test did not; a real application under load will not.
• Our own endpoint is excluded from these totals. It is on the leaderboard, labelled, and measured in a separate pass (details at the end).

Why half of them fail

For the 405 HTTP endpoints that did not pass:

The biggest groups tell a simple story: lists outlive endpoints. Domains lapse, providers shut down or move their free tier behind a signup, and the list entry stays. Thirteen URLs from one discontinued provider are still listed across chains. Others now answer "API key required", "invalid API key" or a usage-limit message, which is a reasonable business decision for the provider but a broken entry for anyone who copied it.

"Working" is not the same as "usable"

Of the 395 endpoints that answered correctly:

The lag numbers matter most, because a lagging node does not fail — it answers, confidently, with old data. An endpoint 4.4 million blocks behind returns a perfectly valid block number; it is just from long ago. If you read balances or wait for confirmations through a node like that, your application is wrong without any error to tell you so. Always compare eth_blockNumber against a second source, or check the latest block's timestamp against the clock.

The eth_getLogs split is the other trap. Two in five working endpoints (164 of 395) refuse a 1,000-block log query, which is small for any indexer or backfill. If your code was written against a generous endpoint and falls back to a stricter one, it will start failing with range errors you never saw in development.

WebSockets are worse than they look

Only 76 of 145 WebSocket endpoints delivered a block. Another 9 accepted the subscription on slow chains (Metis, Arbitrum Nova, HAQQ, Syscoin, Rootstock) that produced no block inside the window, so we count them as inconclusive. The other 60 failed:

The rejected and silent groups are why "the socket connected" proves nothing. An endpoint can complete the handshake, answer eth_blockNumber, accept your subscription with a valid ID, and then send nothing. Your application sees a healthy connection and waits forever. The only real test is a delivered event. We covered the client-side pattern for this in reconnecting without losing events, and the specific errors are in eth_subscribe errors explained.

Which endpoints held up

Some providers' public endpoints passed nearly everywhere they are listed. Counting HTTP endpoints that answered correctly out of those listed:

These are free, keyless endpoints, and they deserve credit for staying up across dozens of chains. They still come with the usual public-endpoint limits: per-IP rate limits, tight eth_getLogs caps on some chains, and shared capacity. For WebSocket, PublicNode streamed on 18 of 27 and Pocket Network on 13 of 15.

How to pick a public endpoint

Based on what failed:

1. Test before you trust the list. Our RPC tester runs these checks on any endpoint from your browser: chain ID, head lag, eth_getLogs range, archive depth and whether its WebSocket really streams.
2. Check freshness, not just liveness. A lagging node is worse than a dead one because it fails silently.
3. Configure two endpoints, not one. Most failures above are permanent (dead domains, discontinued providers), but rate limits are not, and a second endpoint turns an outage into a retry.
4. Match the endpoint to the job. A wallet reading the latest balance can use almost any working endpoint. An indexer needs a generous eth_getLogs range and historical state; that eliminates most of the list.
5. Re-check periodically. Every failing entry here was added to a list by someone, presumably when it worked. Endpoints decay; the list does not update itself.

Our own endpoint, measured the same way

We ran our keyless endpoint through the same checks in a separate pass, so our rate limiter did not collide with the rest of the test. It answered correctly on 63 of 65 chains over HTTP. Over WebSocket it streamed on 45 of 65. On the other 20, either we have no WebSocket upstream for that chain or the subscription did not deliver during the test; each chain page shows our current measured WebSocket status rather than a blanket claim. Our keyless and free tiers are limited to 2 requests per second; paid plans start at 50.

The per-chain pages list every endpoint with its latency, lag, limits and WebSocket result, ours included. For example: Ethereum (33 of 80 listed HTTP endpoints working), Base (15 of 36) and BNB Smart Chain (36 of 47).

For what free endpoints can and cannot do at the plan level, see free RPC endpoints and their real limits and public RPC vs paid RPC. If you want one key that works across 86 chains with the limits published and measured, SwiftNodes has a free tier.