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 128th block does not finalise without a certificate of at least six of nine valid Falcon-512 validator seals bound under its block hash. Live since block 13,014,000, at a quorum of six since block 14,961,456.
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.
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.
What we do not claim
- Not "no block finalises without post-quantum signatures". Only anchor blocks carry a certificate.
- Not "post-quantum consensus". Proposal, identity, transport and per-block finality are secp256k1
ECDSA. The anchor is a binding on top, not a replacement.
- Not "the only chain that can do this". Other codebases can bind post-quantum signatures under a
block hash. The claim we make is narrower and is about verifiability: no public chain has a post-quantum validator certificate under the block hash that is proven and independently verifiable. You can check ours in three commands; 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.