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 verifiers callable by any contract or any eth_call.
Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s and SHAKE256 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.
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 itself covers 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,568 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 the block hash no longer verifies. Since 2026-08-14 every node 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 (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01); 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 2f+1 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 on classical ECDSA under QBFT, 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 from AIP-22 stage 4, whose height is not yet set on chain 2800). 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 stage 5 of AIP-22, what decides each block (its finality) is the ECDSA commit quorum of one round, and the certificate proves participation, not the decision (AIP-22 erratum, 2026-10-01). 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 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