API

Chains being measured, with their block time and the number of providers and endpoints configured.

One chain with its current provider ranking summary.

RPC methods with a benchmark scenario defined.

Every documented method with what it does, why it is measured, and the caveats that actually bite. Written against the primary specifications rather than from memory.

Providers measured on at least one chain, with the chains and transports each is measured on. `serves` maps a chain slug to the transports held for it, because a provider can serve Yellowstone gRPC on Solana and HTTP JSON-RPC elsewhere. It is a directory fact: the endpoint exists and is measured, not that it answered. Providers marked private are measured but never named here.

One provider's endpoints, per-chain scores and measured latency. Endpoint URLs are sanitised: a URL that carries a credential is shown host-only.

Vantage points. Latency is a property of a network path, so where a measurement was taken is part of the measurement. A region that collected nothing in the window is attributed nothing.

The deepest point in history each endpoint will answer about, in the chain's own unit — blocks on an EVM chain, slots on Solana.

A capability rather than a performance measurement. Every other scenario on this platform is head-adjacent, which measures the easy case: every provider serves the head competently, and they differ at depth. An archive node and a pruned one look identical at the tip and nothing alike a million blocks back.

Three kinds are asked separately, because providers differ on each: a block header, a state read at that height, and a log range. A node can keep every header and no historical state; a free tier can serve state and cap log ranges.

Fixed rungs — 1k, 10k, 100k, 1M, 5M — rather than a binary search for the exact boundary. The exact boundary moves with the head every block and means nothing to a reader; an order of magnitude is the answer, and fixed rungs make two providers directly comparable.

Nothing is claimed from an ambiguous refusal. Rate limiting, and a bare 401 or 403, are recorded as not measured: they can mean the provider does not serve that depth or that we asked too often, and those are not distinguishable from here.

How far behind the cohort head each provider's reported head sits, in that chain's own blocks or slots. A chain is required: blocks and slots are different quantities on scales that differ by 27x, so a cross-chain lag table would be arithmetic on incomparable units.

Outages, degradations and sustained throttling, newest first.

Derived from per-minute measurement aggregates rather than stored, so the feed cannot describe something the observations do not, and a change to what counts as an incident applies retroactively rather than only going forward.

Three exclusions are deliberate. Our own failures — an agent that could not reach the network, our own software failing — are our outage, not the provider's, and are removed before anything is judged. Rate limiting is reported as its own kind rather than as failure: a provider enforcing its published limits is behaving correctly, though a sustained refusal is still a fact a caller needs. A single bad minute is a blip, not an incident.

Durations are floors. Only minutes with evidence are counted, and a gap longer than the tolerance ends an incident rather than being spanned — so an incident is never reported as longer than what was measured inside it.

Which providers answer which methods. An unsupported method is a capability fact, not a failure, and is excluded from availability scoring. A method that was called and failed every time is reported as failing rather than as not measured.

The reference entry for a method together with how every provider handles it over time, including a degradation timeline. Degradation is measured against a provider's own median for the method over the window, not against the cohort — a provider that is consistently slower than its peers is not degraded, it is slower, and the ranking already says so.

How far behind the earliest announcement each provider was, per block or slot. Returned as a list of cohorts — chain, transport and subscription together — which are NOT comparable with each other. Absolute subscribe-to-first-notification time and win counts are deliberately not published; the response says why.

Composite score per provider: availability, latency, correctness and freshness, weighted by the values in settings and normalised against the cohort. Below the minimum sample count a provider is reported as having insufficient data rather than given a good score.

The same measurements broken out by where they were taken. Latency is a property of a network path, so a single global ranking answers "fastest from where the measurement was taken" while appearing to answer "fastest"; this makes that visible.

Percentiles cover successful responses only. A request that timed out is not a latency sample — it is counted against availability instead.

Each provider's 95th percentile over a recent window against its own over the days before it, per method.

Compared against itself rather than against the cohort. The ranking already says who is slower than whom, and a provider that has always been the slowest of nine is not regressing — it is slow, which is a different sentence. This is the principle of ADR 005 applied to time instead of to peers.

A ratio rather than a difference: twenty milliseconds is a catastrophe on a call that normally takes five and noise on one that takes eight hundred. Both spans are merged t-digest states built the same way, which is what makes them divisible by each other at all.

Improvements are reported alongside deteriorations, because the same measurement catches both and publishing only one would make this an accusation service.

The client software behind every measured endpoint, as the endpoint reports it.

`web3_clientVersion` and `getVersion` are already measured on every cycle for their own sake, and their answers used to be validated and thrown away. Keeping them makes a census of the public RPC estate a by-product of work already being done rather than new load on anybody's servers.

Self-reported, and unverifiable from outside. A gateway can return any string. A load balancer in front of forty nodes answers for whichever one took the request. An operator can leave the banner at a default that stopped being true two upgrades ago. Every row therefore carries `identity`, the raw string, alongside the fields parsed out of it, so any derivation can be checked against what was actually said.

An endpoint naming its own product rather than a client — `kind: "product"` — is answering, not evading: it is saying the node behind it is an implementation detail, which for a load-balanced gateway is the truthful answer.

`feature_set` is Solana's and null elsewhere. Two nodes on one version with different feature sets have activated different rules, which the version string alone would hide.

One chain's providers as a status page reads them: a current state per provider, a daily uptime history, attainment against a published objective, and the recent incidents.

This is an SLO, never an SLA. An SLA is a contract a provider entered into, with a remedy when it is broken. Almost none of the endpoints measured here carry one, so the objective here is a bar we publish and apply identically to everyone; missing it is a fact about that bar as much as about the provider. What a provider does commit to, where it commits to anything, is quoted on its own resource with a source and a date.

Attainment is a ladder, not a pass mark. A single threshold says little: set at 99.9% almost every free endpoint fails, set at 99% almost everything passes. Each provider is reported at the highest rung it actually cleared, and `attainment_known` is false — rather than the tier being empty — when too few requests were eligible to say. Not knowing and failing are different findings.

The chain-wide state is the worst component, not the average. Nine healthy providers and one in outage average to something that reads fine, while the reader who depends on the tenth is down.

The error budget is counted in requests. A budget in minutes would imply continuous observation; this platform samples. It is scaled to the share of the window actually observed, so a provider three days into a ninety-day window is judged against three days of allowance rather than ninety.

A day nothing was measured carries state `unmeasured` and is excluded from every uptime figure rather than counted as a perfect day.

Ranks providers for a place, measured from the nearest vantage point we operate.

This does not predict your latency, and it is not measured from your host. It names the nearest region we have a probe in, reports how far away that is, and returns what that probe actually measured. `confidence` is derived from that distance alone: `high` within 500 km, `moderate` to 2,000 km, `low` beyond it. Read a `low` result as a statement about our coverage rather than about your location.

Pass `ip` for the host that will make the calls — usually a server, not the browser asking. Pass `region` to skip geolocation entirely. With neither, the caller's own address is used, which is a convenience for pre-filling a form and is frequently the wrong host.

No ranking is returned here, on purpose. This answers the caller-specific half; the ranking for a region is identical for everybody who asks about that region, so it stays on `/rankings`, where it is cached once and shared. Take `measured_from` from this response and pass it as `region` there.

Geolocation is a local database lookup. No third party is contacted, and the address is neither logged nor stored. Responses are `no-store`, because the answer is computed for one caller.

Headline counts across the platform: observations, providers, endpoints and regions.

Bucketed latency percentiles. The bucket size follows the window so a query reads a few hundred buckets whatever the range.

The Nakamoto coefficient, the Herfindahl index and the top-N shares for every chain.

Each figure names the unit it counts, and the units differ because the chains do. On Solana and BNB Smart Chain a validator is an operator. On Ethereum it is not — a validator is 32 ETH and one pool runs hundreds of thousands of them, so counting validators would report Ethereum as the most decentralised chain here by a factor of ten thousand, when it is the one where a single party controls the largest share. Ethereum is therefore grouped by withdrawal address.

Nothing here is comparable across chains without reading the unit.

Slashings, jailings, delinquencies, exits, activations and commission changes, newest first.

Derived from the validator change log rather than stored: the indexer writes a row whenever a validator's status, stake or commission moves, and every event here is a pair of consecutive rows. The feed therefore cannot drift from the history it describes.

Two things are deliberately not events. A first sighting is not one — every validator would produce one on the day indexing began, burying the real events under the whole set. Stake is not one either: Solana restakes rewards automatically every epoch, so it changes constantly by construction, and 700 rows per epoch saying "the chain worked" is not news. A commission is reported only where the chain gave a value both before and after — learning a figure is not the operator changing it.

Two kinds of feature, and the difference is the whole point.

A validator feature is keyed by validator identity, and exists only where the chain publishes an address per validator — of the three measured here, only Solana does. One feature per validator rather than per address: a Solana validator advertises gossip, TPU, TVU and repair addresses that are almost always the same host.

A node feature is a member of the chain's peer-to-peer network, met by walking that network's own discovery protocol and attributed to the chain by the fork identifier in its own record. It says where the network is hosted and nothing about who operates it or what it validates. `summary.crawls` reports what the last walk met and how much of it could be attributed, because a discovery table is always partially explored and a node count without that context reads as the size of the network.

Coordinates are the approximate location of an observed address, never a claim about an operator. Unlocated stays unlocated; no country centroid is substituted.

Who is producing Solana blocks, and who is scheduled next.

Solana is the only chain here that publishes its leader schedule: all 432,000 slots of an epoch are assigned before the epoch begins. Ethereum publishes proposer duties only a short way ahead and BNB Smart Chain's rotation is derived rather than published, so this route is Solana-specific rather than chain-agnostic and mostly empty.

Two different kinds of number are returned, and they are labelled. The schedule and `observed_slot` are measured — the slot is sampled from `getEpochInfo` every 30 seconds and `observed_at` says when. `projected_slot` is arithmetic: elapsed time divided by the target slot time, with `projected_slots` giving the size of the leap. Solana does not produce slots on a metronome, so a consumer that wants only measurement should read `observed_slot` and ignore the projection.

When a Solana identity next leads, and how many slots it holds this epoch.

Returns an empty list with an explanatory note for an identity that is not in the current schedule: a validator with no active stake produces no blocks, which is a fact about the epoch rather than a missing record.

What delegating to each BNB Smart Chain validator actually paid.

Every rate here is measured, with none of the fallbacks Solana needs. The difference is where the payment is written down: Solana reports what it paid the validator, so the delegators' share has to be recovered by dividing the commission back out, while each validator's StakeCredit contract records what reached the pool — which is what a delegator's stake grows by, commission already taken.

There is no protocol rate to check it against. BNB Smart Chain issues nothing for staking: validators are paid out of transaction fees, so the yield follows how busy the chain is rather than an emission schedule.

The window is seven days. A validator only earns while it is producing and the elected set of 45 rotates, so daily returns vary by roughly 15% around the mean — one day is a sample and a week is a rate.

The rate the consensus layer pays for staked ETH, and the queues to get in and out.

There is no validator leaderboard here, and its absence is the point. Ethereum reports no per-validator reward: earnings arrive as balance changes, and a per-validator figure would have to be modelled. A modelled number among measured ones is worse than none.

What is exact is the network rate. Consensus issuance is a closed form in the total active balance — `BASE_REWARD_FACTOR × epochs_per_year ÷ √balance` — so every input is observed and nothing is estimated. The square root is the design: the rate falls as more ETH is staked, without anything changing about any validator.

It excludes execution-layer tips and MEV, which are paid outside the protocol's accounting and are frequently the larger half. They are named rather than estimated.

What delegating to each Solana validator actually paid, and the network economics behind it.

Every rate says how it was arrived at. A measured rate is recovered from the payment the chain made to the validator's vote account, by inverting the commission that was in force when it was made — the delegators' own rewards are paid into individual stake accounts and are not reported anywhere.

A derived rate is the cohort's measured gross rate with this validator's commission and block production applied. It is used where no payment can be inverted, which is more common than it sounds: a validator charging zero commission is paid nothing, and 257 of 684 charge zero.

The network block carries both the cohort's measured gross rate and the protocol derivation from inflation and supply. They are computed from inputs that share nothing, and they agree — 5.3873% against 5.3784% when measured — which is what makes either publishable.

Every completed epoch this validator was paid for, with the commission in force and the stake behind it. The reward is the payment to the vote account, which is the validator's commission rather than its delegators' rewards.

One chain's validator set, ordered by stake. Paged with a hard ceiling — Ethereum has 897,000 validators, and an unbounded query would ask the database to serialise a gigabyte of JSON.

Counts per chain, plus how many observed addresses have been located.

Every validator that withdraws to one execution address, with the totals for the group. Ethereum only: a BNB Smart Chain validator registers a moniker on StakeHub and a Solana validator has an identity pubkey, so neither needs an address to be identifiable, and the route returns 404 for them.

This is what makes staking concentration visible — one address holds 31% of the set. The operator is named only where the address is a publicly documented protocol contract, with a link to that documentation; an explorer's crowd-sourced label is not enough to publish a claim about who controls stake.

A validator with its chain-specific detail and the network addresses it was observed advertising.

Recorded changes to stake and status. Written change-only: a pass over 897,250 Ethereum validators in which nothing moved produces zero rows.

The scoring weights, thresholds and sample floor currently in force, so a published score can be checked rather than taken on trust.

Returns 200 while the process is running. Does not check dependencies — a liveness probe that fails on a database blip restarts a healthy process.

Checks every dependency and reports each one. 503 when a critical dependency is down.