Ethereum
~12s blocks · chain id 1
- Providers
- 9
- Endpoints
- 12
- Validators
- 400K
No ranking yet for this chain. A provider needs a minimum sample count before it is scored at all.
RPCNode.IO continuously measures Ethereum, BNB Smart Chain and Solana RPC providers from distributed probes — latency, availability, response correctness and chain-head freshness, per method and per region.
Collecting right now
Connecting0
measurements stored in the last 24 hours
Live
Every row below is a call that was made, timed and stored. The feed is pushed as each measurement lands rather than polled, so what you are watching is the collection pipeline itself.
Measurements arriving from 0 probe regions
0 providers · 0 methods · 0 chains
Observations / 24h
0
last known figure
Fastest just now
—
waiting for a measurement
Median, live window
—
waiting for a measurement
Leading on latency
—
needs five samples from one provider
newest first
Figures on this panel cover the last few minutes of collection only. Every ranking elsewhere on the site is computed over a stated window from merged percentile states — the two are not the same measurement. Methodology
Live
Each card carries that chain's current top three by p95 response time, over the last 24 hours.
~12s blocks · chain id 1
No ranking yet for this chain. A provider needs a minimum sample count before it is scored at all.
~450ms blocks · chain id 56
No ranking yet for this chain. A provider needs a minimum sample count before it is scored at all.
~420ms blocks
No ranking yet for this chain. A provider needs a minimum sample count before it is scored at all.
Methods
They are broadly equivalent on cheap lookups and diverge sharply on the expensive ones. These are the calls where the difference shows, and what each one is for.
Read contract state
Runs a contract function against current state without sending a transaction. Every balance in a wallet and every quote in a swap UI goes through it — and it is the only method measured here that exercises the execution engine rather than a lookup.
Event history
Fetches event logs over a block range: how indexers, analytics and every transaction-history screen are built. It is also where providers diverge most — block-range caps, result-size caps and outright refusal are all common.
Full block data
Returns a block with transaction hashes, or with full transaction objects. The full form is tens of times larger, which makes it a test of a provider's bandwidth rather than of its lookup speed.
Event history, at 450ms blocks
The same call as on Ethereum, against a chain producing blocks roughly 27 times faster. A block range that is trivial on Ethereum is a large scan here, and the public data seeds document it as disabled outright.
Read contract state
BNB Smart Chain is EVM-equivalent, so contract reads use the same call and the same encoding as Ethereum. What differs is the field: several BSC endpoints are operated as public goods with tight limits rather than as commercial gateways.
Confirming a transaction
The outcome of a transaction — status, gas used, logs. Anything waiting on a confirmation polls it in a loop, so its tail latency is what a user experiences as the word 'pending' staying on screen.
Read account state
Solana keeps state in accounts rather than in contract storage, so this one call is the read path for everything: token balances, program state, PDA lookups. Commitment level is part of the request, and providers differ in how strictly they honour it.
Required before every send
A transaction must reference a recent blockhash to be valid, and that blockhash expires after about 150 slots. A slow or stale response here does not merely delay a send — it can invalidate the transaction outright.
The chain head
Solana advances a slot roughly every 400ms, which makes this both the cheapest call measured and the sharpest freshness signal on the platform: a provider a second behind is two slots behind.
Methodology
Every published figure is traceable to collected observations. Where the data is thin, the interface says so rather than guessing.
Measurement runs from probe agents rather than from this server, over the same public network path a real client would take. Each probe holds its own credential and its own rate budget.
DNS, TCP, TLS, time to first byte and download are stored as distinct fields. A provider that resolves slowly and one that computes slowly look identical in a single total, and they are not the same problem.
An unsupported method is a capability fact. A rate limit is a provider protecting itself. A bug in our own software is never counted against anyone. Collapsing these into one error rate would be the easiest way to publish a wrong ranking.
Responses are validated for envelope, type and chain, and the chain head is compared against a robust median across every provider measured at that instant — never against one provider treated as truth.
Guides
The rankings answer which endpoint to call. These answer the questions that come before that, and the ones that come after deciding not to call anybody else's — general where the problem is general, and per chain where it is not.
Every ranking, method result and validator record on this site is served by a versioned public REST API. Same numbers, same windows, no key required.
curl https://api.rpcnode.io/api/v1/rankings?chain=ethereumAPI reference