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 (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01), 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; individual blocks are still finalised by classical ECDSA. (With the exception named above, added 2026-10-01.)
What we do not claim
- Not "no block finalises without post-quantum signatures". Only anchor blocks carry a certificate.
- Not "post-quantum finality" for every block. Per-block finality and node-to-node transport are
secp256k1 ECDSA. 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 from AIP-22 stage 4, whose height is not yet set on chain 2800; validators are named by post-quantum identities (since block 20,836,228, 2026-09-30); 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.