Standing report

The state of public RPC

Public endpoint lists are how most people find an RPC address, and nobody checks them. We do — every listed endpoint, on a rolling sweep, asking two questions: does it answer, and is it the network it says it is.

The finding

generated 2026-08-28 11:43 UTC

60%of publicly listed endpoints do not answer

Answered40%
Unreachable38%
Timed out8%
HTTP error11%
Declined1%
Wrong network1%

Endpoints checked

3,330

Every listed endpoint the sweep has reached at least once.

Answered

40%

1,337 of 3,330, on their most recent check.

Did not

60%

1,993 unreachable, timed out, answering with something other than JSON-RPC, or declining.

Every endpoint currently failing has also never answered us — 1,993 of them. The two counts separate the first time one stops working, and until they do, publishing both would be publishing one figure twice.

The dangerous ones

endpoints serving a different network

They answer normally, and identify themselves as a network other than the one they are listed under.

This is the failure mode worth caring about. An unreachable endpoint announces itself immediately — the connection fails and the application knows. One serving the wrong chain succeeds: balances are read, nonces are fetched, transactions are built against state belonging to somebody else’s network, and nothing anywhere reports an error. It is the only outcome here that is worse than the endpoint being down.

We check it because the chain identifier is free to ask for and nothing else in this space reports it. It is the reason the sweep asks two questions rather than one.

How they fail

Endpoint check outcomes
Outcome	Endpoints	Share	What it means
Wrong network	19	0.6%	Answered normally, and identified itself as a different network than the one it is listed under. An application pointed here would read the wrong chain's state and never be told.
Declined	49	1.5%	A node answered and refused: a key is required, the method is not served, or the operator has withdrawn public access without withdrawing the address.
Timed out	278	8.3%	Accepted the connection and never answered within the deadline.
HTTP error	371	11.1%	A web server answered, but not with JSON-RPC — commonly a 404, a 403, or a landing page where a node used to be.
Unreachable	1,276	38.3%	DNS did not resolve, or the connection was refused. Nothing is listening.
Answered	1,337	40.2%	Responded, and reported the network it is listed under.

Take it awayCSV JSON

Each endpoint counts once, under the result of its most recent check. An address that failed this morning and worked all last month appears here as a failure — which is why the count that has never answered at all is tracked separately rather than folded in.

By network family

EVM

40%

1,333 of 3,325 answered

Solana

80%

4 of 5 answered

The family decides how the question is put — eth_chainId on EVM, getHealth on Solana, system_health on Substrate, a GET on /status for Cosmos. A node is never marked dead for failing to implement a method its software has never had. Families with few endpoints have correspondingly weak shares, and the denominator is printed on every card for that reason.

How many networks have anything that works

1,511networks advertise RPC endpoints where none of them answers

Networks listed: 2,461
With at least one endpoint that answers: 950

Every network in the directory advertises at least one endpoint, so this is not a gap in cataloguing. It is published infrastructure that has stopped existing while the list still says otherwise — and those lists are what people copy an address out of.

How this is measured

One request per endpoint, from one machine, at most every thirty minutes. It asks two things: does the endpoint answer, and is it the network it claims to be. The family decides how that question is put — eth_chainId on EVM, getHealth on Solana, system_health on Substrate, a GET on /status for Cosmos — so a node is never marked dead for not implementing a method its software has never had.

What this does not measure

Latency. A single sample from one location is not comparable with a percentile built from tens of thousands of observations across four regions, and publishing the two side by side would destroy the meaning of both. Response time is recorded because answering in 40ms and answering in 9 seconds are different facts about usability, and it is never presented as latency.
Availability. Reachability here is the outcome of the most recent check, not a share of time. An endpoint that was down for the last hour and up for the previous month reads the same as one that has never worked, which is why the count of endpoints that have never answered at all is tracked separately rather than folded in.
Whether an endpoint is fit to use. It answered, from one place, once. That is the whole claim.

Everything on this page belongs to the listed tier: one request, from one machine, at most every thirty minutes. It is not a benchmark and cannot be compared with the percentiles published for the endpoints this platform measures continuously from four regions. Those are here: measured providers, and the reasoning behind keeping the two apart is in the methodology.

Looking for an endpoint rather than a finding? The directory is at endpoints by network, where each one carries the result of its own most recent check.