Reference

Methodology

Every rule below is the rule the running system actually applies, and every weight is read live from the settings the scorer uses — not from this page's prose.

What a score is made of

Availability: 40%
Latency: 30%
Correctness: 20%
Head freshness: 10%

Correctness is a ceiling

≤ 89

Below 99% correct, the composite is capped no matter how fast the provider is. A node returning wrong data cannot be presented as healthy.

Below this, no score

samples in the window. Under it a provider is reported as insufficient data rather than given a number the sample count cannot support.

Principles

Nothing is invented

Every published figure traces to a collected observation. Where a measurement does not exist, the interface says so rather than substituting a zero. “Never measured” and “measured as zero” are opposite facts and are never rendered the same way.

Failures are classified, not counted

A rate limit, an unsupported method and a TLS failure are three entirely different facts about a provider. Collapsing them into one error count destroys the ability to say anything useful, so each is recorded and treated separately.

Our bugs are never their outage

Failures caused by our own measurement software are recorded in their own categories and excluded from provider scoring entirely. A defect in RPCNode.IO must never appear as a provider failing.

Percentiles are real percentiles

Latency percentiles are computed in the database from mergeable t-digest states, so a 30-day p95 is a genuine merge of daily states rather than an average of averages. Averaging percentiles is a common shortcut that produces plausible, false numbers.

Measurement rules

Availability: Rate-limited requests and unsupported methods are excluded from the denominator. A provider enforcing its published limits, or not implementing an optional method, has not had an outage.
Latency: Percentiles are computed over successful requests only. A request that timed out is not a latency sample; it is counted against availability instead.
Correctness: Responses are validated against the chain and the method's expected shape. Correctness also caps the composite score: a provider returning wrong data cannot be presented as healthy however fast it is.
Head freshness: Chain head is compared against the cohort reference: the highest head any provider reached, after discarding heads implausibly far above the cohort median and time-aligning samples taken at different instants. No single provider is ever treated as truth.
Connection profiles: Warm measurements reuse a pooled connection; cold measurements dial fresh and include DNS, TCP and TLS setup. The two are never mixed.
Our own failures: Failures caused by RPCNode.IO itself are recorded separately and never counted against a provider.

Configuration in force

Read live from the running configuration. If a weight or a threshold changes, this table changes with it.

Platform settings currently in force
Setting	Value	Meaning
benchmark.cold_interval_s	900	Interval for cold-connection benchmarks, which include DNS, TCP and TLS setup.
benchmark.default_interval_s	60	Default benchmark interval when no policy overrides it.
benchmark.default_jitter_pct	20	Random jitter applied to every schedule so probes do not hit providers in lockstep.
capability.confirm_threshold	3	Consecutive consistent results required before a method's capability state changes. Transient errors are not evidence that a method is unsupported.
freshness.cohort_min_providers	2	Smallest number of distinct providers that may form a cohort head reference. Below this no freshness is recorded, because a provider compared against itself is not a comparison.
freshness.cohort_window_seconds	90	Maximum age of a head sample usable in a cohort comparison. Older samples are dropped rather than extrapolated across a long gap.
freshness.max_ahead_seconds	60	How far above the cohort median a reported head may sit before it is rejected as implausible rather than accepted as the reference. Without this guard, one provider returning a garbage height declares every honest provider stale.
freshness.stale_behind_seconds	30	How far behind the cohort head an endpoint may fall before its response is judged stale, measured as block-production time and converted to blocks per chain.
score.min_samples	30	Minimum samples in the window before a score is published. Below this the status is 'Insufficient data' rather than a number.
score.weight.availability	0.4	Weight of availability in the composite provider score.
score.weight.correctness	0.2	Weight of response correctness in the composite provider score.
score.weight.freshness	0.1	Weight of chain-head freshness in the composite provider score.
score.weight.latency	0.3	Weight of latency (scored on p95) in the composite provider score.
score.winsorize_pct	5	Percentile at which cohort values are winsorized before normalisation, so a single outlier cannot distort every other provider's score.
stake.min_epochs	1	Completed epochs required before a staking score is published. One by default: public RPC nodes prune the blocks rewards are credited in, so history accumulates at one epoch every two days rather than being fetchable, and three of the score's four components do not depend on epochs at all.
stake.weight.commission_stability	0.15	Weight of commission stability: how often the validator has changed its rate over the observed epochs.
stake.weight.decentralisation	0.15	Weight of the penalty for stake already concentrated in one validator. Delegating to the largest is individually rational and collectively harmful, and the ranking prices that in rather than recommending it.
stake.weight.performance	0.35	Weight of block production — the share of assigned leader slots that produced a block — in the staking score.
stake.weight.yield	0.35	Weight of net annual return, after the validator's commission, in the staking score.
status.degraded_success_rate	0.95	Success rate below which an endpoint is considered degraded.
status.hysteresis_windows	3	Consecutive evaluation windows a condition must hold before the status changes. Prevents a single failed request from flipping a provider offline.
status.offline_success_rate	0.5	Success rate below which an endpoint is considered offline.

Scenario versions in force

Every observation is stored with the version of the scenario that produced it. A figure computed under version 1 and one computed under version 2 are not the same measurement, and this is how a consumer of the API can tell — the version is the contract, not the method name.

Current scenario version per measured method
Method	Family	Scenario	Version
eth_blockNumber	evm	evm.block_number	1
eth_call	evm	evm.call_erc20_balance	1
eth_chainId	evm	evm.chain_id	1
eth_estimateGas	evm	evm.estimate_gas	1
eth_feeHistory	evm	evm.fee_history	1
eth_gasPrice	evm	evm.gas_price	1
eth_getBalance	evm	evm.get_balance	1
eth_getBlockByNumber	evm	evm.get_block_by_number	1
eth_getLogs	evm	evm.get_logs	1
eth_getTransactionCount	evm	evm.get_transaction_count	1
eth_getTransactionReceipt	evm	evm.get_transaction_receipt	1
eth_maxPriorityFeePerGas	evm	evm.priority_fee	1
eth_syncing	evm	evm.syncing	1
net_version	evm	evm.net_version	1
web3_clientVersion	evm	evm.client_version	1
eth_subscribe.newHeads	evm	evm.ws_new_heads	1
geyser.subscribeBlocksMeta	solana	sol.geyser_blocks_meta	1
geyser.subscribeSlots	solana	sol.geyser_slots	1
geyser.subscribeTransactions	solana	sol.geyser_transactions	1
getAccountInfo	solana	sol.account_info	1
getBalance	solana	sol.balance	1
getBlock	solana	sol.block	1
getBlockHeight	solana	sol.block_height	1
getClusterNodes	solana	sol.cluster_nodes	1
getEpochInfo	solana	sol.epoch_info	1
getHealth	solana	sol.health	1
getLatestBlockhash	solana	sol.latest_blockhash	1
getMultipleAccounts	solana	sol.multiple_accounts	1
getProgramAccounts	solana	sol.program_accounts	1
getSignaturesForAddress	solana	sol.signatures_for_address	1
getSlot	solana	sol.slot	1
getSupply	solana	sol.supply	1
getTransaction	solana	sol.transaction	1
getVersion	solana	sol.version	1
getVoteAccounts	solana	sol.vote_accounts	1
logsSubscribe	solana	sol.ws_logs	1
slotSubscribe	solana	sol.ws_slot	1

How validators are named

The three chains differ, and the site does not paper over it.

BNB Smart Chain: Validators register a moniker on StakeHub. The name shown is the one on chain.
Solana: Validators are identified by their node identity pubkey. Reading the operator name requires querying the Config program, which is an expensive call this platform does not make on a schedule.
Ethereum: Beacon chain validators have no name. A validator is an index and a BLS public key, and nothing on the chain says who runs it.

What can be derived for Ethereum is the execution address in the withdrawal credentials, and from it two things: how many other validators withdraw to the same address, and — where that address is documented by the operator itself — who the operator is.

The first covers every validator and is what makes staking concentration visible. The second is deliberately rare. A mapping is added only when it is verifiable from the operator's own documentation or from a contract whose identity is not in dispute. An explorer's name tag is not enough: those are crowd-sourced, and attaching one here would publish a claim about who controls a large share of the stake on the basis of a wiki edit. Where nothing is published, the site says so and shows the address.