Post-Quantum Anchor

A post-quantum anchor ties a certificate of post-quantum signatures to a block by putting its 32-byte digest into the data that the block hash covers (corrected 2026-10-28: this sentence said the certificate itself is in that data). The problem it addresses is retroactive. Classical signatures stay verifiable in the record forever, so an attacker who later recovered old validator keys could, in principle, re-sign an alternative history that looks as valid as the real one. An anchor leaves periodic evidence in the chain that was signed with a scheme designed to resist that recovery, and it binds a 32-byte digest of that evidence under the block hash, so a certificate detached or replaced afterwards no longer matches the digest and the anchor fails validation; the block hash itself does not change (corrected 2026-10-27: this sentence said the evidence cannot be detached or replaced).

On chain 2800 the anchor has been live since block 13,014,000. Every anchor block header (every 32nd block; every 128th from 17,225,968 to 20,746,736) carries a seal certificate of post-quantum signatures (Falcon-512 at every anchor and, since 2026-09-04, SLH-DSA-SHA2-128s as a second, hash-based scheme, every 128th block since 2026-09-29) from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. The rule enforced today requires at least 7 signatures of each required scheme per anchor block, as many as the quorum of the ten validators (3 from 2026-08-14, 6 from 2026-08-21, 7 since block 20,715,632 on 2026-09-29; 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); in practice certificates carry 8 to 10. The signers are the 10 entries (9 until 2026-09-11) of the signer registry, committed on chain, in an immutable contract whose storage holds the registry keccak, for the epochs up to the one of block 18,082,816 and, for the epoch in force since block 20,836,228 (post-quantum ids, the same keys), pinned by its hash in the node configuration.

The boundaries that remain: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. Under QBFT on chain 2800 every header carried the ECDSA commit quorum until block 25,080,000 (AIP-22 stage 5) and carries the Falcon-512 seal of its proposer from it, and since block 24,300,000 (AIP-22 stage 4) every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check; for a validator a block is final on import (its finality), and its post-quantum proof is the certificate of the anchor that covers it; a node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). The anchor adds post-quantum evidence to the record; the changes to the votes and the headers are separate stages of AIP-22. The Falcon-512 verification the anchor relies on is itself available on-chain: five post-quantum precompiles have been live since block 9,189,161 at addresses 0x0AE1 to 0x0AE5, validated against NIST test vectors.