Read this page before the rest of the section. It is the part that most projects state in their own favour, and stating it accurately is the only reason the rest of our claims are worth anything.
Two separate things
There are two post-quantum mechanisms on chain 2800, at different layers, with different guarantees.
Layer one: verification inside the EVM. Five precompiled contracts verify NIST post-quantum signatures and hashes. Live on mainnet since block 9,189,161. Any contract can call them. They are a capability offered to applications.
Layer two: a certificate under the block hash. Every 32nd block does not finalise without a certificate of at least seven valid Falcon-512 validator seals bound under its block hash, as many as the quorum of the ten validators (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), and every 128th block needs SLH-DSA-SHA2-128s seals as well. Live since block 13,014,000; six seals from block 14,961,456 (then as many as the quorum of the nine validators of that time), seven since block 20,715,632 (2026-09-29); every 128th block from block 17,225,968 to block 20,746,736.
What the first one does not buy you
A post-quantum verifier called from a transaction that was authenticated with ECDSA provides no post-quantum security. The adversary does not attack the verifier. They forge the outer transaction.
This is not a subtlety we are being modest about; it is the whole argument. "Post-quantum precompiles are live" is true and it does not mean "accounts are protected". An account is protected only when moving its funds requires a post-quantum signature, which is an application-level construction on top of the precompiles, not a property of having them.
A second, equally hard point: "a primitive is an address you call" is not an architecture. It is the EVM since 2015, with 0x01 for ecrecover and 0x08 for pairings. Anyone can deploy a Dilithium verifier in Solidity on Ethereum today. The difference between that and a native precompile is gas, which is a number, not a thesis.
What the second one does buy you
The block hash is the thing every other node, light client and bridge already relies on. On chain 2800 that hash covers a 32-byte commitment to a certificate of post-quantum validator signatures. So an adversary who holds every classical validator key, and no Falcon key, can rewrite at most the tail since the last anchor. Rewriting anything below an anchor changes that anchor's parent hash, which forces the anchor to be reproduced, and reproducing it needs Falcon signatures the adversary does not have. (Added 2026-10-01: one exception, at the height of the anchor's parent, is named in the threat model after the AIP-22 erratum of that date.)
The honest boundary, in one sentence: history below the last anchor is bound by post-quantum signatures; the blocks above it carry no certificate of their own and are admitted on their ECDSA commit seals until AIP-22 stage 5, although since block 24,300,000 (AIP-22 stage 4) every vote counts only with its verified post-quantum seal; the transport between nodes is still secp256k1. (With the exception named above, added 2026-10-01.)
What we do not claim
- Not a post-quantum certificate in every block. Every validator refuses a commit without a valid post-quantum seal of its author and, since block 24,300,000 (AIP-22 stage 4), attributes every vote only through that seal (next point), but between anchors a node that does not take part in consensus checks only the header (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5); only anchor blocks carry a certificate.
- Not a post-quantum transport. Node-to-node transport is still secp256k1 ECDSA, and a block is post-quantum final only once the next anchor, at most 32 blocks later, carries the certificate that covers it. What is post-quantum in consensus today: every validator refuses a commit without a valid Falcon-512 seal of its author (all ten since block 18,131,633), and nine of the ten, the validators that run the AERE client (Besu-derived, see Client diversity), refuse any consensus message without one (since block 17,700,000); the tenth runs the independent second client, which applies the rule to the other three message types since block 24,300,000 (AIP-22 stage 4, 2026-10-25); validators are named by post-quantum identities (since block 20,836,228, 2026-09-30); since block 24,300,000 (AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal; and the anchors carry the certificate. The anchor is a binding on top, not a replacement. (Until 2026-09-30 this line listed identity as classical as well. Corrected 2026-10-09: until that date it said that every consensus message must carry a seal, without the second client's exception.)
- Not "the only chain that can do this". Other codebases can bind post-quantum signatures under a block hash. What we claim is narrower and is about verifiability: ours is proven and independently verifiable, and you can check it in three commands without asking us. See Verify an anchor yourself.
- Not audited. No third party has reviewed the anchor code.
Where to read the rest
- The five precompiles, with addresses and gas.
- Falcon input framing, which is where integrations fail.
- The certificate anchor, stated exactly.
- Threat model, including which quantum threat does not apply.