The anchor is the part of AERE that is proven and independently verifiable. This page states it exactly, including the parts that make it smaller than it sounds.
The claim, in one sentence
Every 32nd block of chain 2800 does not finalise without a certificate of at least seven valid Falcon-512 validator seals, of the ten validators, bound under its block hash.
Three of nine before block 14,961,456; six from that height, which was then as many as the 2f+1 quorum of nine; the seals prove those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01). The set grew to ten validators on 2026-09-11 and the threshold stayed at six, above f+1 and below the quorum of seven, until block 20,715,632 (2026-09-29, AIP-22 stage 1) raised it to seven, as many as the quorum of the ten. Every 32nd block before block 17,225,968; every 128th from that height to block 20,746,736; every 32nd again since then (AIP-22 stage 2), with SLH-DSA-SHA2-128s seals required as well at every 128th block.
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 32 blocks, roughly 20 seconds (128 blocks, roughly 75 seconds, from 2026-09-05 to 2026-09-29). 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. (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.)
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 per-block finality post-quantum. Per-block finality and node-to-node transport
are secp256k1. Consensus messages also carry Falcon-512 seals: every validator requires one on a commit, and nine of the ten, the validators that run the AERE client (Besu-derived, see Client diversity), on all four message types since block 17,700,000; the tenth runs the independent second client, which applies the rule to the other three 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). The decision recorded in each header is still the classical one. The anchor is a binding, not a replacement. (Until 2026-09-30 this line listed identity as classical. Corrected 2026-10-09: until that date it gave the height 17,700,000 without saying which client requires the seal on which messages.)
- 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, as many as the 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. |
| 20,715,632 | Minimum 7 of 10 per scheme, as many as the 2f+1 quorum of the ten validators (AIP-22 stage 1). |
| 20,746,736 | Falcon-512 at every 32nd block again, SLH-DSA-SHA2-128s at every 128th (AIP-22 stage 2). |
| 20,836,228 | Validators named by post-quantum ids in the header and in qbft_getValidatorsByBlockNumber (AIP-22 stage 3). |
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.