The certificate anchor

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, f+1, before block 14,961,456: a schedule step from block 13,034,000, at seven validators and at nine from block 13,082,148, held at an effective one by the emergency ceiling until 2026-08-14; six from that height, which was then as many as the QBFT quorum of nine, except one anchor, 17,102,384, under a dated one-anchor step of the minimum to zero on 2026-09-04; below block 24,148,752 the seals proved those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01), and from that block a certificate that carries the quorum of one round proves the decision. 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 makes it disagree with the digest under the hash, and the anchor fails validation; making them agree again means changing the digest, which changes the block hash and breaks every child block. Stripping or replacing only the certificate leaves the block hash itself unchanged (aere-node SPEC.md 2.3; corrected 2026-10-27: this paragraph said a changed certificate changes the digest and with it the block hash).

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 certificate of their own (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5), and since block 24,300,000 (AIP-22 stage 4) every validator attributes their votes only through verified post-quantum seals.
• It does not authenticate the transport between nodes, which is still secp256k1, and it does not count the votes: since block 24,300,000 (AIP-22 stage 4) every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check. 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 since block 24,300,000 (AIP-22 stage 4, 2026-10-25). 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

(Corrected 2026-10-27: the row of block 13,034,000 said "3 of 9" and the paragraph at the top said "three of nine"; at block 13,034,000 the set had seven validators, and the effective minimum was one until 2026-08-14. The one-anchor step at block 17,102,384 was missing from this history, although the published schedule carries it.)

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.