Live health of the services this page can actually measure. Every number on this page is read from the chain or from the service itself when the page loads, except in the network parameters card, which lists configured values and says so. Nothing else here is written down in advance.
Every 32nd block (every 128th from block 17,225,968 to block 20,746,736) carries, under its block hash, a certificate of validator post-quantum seals, with at least seven validators per scheme since block 20,715,632, as many as the quorum of the ten (six from 2026-08-21, six of the nine of that time; below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision); the certificate carries SLH-DSA-SHA2-128s seals next to Falcon-512 at every 128th block (at every anchor from block 17,047,600 to block 20,746,736). Every validator refuses a commit without a post-quantum seal, and nine of the ten refuse any QBFT message without one. On the nine validators that run the primary, Besu-derived client the four message types are refused without a seal from blocks 17,250,000 (commit), 17,400,000 (proposal), 17,550,000 (round change) and 17,700,000 (prepare); the tenth validator, which runs the independent second, Nethermind-derived client, refuses an unsealed commit from block 18,131,633 and the other three types since block 24,300,000 (AIP-22 stage 4, 2026-10-25). Which of those are in force, client by client, is computed here from the latest block, not written down in advance. (Corrected 2026-10-09: until that date this paragraph gave the four heights without naming the client, and the two cards above counted the primary client's layers alone, so they read "4 of 4" and "all four in force" for every validator.) The certificate itself is verified from raw header bytes by verify-anchor.mjs; this card reads the header, counts the seals of each scheme and compares them with the published minimum for that anchor, and verifies no signature. (Changed 2026-10-21: until that date this card said "yes" for any certificate of a known form, including one with no seals at all.)
"Proposing their share" counts how many members of the validator set proposed at least half of their fair share
(the window divided by the set size) of the blocks inside the node's recent signing window, read from
qbft_getSignerMetrics and matched to the set by address. A validator that proposes one block in a hundred
is present but not healthy, and this card says so. "Latest block" asks the node whether it is still syncing, and turns
red when it is. The line under the cards reads the same block from both public RPC doors and compares its hash, not
its height, because two nodes can stand at the same height on different chains. (Changed 2026-10-21: until that date
the share card counted any validator with one block in the window, the page did not ask whether the node was syncing,
and it read only one of the two public doors.)
This card lists configured values and the contract suites deployed on chain 2800; apart from the block time, nothing in it is measured when the page loads. Deployed is not the same as in use: on 2026-10-15 none of these suites carried third-party traffic, the paymasters held no deposit, the price oracle had no reporters, the cross-chain messenger carried no route, and no developer fee share was being paid. The 37.5% burn share is enforced by the splitter contract; what it has burned is in the tracker below.
The burn share is a cut of the validator reward, not of the base fee, and on an idle
chain it is close to nothing. AereFeeBurnVault has no withdraw function and no admin, so native AERE
that arrives there is out of circulation whether or not the optional sweepToZero() step
has been called, and that step has been called: the vault forwards what it receives to address(0), so its
own balance stays near zero. What the vault holds plus what it has forwarded comes from one contract, the
splitter counter from another, and the two should agree; the line above says whether they do.
FeeBurnVault contract ·
CoinbaseSplitter contract
A browser cannot always tell a service being down from a service refusing to answer this page. When it cannot tell, the light reads NOT MEASURED. It never reads UP on a guess.
A 200 on an HTML file proves the file is served, not that the application behind it works, so this page no longer carries a reachability grid for the dApp pages. Open any dApp from the dApps directory to see its own live state.
The first number is the length of the list this page carries, so it cannot drift away from it.
The second is measured with eth_getCode against the live chain, which is the check that
catches a contract address that points at nothing. Browse the full set in the
block explorer.