The anchor is the part of AERE that no other public chain has in a form you can check. This page states it exactly, including the parts that make it smaller than it sounds.
The claim, in one sentence
Every 128th block of chain 2800 does not finalise without a certificate of at least six of nine valid Falcon-512 validator seals bound under its block hash.
Three of nine before block 14,961,456; six of nine, a full 2f+1 quorum, from that height. Every 32nd block before block 17,225,968; every 128th from that height.
How the binding works
The block hash in QBFT is not keccak over the raw header: seals are stripped and the round is zeroed before hashing. So anything a decoder discards is discarded before the hash. The certificate itself therefore does not go under keccak directly.
What goes under keccak is a 32-byte digest of the certificate, carried in vanityData, element 0 of extraData, which is already inside the hashed pre-image. Changing one byte of the certificate changes the digest, which changes the block hash, which breaks every child block.
What it protects, and what it does not
An adversary who holds every classical validator key and no Falcon key can rewrite at most the tail since the last anchor. That is a fork depth of at most 128 blocks, roughly 70 seconds. Rewriting anything below an anchor changes that anchor's parent hash, forces the anchor to be reproduced, and reproducing it requires Falcon signatures the adversary does not have.
What it does not do:
- It does not make ordinary blocks post-quantum. Blocks between anchors carry no Falcon seals and
are finalised by ECDSA alone.
- It does not make consensus post-quantum. Proposal, identity, transport and per-block finality are
secp256k1. The anchor is a binding, not a replacement.
- It does not give slashable safety. A validator that signs two conflicting anchors is not punished
by the protocol.
- It is not audited. No third party has reviewed this code.
Activation is by node configuration, not by genesis
This is a real caveat and we would rather state it than have it found. The anchor rules are armed through per-node system properties, not through a genesis milestone. Two nodes configured with different heights or different minimum seal counts do not agree on what a valid header is. The fleet is checked for uniformity, and a split configuration is treated as an open defect rather than a warning.
History
| Block | Change |
|---|---|
| 13,014,000 | Anchor rules armed. Minimum seals 0, a deliberate warm-up window. |
| 13,034,000 | Minimum 3 of 9, that is f+1, enforced on the fleet from 2026-08-14. |
| 14,961,456 | Minimum 6 of 9, a full 2f+1 quorum, the same count QBFT itself requires. |
| 17,047,600 | Certificate format v2, hybrid. See Hybrid certificates. |
| 17,225,968 | Interval moves from every 32nd block to every 128th. |
A correction we published against ourselves
Until 2026-08-19 our own site, whitepaper and press releases said that from block 14,050,000 no block finalises without a six-of-nine post-quantum quorum. That was false. The property armed at that height is a per-block rule that the shipped code retires at the anchor activation, so nothing changed at 14,050,000. The correction was published the same day in seven languages. The formulation on this page is the one that survives being checked.
Check it rather than believe it
Verify an anchor yourself. Three commands, from an empty directory.