Dated corrections (2026-10-28) from the tenth review round: 21 documents; 19 carry the consensus note on AIP-22 stage 4 (since block 24,300,000), with the date it was applied to each, and the cross-client determinism report and the engineering security specification carry dated corrections; each change states its date in the text

AERE-BENCHMARK-REPORT.md

@@ -1,5 +1,7 @@
 # Aere Network: Reproducible Benchmark Report (spec-18)
 
+> **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 date:** 2026-07-19
 **Chain:** Aere Network mainnet, chain ID 2800 (Hyperledger Besu QBFT).
 **Scope:** chain performance, zkVM proof-verification economics, and post-quantum

AERE-COMPUTE-MARKET-V3-SUMMARY.md

@@ -1,5 +1,7 @@
 # Spec 10: Aere Compute Market V3 (proof-carrying DePIN)
 
+> **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.
 
 Revised 2026-07-20. The prior revision of this file described V3 before the liveness review; the

AERE-CROSS-CLIENT-DETERMINISM.md

@@ -1,5 +1,7 @@
 # Aere Network Cross-Client Determinism
 
+> **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.
 
 Technical specification. Chain 2800 (Aere Network mainnet).
@@ -66,9 +68,10 @@ This document does **not** claim any of the following, and the reader should not
   at that time Nethermind ran as a non-validating follower and cross-check, took zero part in
   live consensus, and Besu was the sole live producer. Since 2026-09-11 Nethermind is the tenth
   validator of chain 2800 and produces blocks (correction 2026-09-27).
-- It does **not** claim client-diverse consensus or a "two-client mainnet". Making
+- It does **not** claim client-diverse consensus in the fault-tolerance sense. Since 2026-09-11
-  Nethermind a live sealer is a separate, founder-gated, high-risk change documented in
+  Nethermind seals blocks as the tenth validator, but nine of the ten run Besu, so a Besu fault
-  `DECENTRALIZATION-2ND-CLIENT-RUNBOOK.md` Phase B, not started and not authorized here.
+  can still stop the chain (corrected 2026-10-28: this said that making Nethermind a live sealer
+  was a separate change, not started).
 - It does **not** claim post-quantum consensus. Consensus is classical secp256k1 ECDSA
   QBFT. The post-quantum surface is signatures, accounts, and applications only. This scope
   boundary holds throughout every section below.
@@ -345,17 +348,20 @@ recover, not to fork.
 **The remaining operational work** is turning the proven cross-check into an automated live
 fail-safe gate: a supervised process that continuously reads both clients at head, diffs block
 hash and state root per block, and alerts (and gates trust) on the first divergence, with the
-permanent follower held at head under a sustained soak. Separately and further out, making
+permanent follower held at head under a sustained soak. When this document was written, making
-Nethermind a live sealing validator is the founder-gated, high-risk Phase B in
+Nethermind a live sealing validator was a separate step further out (an extended mixed-client
-`DECENTRALIZATION-2ND-CLIENT-RUNBOOK.md` (extended mixed-client soak at production shape,
+soak at production shape, an independent audit of the Nethermind QBFT engine, a rehearsed
-independent audit of the Nethermind QBFT engine, a rehearsed one-block rollback vote, and
+one-block rollback vote, and fault tolerance preserved by construction). Since 2026-09-11
-fault tolerance preserved by construction), not started and not authorized by this document.
+Nethermind seals blocks as the tenth validator; no third party has audited its QBFT engine yet
+(corrected 2026-10-28: this paragraph said that step was not started and not authorized).
 
-Public-copy rule that travels with this status: a second independent client follows and
+Public-copy rule that travelled with this status until 2026-09-11: a second independent client
-validates live chain 2800 as a non-validating full node. Do not write "client-diverse
+followed and validated live chain 2800 as a non-validating full node, and no text was to imply
-consensus", "two-client mainnet", or anything implying the second client seals live blocks.
+that it sealed live blocks. Since that date it is the tenth validator and seals blocks; nine of
-The Nakamoto coefficient by operator is still about 1; a follower does not change it. Never
+the ten validators still run Besu, so "client-diverse consensus" is still not claimed in the
-claim mainnet consensus is post-quantum; it is classical secp256k1 ECDSA.
+fault-tolerance sense. The Nakamoto coefficient by operator is still about 1: all ten validators
+are run by one operator. On post-quantum consensus, see the note of 2026-09-24 at the head of
+this document (rule corrected 2026-10-28).
 
 ---
 

AERE-EIP-COMPATIBILITY-MATRIX.md

@@ -1,5 +1,7 @@
 # Aere Network: Ethereum EIP Compatibility Matrix
 
+> **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 (N=7 with f=2 and a commit quorum of 5 of 7, or N=9 with a quorum of 6) describe the set on the date they were 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. Since 2026-09-04 the anchor certificate is scheme-tagged and carries Falcon-512 seals, with SLH-DSA-SHA2-128s seals as well at every anchor until block 20,746,736 and at every 128th block since; from block 17,225,968 (2026-09-05) to block 20,746,736 there was one anchor every 128 blocks with at least six valid seals for each scheme, and since then (AIP-22 stages 1 and 2, updated 2026-09-30) a Falcon-512 certificate is required every 32 blocks and SLH-DSA seals every 128, with at least seven valid seals for each scheme, as many as the quorum of the ten validators (below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision; this clause corrected on 2026-10-25), from block 20,715,632; since block 20,836,228 the validators are named in consensus by post-quantum ids. The live set and its quorum are at https://aere.network/docs/network/consensus.
 
 **Chain:** Aere Network mainnet, chain ID 2800 (`0xaf0`). Execution client: Hyperledger Besu 26.4.0 with QBFT consensus (classical secp256k1 ECDSA, N=7 validators, f=2), approximately 0.5 second blocks. This document is a developer reference: it states, EIP by EIP, where Aere's EVM matches Ethereum mainnet and where it deliberately differs.

AERE-ENGINEERING-SECURITY-SPEC.md

@@ -168,7 +168,7 @@ This section records, for each load-bearing architecture decision, what was chos
 
 ### 4.2 Execution client: forked Besu, not Reth, with Nethermind as the second client
 
-**Chosen.** A fork of Hyperledger Besu v26.4.0 (Java, base commit d2032017, built on a JDK 21 toolchain) as the sole live mainnet producer. The fork adds native post-quantum precompiles and an extended EIP-2935 block-hash lookback (live on mainnet since block 9,189,161) and carries the base-fee-floor change (live since block 10,141,734). A patched Nethermind 1.39.0 (.NET) is the second, independent client.
+**Chosen.** A fork of Hyperledger Besu v26.4.0 (Java, base commit d2032017, built on a JDK 21 toolchain) as the live mainnet producer at nine of the ten validators (the sole one until 2026-09-11; corrected 2026-10-28: this said the sole live mainnet producer). The fork adds native post-quantum precompiles and an extended EIP-2935 block-hash lookback (live on mainnet since block 9,189,161) and carries the base-fee-floor change (live since block 10,141,734). A patched Nethermind 1.39.0 (.NET) is the second, independent client.
 
 **Alternatives considered.** Reth (Rust, high-performance) as the base client; or running a single client indefinitely.
 

AERE-ERC7683-DESTINATION.md

@@ -1,5 +1,7 @@
 # Aere Network ERC-7683 Destination Settler
 
+> **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 (N=7 with f=2 and a commit quorum of 5 of 7, or N=9 with a quorum of 6) describe the set on the date they were 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. Since 2026-09-04 the anchor certificate is scheme-tagged and carries Falcon-512 seals, with SLH-DSA-SHA2-128s seals as well at every anchor until block 20,746,736 and at every 128th block since; from block 17,225,968 (2026-09-05) to block 20,746,736 there was one anchor every 128 blocks with at least six valid seals for each scheme, and since then (AIP-22 stages 1 and 2, updated 2026-09-30) a Falcon-512 certificate is required every 32 blocks and SLH-DSA seals every 128, with at least seven valid seals for each scheme, as many as the quorum of the ten validators (below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision; this clause corrected on 2026-10-25), from block 20,715,632; since block 20,836,228 the validators are named in consensus by post-quantum ids. The live set and its quorum are at https://aere.network/docs/network/consensus.
 
 The receiving side of cross-chain intents on Aere Network. This document explains how

AERE-MIGRATION-TOOLKIT.md

@@ -1,5 +1,7 @@
 # spec-31: Aere Quantum Migration Toolkit
 
+> **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 date: 2026-07-19
 Location: `aerenew/pqc-migration-toolkit/`
 Runtime: pure Node built-ins (Node 18+), zero runtime dependencies.

AERE-NEW-CONTRACTS-DEPLOY-RUNBOOK.md

@@ -1,5 +1,7 @@
 # Aere Network: new-contracts deployment-readiness runbook
 
+> **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.)
+
 Scope: the ~17 new Solidity contracts added under `aerenew/contracts/contracts/` during this build loop.
 Source review: `aerenew/docs/AERE-SECURITY-REVIEW-NEW-CONTRACTS.md` (no CRITICAL, no HIGH).
 Applied fixes: `aerenew/docs/AERE-SECURITY-FIXES.md` (M1 fixed, L1 x3 fixed, L2 fixed, L3 documented).

AERE-PQ-AGGREGATE-SUMMARY.md

@@ -1,5 +1,7 @@
 # Spec 6: AerePQAggregate build summary
 
+> **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.
 
 ## What was built

AERE-PQ-AGGREGATE.md

@@ -1,5 +1,7 @@
 # AerePQAggregate: constant-cost t-of-n post-quantum committee authorization
 
+> **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: on-chain verifier and ERC-7579 module BUILT and TESTED against a mock SP1 gateway.
 Off-chain SP1 aggregation circuit NOT implemented, [MEASURE], research frontier.
 

AERE-PQ-FINALITY-CERTIFICATE-SUMMARY.md

@@ -1,5 +1,7 @@
 # Spec 4: Aere Network Post-Quantum Finality Certificate
 
+> **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.)
+
 Built the flagship ADDITIVE post-quantum finality feature: one succinct proof that a quorum of
 Aere validators attested to a finalized block with HASH-BASED (post-quantum) keys, verifiable
 on-chain in ONE call, WITHOUT changing QBFT consensus and WITHOUT a re-genesis.

AERE-PROTOCOL-SPECIFICATION.md

@@ -47,7 +47,7 @@ Aere Network  =  Ethereum execution (Pectra + Fusaka ruleset)
 The Aere delta is small and enumerable. It consists of exactly the following:
 
 1. **Chain and consensus parameters** distinct from Ethereum mainnet: chain ID, block period (with one mid-chain transition), the QBFT validator-set size and quorum, and the genesis allocation. (Section 2, Section 3.)
-2. **The AerePQC hard fork**: five native post-quantum verification precompiles at `0x0AE1..0x0AE5`, the native EIP-2935 write path, and the EIP-7939 CLZ opcode, all activated together at one block height. (Section 4.)
+2. **The AerePQC hard fork**: five native post-quantum precompiles at `0x0AE1..0x0AE5`, four signature verifiers and the SHAKE256 hash (corrected 2026-10-28: this called all five verification precompiles), the native EIP-2935 write path, and the EIP-7939 CLZ opcode, all activated together at one block height. (Section 4.)
 3. **Two further precompiles built but not activated on mainnet** (`0x0AE6` ML-KEM-768, `0x0AE7` Falcon HashToPoint) and one reference skeleton (`0x0AE8` hash-based STARK verify; the BabyBear/FRI skeleton targets Aere's own Plonky3 circuits, NOT SP1 6.1.0, which is Hypercube, see 4.8.3). Specified for completeness and clearly marked non-live. (Section 4.6.)
 4. **Fee and burn mechanics**: a 1-Gwei EIP-1559 base-fee floor applied at the execution layer, and a validator-reward-cut burn applied *above* consensus by an application contract. (Section 5.)
 5. **A set of deliberate EIP deviations** from Ethereum parity that follow from Aere being a QBFT chain with no beacon layer and no blob data-availability market. (Section 6.)
@@ -290,7 +290,7 @@ A consensus-relevant subtlety a reimplementer must know: the QBFT header ruleset
 
 The AerePQC hard fork is the single largest element of the Aere delta. It activated on mainnet chain 2800 at **block 9,189,161** (2026-07-12), configured as a Besu `futureEips` milestone with activation timestamp `futureEipsTime = 1783820272`. It is a coordinated, client-only, flag-day activation with **no re-genesis and no state migration**. It added three things, all at the execution layer:
 
-1. Five native post-quantum verification precompiles at the address band `0x0AE1..0x0AE5`.
+1. Five native post-quantum precompiles at the address band `0x0AE1..0x0AE5`: four signature verifiers (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s) and the SHAKE256 hash (corrected 2026-10-28: this called all five verification precompiles).
 2. The native EIP-2935 historical-block-hash write path.
 3. The EIP-7939 CLZ opcode.
 

AERE-QUANTUM-MIGRATION-SUMMARY.md

@@ -1,5 +1,7 @@
 # Spec #14: Account migration + network key rotation (quantum layer 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.)
+
 Built the LAST account-layer quantum-resistance piece: a real, no-custody,
 tested contract for moving assets off a classical ECDSA EOA onto a post-quantum
 account, plus a design doc covering both that and network key rotation (gated).

AERE-QUANTUM-MIGRATION.md

@@ -1,5 +1,7 @@
 # Aere Quantum Migration: Accounts and Network Keys
 
+> **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: user account migration is REAL and TESTED (contract + Hardhat suite,
 below). Network key rotation is DESIGN ONLY and founder + audit gated. This
 document is the last quantum-resistance layer at the key-management level (quantum

AERE-SHADOW-PRODUCER-SUMMARY.md

@@ -1,5 +1,7 @@
 # Spec 13: Self-verifying parallel Shadow Block Producer
 
+> **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-19. Chain 2800 (Aere Network mainnet), head ~10,364,611 at build time.

AERE-SHADOW-PRODUCER.md

@@ -1,5 +1,7 @@
 # Aere Shadow Block Producer
 
+> **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.
 
 Technical specification. Chain 2800 (Aere Network mainnet).

AERE-STARK-MMCS-SUMMARY.md

@@ -1,5 +1,7 @@
 # STARK-verify port 0x0AE8, component (c): MMCS (FieldMerkleTreeMmcs) - IMPLEMENTED + CONFORMANCE-CONFIRMED
 
+> **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.)
+
 > **Scope caveat (2026-07-19 finding).** This component is conformance-confirmed against Plonky3
 > `0.4.3-succinct` (Aere's OWN BabyBear + FRI STARK stack), NOT against SP1 6.1.0. SP1 6.1.0 is a
 > **Hypercube** release (KoalaBear multilinear: BaseFold + Jagged + sumcheck-zerocheck + LogUp-GKR),

AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC.md

@@ -1,5 +1,7 @@
 # AERE STARK verifier: SP1-recursion AIR port specification (precompile 0x0AE8, part 2)
 
+> **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.)
+
 Spec date: 2026-07-19
 Status: RESEARCH + PORTING PLAN, not an implementation. This document scopes the ONE remaining
 crypto-core piece of the native STARK-verify port (the SP1-recursion-specific constraint system and

AERE-STARK-VERIFIER-PORT-SPEC.md

@@ -1,5 +1,7 @@
 # AERE STARK verifier port specification (0x0AE8): component order, interfaces, vectors, effort
 
+> **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 (N=7 with f=2 and a commit quorum of 5 of 7, or N=9 with a quorum of 6) describe the set on the date they were 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. Since 2026-09-04 the anchor certificate is scheme-tagged and carries Falcon-512 seals, with SLH-DSA-SHA2-128s seals as well at every anchor until block 20,746,736 and at every 128th block since; from block 17,225,968 (2026-09-05) to block 20,746,736 there was one anchor every 128 blocks with at least six valid seals for each scheme, and since then (AIP-22 stages 1 and 2, updated 2026-09-30) a Falcon-512 certificate is required every 32 blocks and SLH-DSA seals every 128, with at least seven valid seals for each scheme, as many as the quorum of the ten validators (below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision; this clause corrected on 2026-10-25), from block 20,715,632; since block 20,836,228 the validators are named in consensus by post-quantum ids. The live set and its quorum are at https://aere.network/docs/network/consensus.
 
 > **SCOPE CAVEAT (research finding, 2026-07-19; read before anything else).** The six generic

AERE-XMSS-CIRCUIT-CORE-SUMMARY.md

@@ -1,5 +1,7 @@
 # Post-Quantum Finality Certificate (#4): XMSS aggregation circuit, verification core
 
+> **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.)
+
 Date: 2026-07-19
 
 ## What was asked

DOVADA-PQC-VERIFICABILA-2026-07-20.md

@@ -1,5 +1,7 @@
 # Dovada PQC verificabila. Tested commands and real output
 
+> **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.)
+
 > **Nota adaugata 2026-08-19.** Afirmatiile de aici ca pe lantul 2800 consensul e (sau ramane) clasic ECDSA secp256k1 QBFT au fost scrise inainte de ancora post-cuantica din antet si raman adevarate pentru finalitatea bloc cu bloc. De la blocul 13.014.000 fiecare al 32-lea bloc poarta, sub amprenta lui, un certificat de sigilii Falcon-512 ale validatorilor, iar de la 13.034.000 un nod respinge un astfel de bloc de ancora cu mai putin de 3 sigilii valide (f+1 din 9; 8-9 purtate in practica). E un punct de control post-cuantic la ~16 secunde, nu un cvorum pe fiecare bloc: afirmatia publicata pe 15 august ca de la 14.050.000 niciun bloc nu se finalizeaza fara cvorum post-cuantic era gresita (regula armata atunci e retrasa in codul livrat in favoarea regulilor ancorei) si a fost retrasa pe 19 august. Detalii: https://aere.network/quantum.html si depozitul aere-node, anchor/README.md.
 
 **Date:** 2026-07-20