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>
Both are prerequisites for any external review programme, and one of them was already
promised by our live security.txt to a file that did not exist.
SECURITY.md states the scope, the response times we hold ourselves to, and three things
we would rather a reviewer heard from us than discovered: there has been no third-party
audit, every validator is operated by the Foundation, and the post-quantum guarantee is
at anchor heights rather than on every block.
AUDITS.md opens by saying we have had no third-party audit, and keeps that first line
until it stops being true.
