README, SPEC, RUN-A-NODE, SECURITY, AUDITS and anchor/README now state the live rules: at least seven of
ten seals per scheme from block 20,715,632 (stage 1), Falcon-512 at every 32nd block and SLH-DSA-SHA2-128s
at every 128th from block 20,746,736 (stage 2), post-quantum validator ids in the header and in
qbft_getValidatorsByBlockNumber from block 20,836,228 (stage 3). Stages 4 and 5 are not active on chain 2800.
tools/verify-anchor.mjs: the FINALIZED line said on every chain that a header between anchors carries only
its proposer's seal, which is true only where AIP-22 stage 5 is active (testnet 28001). It now reports what
it measured: on chain 2800 headers between anchors carry the validators' classical ECDSA commit seals.
Checked on both chains on 2026-10-01: chain 2800, 4/4 anchors verified, ECDSA branch printed; testnet 28001,
2/2 anchors and 20/20 proposer seals verified, stage-5 branch printed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One document from which a third party can implement a client that follows chain
2800 without reading our code: chain parameters, QBFT with the full extraData
layout and what the block hash does and does not cover, the post-quantum anchor
rules with exact pre-images and the follower configuration, precompile formats
with the message in the middle and variable signature lengths, fee rules with
their historical windows, sync requirements including the genesis-set ceiling,
and the formal models with their honest boundaries.
Every normative statement carries a file citation, a [MEASURED <date>] marker
with the command, or [NOT MEASURED]. Section 8 documents twelve dated
divergences a syncing client will meet on the real chain (the 2138451 transition
value that must not be corrected, the base-fee lapse window, the anchor disarmed
window, the threshold window, the retired falcon.forkBlock rule), because a spec
that hides history cannot sync anyone. Section 9 lists ten things this spec
cannot state from published sources, by name, rather than papering over them.
