The Post-Quantum Stack
Six layers, from a signature primitive an account can call today to a consensus rule under which every 32nd block does not finalize without a post-quantum validator certificate. Each layer states what is live, what is armed, 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. 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.
No protocol change · EVM at Ethereum parity
The block record
The block hash itself covers a post-quantum certificate of the validator set.
Since block 13,014,000, every 32nd block header carries a certificate of Falcon-512 signatures from the validators over the parent block, 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; since 2026-08-16 the cap is nine, and certificates in practice carry all nine.
Live since block 13,014,000 · min 3 seals · digest under the block hash
The signer registry
The nine signing keys are bound on-chain in an immutable contract anyone can read.
The registry that says which key belongs to which validator is not shared configuration a node could quietly change. Its keccak is held in the storage of an immutable contract at 0x5214F0e53899Dad805ef3AdF0624F5e49d2a5EB5, deployed with no writable path, so the binding cannot be altered after the fact. You can read the bound hash yourself with eth_getStorageAt and compare it to the published manifest: the verifier below does exactly that, and also checks every key against the validator's own signature over it.
9 entries · immutable contract · readable via eth_getStorageAt
Consensus finality
Live: since block 13,034,000 every 32nd block does not finalize without a certificate of at least three valid post-quantum validator seals 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. Apart from anchor blocks, consensus signatures are classical ECDSA under QBFT, and this page says so. At and after it, the finality of every block depends on a certificate of validator Falcon signatures: a node presented with a block that lacks one will not accept it. Nine keyed validators give the layer a real fault margin (f=2), which is why the arming guard refuses a smaller set. The chain shows it: the switch is live, and the verifier below checks the record that proves it.
Anchor certificate enforced since block 13,034,000 · at least 3 of 9 seals (f+1), 8 or 9 carried
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. It produces no mainnet blocks yet; putting a second client into the producing set is a deliberate, founder-supervised step, because a bug in a producing client can halt a live chain.
Validates live chain 2800 · producing set remains single-client
See each layer yourself
# Layers 3 and 4: recompute the digest bound under the block hash, then verify every Falcon-512 seal against the on-chain-pinned key manifest curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.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