Ethereum
~12s blocks · chain id 1
- Providers
- 9
- Endpoints
- 12
- Validators
- 926K
Fastest right now
- 1Tenderly32 ms
- 2PublicNode40 ms
- 3NodeReal99 ms
p95 response time over 24 hours · 37,808 samples for the leader
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.
Leading right now
Measured over 24 hours from 4 vantage points.
Collecting right now
Connecting581,304
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 4 probe regions
12 providers · 28 methods · 3 chains
Observations / 24h
581,304
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
Fastest right now
p95 response time over 24 hours · 37,808 samples for the leader
~450ms blocks · chain id 56
Fastest right now
p95 response time over 24 hours · 37,227 samples for the leader
~420ms blocks
Fastest right now
p95 response time over 24 hours · 43,346 samples for the leader
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.
Propagation
Every provider is subscribed at the same moment from one process, and each announcement is stamped by the same clock before any parsing. What is published is how far behind the earliest one each provider was.
First to announce
Led on 98% of 183,387 blocks, against 2 providers subscribed at the same moment.
next: NodeReal +300 ms median
First to announce
Led on 92% of 6,671 blocks, against 3 providers subscribed at the same moment.
next: dRPC +100 ms median
First to announce
Led on 65% of 42,478 slots, against 2 providers subscribed at the same moment.
next: PublicNode +16 ms median
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