The Post-Quantum Stack
Six layers, from a signature primitive an account can call today to a consensus rule under which every 32nd block (every 128th from block 17,225,968 to block 20,746,736, 2026-09-05 to 2026-09-29) does not finalize without a post-quantum validator certificate. Each layer states what is live, what is not yet, and the number that backs it.
Verification primitives
Five post-quantum precompiles callable by any contract or any eth_call: four signature verifiers and the SHAKE256 hash function.
Falcon-512, Falcon-1024, ML-DSA-44 and SLH-DSA-128s (the signature verifiers) and SHAKE256 (a hash function, which verifies nothing by itself) run as native precompiles at addresses 0x0AE1 through 0x0AE5. They have been live on mainnet since block 9,189,161 and are validated against the published NIST test vectors on-chain. ML-DSA-44 checks the FIPS 204 internal form of the message: a standard signature over a message M with an empty context is checked by passing the bytes 0x00 0x00 followed by M. Five algorithms rather than one is the point: a contract can pick a lattice scheme or a hash-based scheme at runtime, so no application is hostage to a single family. (Corrected 2026-10-27: the heading of this layer called all five verifiers.)
Live since block 9,189,161 · 5 addresses · NIST-vector checked
Account and application authorization
Any account or contract can bind its authorization to a post-quantum key today, with no protocol change.
Because the primitives are on-chain, a smart account verifies a Falcon or SLH-DSA signature the same way it verifies anything else. This is the additive layer: adopting post-quantum authorization is a contract deployment, not a fork, and it touches no operator. The honest boundary, stated plainly: a post-quantum check invoked from a transaction still authenticated by classical ECDSA inherits ECDSA's exposure. The durable posture is to move the account's own authorization onto a post-quantum key. Since block 19,900,000 (2026-09-23) the chain also accepts a native post-quantum transaction (AIP-20, type 0x50) signed with ML-DSA-87 and carrying no classical signature at all; ordinary ECDSA transactions remain the default.
No protocol change · Prague and Osaka EVM rules (the EIP-4788 beacon-roots contract has no code)
The block record
The block hash covers a 32-byte digest of a post-quantum certificate of the validator set.
Since block 13,014,000, every anchor block header (every 32nd block; every 128th from 17,225,968 to 20,746,736) carries a certificate of post-quantum signatures from the validators over the parent block (Falcon-512 at every anchor and, since block 17,047,600 on 2026-09-04, SLH-DSA-SHA2-128s as a second, hash-based scheme, on every fourth anchor since block 20,746,736), and a 32-byte digest of that certificate sits inside the hashed part of the header. Strip or alter the certificate and it no longer matches that digest, so the anchor fails validation; the block hash itself does not change (aere-node SPEC.md, section 2.3; corrected 2026-10-27: this sentence said the block hash no longer verifies, and the line above it said the block hash covers the certificate itself). Since 2026-08-14 every validator enforces a minimum of three seals per anchor block, raised to six seals, then as many as the quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six was below the quorum of seven until block 20,715,632, on 2026-09-29, raised the minimum to seven, as many as the quorum of ten (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); a node started from the published node package lowers that count to one seal (aere-node SPEC.md, section 6.4; corrected 2026-10-27: this sentence said every node enforces the minimum, and dated the SLH-DSA seals from block 17,047,568, the last anchor with Falcon-512 seals only); the cap was nine from 2026-08-16 (the Nethermind validator, in the set since 2026-09-11, attached up to ten, and a Besu validator first attached ten on 2026-09-27), and certificates in practice carry eight to ten seals (measured 2026-10-01).
Live since block 13,014,000 · min 7 seals per scheme · digest under the block hash
The signer registry
The ten signing keys are bound on-chain in immutable contracts anyone can read.
The registry that says which key belongs to which validator is pinned on chain, not left to shared configuration a node could quietly change. The keccak of each key manifest sits in slot 0 of an immutable contract with no writable path: the ten keys in force since block 18,082,816 at 0xC01Bb2843EFAF92D8389F14aC1dD26dbeAf9144C, the nine before them at 0x5214F0e53899Dad805ef3AdF0624F5e49d2a5EB5, the first seven at 0x5A98D2EA8F1a41ec189499Ce9837A5409611ac4e. Since block 20,836,228 (2026-09-30) the validators are named in consensus by post-quantum ids from a version-3 registry whose hash is pinned in the nodes' configuration rather than in a contract; it carries the same ten keys, and the verifier below refuses it if they differ from the keys pinned on chain. You can read a bound hash yourself with eth_getStorageAt and compare it to the published manifests: the verifier does exactly that, proving the slot under the state of a block the validators certified, and also checks every key against the validator's own signature over it.
10 entries · immutable contracts · post-quantum ids since block 20,836,228
Post-quantum anchor certificates
Live: since 2026-08-14 every 32nd block (every 128th from block 17,225,968 to block 20,746,736, 2026-09-05 to 2026-09-29) does not finalize without a certificate of at least three valid post-quantum validator seals (raised at block 14,961,456, August 21, 2026, to six seals, then as many as the QBFT quorum of nine; from 2026-09-11 the set was ten and six sat above f+1 but below its quorum of seven, until block 20,715,632, on 2026-09-29, raised the enforced minimum to seven, as many as the quorum of the ten validators) under its hash.
Correction 2026-08-19: the per-block post-quantum quorum rule armed at block 14,050,000 (aere.falcon.forkBlock) is, in the shipped code, retired in favour of the anchor rules from 13,014,000 and changed no enforcement; the earlier claim that every block required it to finalize is withdrawn, and what is enforced is the anchor certificate above. Per-block finality rests, for a validator, since block 24,300,000 (AIP-22 stage 4), on votes that every validator attributes only through their verified post-quantum seals (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check), and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it, and this page says so; every validator refuses a commit without a post-quantum seal, and nine of the ten refuse any consensus message without one (the tenth runs the independent second client, which applies that to proposal, prepare and round-change messages since block 24,300,000 (AIP-22 stage 4, 2026-10-25)). From block 13,014,000, every anchor block requires a certificate of validator post-quantum signatures: a node presented with an anchor block that lacks one will not accept it. Until block 25,080,000 (stage 5 of AIP-22), the header of each block carried the ECDSA commit quorum of one round; from that block it carries the Falcon-512 seal of its proposer instead, which admits the header but does not decide the block, and 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). What decides each block is, as before, the commit quorum of one round, in which, 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, as before (its finality), and its post-quantum proof is the certificate of the next anchor, which since block 24,148,752 (stage R) carries the quorum of one round and proves the decision of the parent of its anchor, not only participation. Ten keyed validators (since 2026-09-11) give the layer a fault margin of f=3: with three validators down, an anchor still gathers the seven seals it needs. The chain shows it: the switch is live, and the verifier below checks the record that proves it.
Anchor certificate enforced since 2026-08-14 · seven seals per scheme since block 20,715,632 (2026-09-29), as many as the quorum of the ten validators · six from block 14,961,456 (2026-08-21), as many as the quorum of the nine validators then
Independent cross-check
A second, separately built client re-validates the chain and refuses what it cannot verify.
A second client, an independently implemented Nethermind fork, validates chain 2800 alongside the first, Besu-derived client, and since 2026-09-11 it also proposes and seals blocks as the tenth validator (nine of the ten run the first client; corrected 2026-10-28: this sentence called the first client the producing client). Because it enforces the rules on its own predicate, it has twice stopped at divergences it refused to accept rather than following silently: exactly the assurance a second implementation exists to provide. Since 2026-09-11 it is also the tenth validator of chain 2800: it proposes and seals mainnet blocks, and its post-quantum seals enter the anchor certificates. That is two producing implementations, not client diversity in the fault-tolerance sense: nine of the ten validators still run Besu, so the chain's liveness still depends on one code base; until 2026-09-11 it produced no mainnet blocks, and this page said so.
Validates and produces on live chain 2800 since 2026-09-11 · nine Besu, one Nethermind
See each layer yourself
# Layers 3 and 4: recompute the digest bound under the block hash, then verify every Falcon-512 and SLH-DSA seal against the on-chain-pinned key manifests curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/mpt.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/registry-v3.mjs -O https://aere.network/tools/package.json && npm install && node verify-anchor.mjs # the primitives (Layer 1): replay NIST vectors in your browser, read-only open https://aere.network/quantum-verify.html