Dated corrections (2026-10-28) from the tenth review round: AIP-7, AIP-10, AIP-13, AIP-15, AIP-16, AIP-20 and AIP-22 and seven research documents; each change states its date in the text (what the anchor certificate is bound by, the consensus note after AIP-22 stage 4, and the denial-of-service paragraph of AIP-20, which no longer claims per-peer limits on pool admission)

aips/AIP-10.md

@@ -1,5 +1,7 @@
 # AIP-10: Execution Client: Forked Besu with Nethermind as the Second Client, not Reth
 
+> **Note added 2026-10-28.** Where this document says that Besu is the sole live mainnet producer and that Nethermind is not yet a live producer on chain 2800, it describes the network until 2026-09-11. Since that date the tenth validator runs the Nethermind-derived client and proposes and seals blocks on mainnet; nine of the ten validators still run the Besu-derived client, so a fault in that client can still stop the chain, and two clients do not yet give the fault tolerance this document aims at. The decision it records is unchanged.
+
 ## Preamble
 
 | Field | Value |

aips/AIP-13.md

@@ -2,6 +2,8 @@
 
 > **Note added 2026-10-27 (consensus).** Where this document says that consensus remains classical (validators sign secp256k1 QBFT), read it as the statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a commit still carries the ECDSA commit seal of its validator as an additional check; headers are still admitted on their ECDSA commit seals until AIP-22 stage 5, and Aere does not claim post-quantum consensus. The decision this document records, two lattice families plus hash-based schemes, is unchanged.
 
+> **Note added 2026-10-28 (to the note above).** The note above ends the statement that consensus remains classical at block 24,300,000, but post-quantum layers were already part of consensus before that block, each dated in AIP-22: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash, and since 2026-09-05 the Besu-derived validators (nine of the ten since 2026-09-11) refuse any consensus message without a valid Falcon-512 seal of its author, while the second client enforced that seal on commit messages only until block 24,300,000. Read that statement as the per-block statement it was on the date of this document. That validators sign secp256k1 in QBFT is still true after block 24,300,000: every commit carries the ECDSA commit seal of its validator, as an additional check, and every consensus message the ECDSA envelope of the wire format, while a vote is attributed only through its verified post-quantum seal.
+
 ## Preamble
 
 | Field | Value |

aips/AIP-15.md

@@ -1,5 +1,7 @@
 # AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 ## Preamble
 
 | Field | Value |

aips/AIP-16.md

@@ -1,5 +1,7 @@
 # AIP-16: PQ STARK-Verify Precompile (0x0AE8)
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 ## Preamble
 
 | Field | Value |

aips/AIP-20.md

@@ -255,8 +255,15 @@ early is safe.
   ML-DSA signing paths in the reference repository each build their own message and none signs a
   caller-supplied value.
 - **Denial of service.** ML-DSA verification is slower than ECDSA recovery. The cost is paid in gas
-  before execution, the pool verifies before storing, and pool admission is subject to the existing
+  before execution and the pool verifies before storing; the verification cost is bounded and
-  per-peer limits; the verification cost is bounded and constant per `alg_id`.
+  constant per `alg_id`. A transaction that fails verification pays no gas, so what bounds it is the
+  network layer, and the two clients differ there (measured in their sources on 2026-10-28): the
+  primary client bounds the number of transactions and the size of each transactions message, hands
+  remote transactions to its pool without the peer that sent them and does not penalise a peer whose
+  transactions fail validation, so a peer can make it run one verification per fresh transaction it
+  sends; the second client disconnects a peer at the first transaction its validator refuses, which
+  is where an invalid type-`0x50` signature is refused. (Corrected 2026-10-28, see Errata: this
+  sentence said that pool admission is subject to the existing per-peer limits.)
 - **Transaction size.** Up to 7,219 bytes of authorization per transaction; pool and block size
   accounting count them like calldata (the gas charge above makes the economics explicit).
 - **Signature non-uniqueness.** Hedged ML-DSA signing yields different signatures for the same
@@ -367,6 +374,12 @@ type-0x50 transaction proposed by the Nethermind-derived validator on chain 2800
   it on all four message types. The second client requires it on commits since block 18,131,633 and applies it to the other
   three message types from AIP-22 stage 4, whose height is not yet set on chain 2800, as the note of 2026-10-05 under
   "Quantum threat model" states. Corrected in place, dated; nothing else changes.
+- **2026-10-28, Security Considerations, "Denial of service".** The sentence said that pool admission "is subject to the
+  existing per-peer limits". Measured in the sources of both clients on that date, the primary client has no per-peer limit
+  on transactions: its pool receives remote transactions without the peer that sent them, a peer whose transactions fail
+  validation is not penalised, and what is bounded is each transactions message (count and size). The second client
+  disconnects a peer at the first transaction its validator refuses. Corrected in place, dated; the transaction format, the
+  signing hash and every vector are unchanged.
 
 ## Post-Acceptance Outcome Record
 

aips/AIP-22.md

@@ -200,6 +200,8 @@ From `H_hdr` (at or above `H_fin`), `extraData` gains element 6, `proposerSeal =
 
 **Note added 2026-10-27 (to the correction above).** The correction says that one consensus message still carries ECDSA. Every consensus message still carries the ECDSA envelope of the upstream wire format, and both clients judge its form, though not its author: the Besu-derived client requires a low s (`SignedData`), and the Nethermind-derived client refuses a message whose envelope does not recover (`BesuQbftWire.Recover`). The D-454 quotas also classify a message by the key that signed its envelope. What the correction says of the commit seal is unchanged. The correction is kept as it was written.
 
+**Note added 2026-10-28 (to the note above).** "The D-454 quotas" in the note above, and in the Errata entry of 2026-10-27, is an internal name. It means the per-author quotas that a client keeps on consensus messages it holds before it can judge them; in the Besu-derived client these are the commits heard before the proposal of their round, kept within a quota per claimed author and per class of the envelope (signed by the same ECDSA key as the commit seal, or by another), in `AereD454PendingCommits` (patches 0009 and 0010 of the aere-node recipe).
+
 ### 6. Equivocation evidence and consequences without stake
 
 **Evidence object.** `PqEquivocation = [type, height, round, payloadA, sealA, payloadB, sealB, registryProof]` where `type` is one of the four message domains, the two payloads are the upstream RLP payloads of two messages of that type at the same height and round with different digests (for round-change, different `prepared digest` at the same target round), the seals are the two Falcon-512 seals of the same index over the respective pre-images of SPEC 2.6, and `registryProof` is the v3 Merkle path of that index's row in the epoch bound at `height`. The object is valid iff both seals verify under the row's Falcon key, the index is the same, and the digests differ. A second form, `PqConflictingAnchors = [anchorHeaderA, anchorHeaderB, registryProofs]`, two anchor headers at the same height with different parent hashes and each with a valid certificate of at least Q seals: by the quorum-intersection bound proved for all N in `formal-consensus/qbft_safety_smt.py` (L1: `2Q - N >= f + 1`), the two certificates share at least f + 1 = 4 indexes at N = 10, each of which double-signed. This is accountable safety: a finality violation names its authors by their post-quantum seals, and it needs `K = Q` (section 2), which is one more reason for that step.
@@ -414,6 +416,8 @@ Two refinements to the text above, recorded rather than silently applied: the Me
 
 - 2026-10-27, section 3.3, section 5 and Security Considerations: three dated notes. The row "message authorship" of table 3.3 required the envelope's recovered address to equal `row.ecdsa.addr` while that field exists; from `H_fin` the envelope is not examined for authorship. The correction of 2026-10-25 to section 5 named the commit seal as the one classical element of consensus messages; every message still carries the ECDSA envelope, whose form both clients judge and by whose signer the D-454 quotas classify. "Denial of service by seals" said that the per-peer limits of the clients apply and that a refusal costs 0.068 ms; neither client's consensus layer bounds one peer, and a forged proposal can cost about 1,025 Falcon-512 verifications. Found by an adversarial review of the draft that removes ECDSA from consensus messages.
 
+- 2026-10-28, the note of 2026-10-27 under section 5 and the Errata entry of that date: both named per-author message quotas by an identifier of an internal register ("the D-454 quotas"), defined nowhere in this AIP; a dated note under section 5 now says what they are and where they are in the source.
+
 ## Post-Acceptance Outcome Record
 
 Not accepted; nothing to record.

aips/AIP-7.md

@@ -2,6 +2,8 @@
 
 > **Note added 2026-10-27 (consensus).** Where this document says that AERE consensus is classical secp256k1 ECDSA QBFT and not post-quantum, read it as the statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a commit still carries the ECDSA commit seal of its validator as an additional check; headers are still admitted on their ECDSA commit seals until AIP-22 stage 5, and Aere does not claim post-quantum consensus. What this document records, a fork that changed the execution layer only, remains true.
 
+> **Note added 2026-10-28 (to the note above).** The note above ends the statement that AERE consensus is classical at block 24,300,000, but post-quantum layers were already part of consensus before that block, each dated in AIP-22: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash, and since 2026-09-05 the Besu-derived validators (nine of the ten since 2026-09-11) refuse any consensus message without a valid Falcon-512 seal of its author, while the second client enforced that seal on commit messages only until block 24,300,000. Read that statement as the per-block statement it was on the date of this document. The Abstract also calls the five precompiles verification precompiles: four of them verify signatures (Falcon-512, Falcon-1024, ML-DSA-44 and SLH-DSA-SHA2-128s) and the fifth, SHAKE256, is a hash function.
+
 ## Preamble
 
 | Field | Value |

formal-consensus/CONSENSUS-VERIFICATION-2026-07-12.md

@@ -1,5 +1,7 @@
 # AERE consensus, machine-checked SAFETY + LIVENESS verification (with Falcon quorum extension)
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.
 
 Date: 2026-07-12 · Scope: AERE QBFT / IBFT 2.0 (Hyperledger Besu, chain 2800) consensus and its

pq-finality-circuit/README.md

@@ -1,5 +1,7 @@
 # pq-finality-circuit
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 The off-chain research core of the Aere Network Post-Quantum Finality Certificate
 (research item #4).
 

pq-stark/README.md

@@ -1,5 +1,7 @@
 # pqc-fork/pq-stark - PQ STARK-verify precompile 0x0AE8 (BabyBear/Plonky3 FRI/STARK verify skeleton)
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.
 
 > **SCOPE CAVEAT (research finding, 2026-07-19; read before anything else).** The generic components

research/aip-draft-pqc-precompiles.md

@@ -11,6 +11,8 @@ created: 2026-07-11
 requires: EIP-7825 (per-transaction gas cap), RIP-7951 (P-256 precompile precedent), EIP-2537 (BLS12-381 precompiles precedent), FIPS 202, FIPS 204, FIPS 205, Falcon (NIST PQC round-3)
 ---
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Status update (2026-07-16): SHIPPED.** The AerePQC hard fork is LIVE on mainnet
 > chain 2800, activated at block 9,189,161 (2026-07-12). The five precompiles are
 > live at the address band `0x0AE1`..`0x0AE5` (Falcon-512, Falcon-1024, ML-DSA-44,

research/pqc-onchain-verification.md

@@ -1,5 +1,7 @@
 # On-Chain Post-Quantum Signature Verification on an EVM Layer-1 (AERE, Chain 2800)
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Note added 2026-09-24.** Validator-set figures in this document (seven validators, or nine) describe the set on the date it was written. Since 2026-09-11 chain 2800 has ten validators (f=3, commit quorum 7 of 10), all still operated by the Foundation, one of them running the second, Nethermind-derived client. The live set and its quorum are at https://aere.network/docs/network/consensus.
 
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.

research/specs/spec-antimev-mempool.md

@@ -1,5 +1,7 @@
 # AERE Anti-MEV Design: Threshold-Encrypted Mempool and Batch-Atomic Fair Settlement
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Note added 2026-09-24.** Validator-set figures in this document (seven validators, or nine) describe the set on the date it was written. Since 2026-09-11 chain 2800 has ten validators (f=3, commit quorum 7 of 10), all still operated by the Foundation, one of them running the second, Nethermind-derived client. The live set and its quorum are at https://aere.network/docs/network/consensus.
 
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.

results/PROVEN-RESULTS-2026-07-11.md

@@ -1,5 +1,7 @@
 # AERE Network: Proven Results (status as of 2026-07-11)
 
+> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12 and 2026-10-25). (Note applied to this document on 2026-10-28.)
+
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.
 
 > **UPDATE (2026-07-16): two facts in this 2026-07-11 snapshot have since changed on