AIP-20, AIP-22, README: message-layer enforcement stated per client (corrected 2026-10-09): every validator refuses a commit without a post-quantum seal, the nine primary-client validators any consensus message since block 17,700,000; the second client enforces commits since 18,131,633 and the other three types from AIP-22 stage 4, whose height is not yet set on chain 2800; dated notes and an Errata entry, nothing removed

aips/AIP-20.md

@@ -36,9 +36,14 @@ chain 2800 only through a founder-signed acceptance of this AIP (AIP-19 process)
 
 Every externally owned account on chain 2800 is authorized today by a secp256k1 ECDSA signature,
 whose security rests on the discrete logarithm problem, broken by Shor's algorithm. The chain's
-consensus already requires post-quantum seals on every QBFT message (SPEC section 2.6, in force
+consensus already requires a post-quantum seal beside the classical signature on every commit at
-since block 17,700,000) and binds every 128th block under a hybrid Falcon-512 + SLH-DSA-SHA2-128s
+every validator (at the tenth since block 18,131,633), and on every QBFT message at the nine
-certificate; the accounts of users are the remaining classical layer.
+validators that run the primary, Besu-derived client (SPEC section 2.6, since block 17,700,000); the
+second, Nethermind-derived client applies the rule to proposal, prepare and round-change messages
+from AIP-22 stage 4, whose height is not yet set on chain 2800. Consensus also binds every 128th
+block under a hybrid Falcon-512 + SLH-DSA-SHA2-128s certificate; the accounts of users are the
+remaining classical layer. (Corrected 2026-10-09: until that date this paragraph said that consensus
+requires "post-quantum seals on every QBFT message", without naming the second client.)
 
 Post-quantum contract accounts exist on 2800 (`AerePQCTxAccount`, `HybridAuthorizer`, the ERC-4337
 threshold account), but they are second-class: the transaction that carries the post-quantum
@@ -357,6 +362,11 @@ type-0x50 transaction proposed by the Nethermind-derived validator on chain 2800
   false for chain 2800 and is replaced by the corrected text under "Quantum threat model". Added under "Key reuse and the
   empty context": a key that authorizes a type-`0x50` account must not be used by a signer that signs caller-supplied
   32-byte values with the empty context. The transaction format, the signing hash and every vector are unchanged.
+- **2026-10-09, Motivation.** The sentence said that consensus requires post-quantum seals "on every QBFT message" since
+  block 17,700,000. Every validator requires the seal on commits, and the nine validators that run the primary client require
+  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.
 
 ## Post-Acceptance Outcome Record
 

aips/AIP-22.md

@@ -11,6 +11,13 @@
 > `M(parent(A))` does not prove that `parent(A)` was decided, for any number of seals. See the Errata entry of that date;
 > it withdraws the finality definition of section 1 as written and three statements that rest on it. Chain 2800 today,
 > below stage 5, is not affected: its headers still carry the ECDSA commit quorum of a single round.
+>
+> **Correction added 2026-10-09.** On chain 2800 every validator refuses a commit without a valid post-quantum seal of its
+> author, and nine of the ten refuse any consensus message without one. Where this document said that all four message types
+> are refused without a seal "on both clients", it overstated: the second, Nethermind-derived client, which runs the tenth
+> validator, applies the rule to proposal, prepare and round-change messages from stage 4 below, whose height is not yet set on
+> chain 2800. See the Errata entry of that date; the Preamble (Requires), the Motivation and Security Considerations carry
+> dated notes.
 
 ## Preamble
 
@@ -23,7 +30,7 @@
 | Category | Core |
 | Status | Draft (design only; nothing described here is implemented or deployed at the Created date) |
 | Created | 2026-09-23 |
-| Requires | AIP-15 (anchor certificate under the block hash), AIP-21 (per-block seal record), the per-message post-quantum enforcement of SPEC section 2.6 (in force on chain 2800 since block 17,700,000), AIP-19 (the acceptance process) |
+| Requires | AIP-15 (anchor certificate under the block hash), AIP-21 (per-block seal record), the per-message post-quantum enforcement of SPEC section 2.6 (on chain 2800: commits at every validator; all four message types at the nine validators that run the primary, Besu-derived client, since block 17,700,000; at the second, Nethermind-derived client, commits since block 18,131,633 and the other three types from stage 4 of this AIP, whose height is not yet set on chain 2800; corrected 2026-10-09, see Errata), AIP-19 (the acceptance process) |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Not ratified; testnet-gated (chain 28001 first, both clients), second-client-gated (both clients accept and refuse the same headers), founder-gated per activation height (AIP-19), external-audit gated before the canonical rule (section 4 of the Specification) is armed on chain 2800 (the gate AIP-15 already names) |
@@ -34,14 +41,14 @@ This AIP makes the finality of every block of an Aere QBFT chain a post-quantum
 
 ## Motivation
 
-Chain 2800 today has the following measured shape (sources in the Specification): every QBFT message on the hot path (proposal, prepare, commit, round-change) is refused unless it carries a valid Falcon-512 seal bound to its author, since block 17,700,000 on both clients; every 128th block carries a hybrid Falcon-512 + SLH-DSA-SHA2-128s certificate over its parent under the block hash, with at least six valid seals per scheme of the ten validators; and `aere_getPqFinality` returns, on every validator, the Falcon seals it heard for a recent block, re-verified (ten of ten on 2026-09-22). A validator that is online therefore finalizes nothing without post-quantum seals.
+Chain 2800 today has the following measured shape (sources in the Specification): every validator refuses a commit unless it carries a valid Falcon-512 seal bound to its author, and the nine validators that run the primary client refuse every QBFT message on the hot path (proposal, prepare, commit, round-change) without one, since block 17,700,000; the second client, which runs the tenth validator, refuses any commit without one since block 18,131,633, while its proposal, prepare and round-change layers take effect at stage 4 below (`H_fin`, whose height is not yet set on chain 2800); every 128th block carries a hybrid Falcon-512 + SLH-DSA-SHA2-128s certificate over its parent under the block hash, with at least six valid seals per scheme of the ten validators; and `aere_getPqFinality` returns, on every validator, the Falcon seals it heard for a recent block, re-verified (ten of ten on 2026-09-22). A validator that is online therefore finalizes nothing without post-quantum seals. (Corrected 2026-10-09: until that date this paragraph said that the four message types are refused without a seal "since block 17,700,000 on both clients"; on chain 2800 the second client enforces its commit layer only, and its other three layers take effect at stage 4. See the Errata entry of that date.)
 
 What remains classical is exactly what a node that is NOT online, one that syncs the history, is asked to believe:
 
 1. Between two anchors, the header of a block carries only ECDSA commit seals. A syncing node checks those and nothing post-quantum for up to 127 blocks (about 72 seconds at the measured block period). Its post-quantum assurance for those blocks arrives only with the next anchor, and the anchor's certificate is bound to the parent hash, so the assurance is real but delayed, and it is not stated as a rule anywhere.
 2. The certificate threshold is six of ten (schedule step `14961456:6`), which is f + 3 at N = 10 and below the QBFT quorum of seven (recorded in the repository's findings register on 2026-09-11). A hostile reader is right to say: the certificate proves that six validators signed, it does not prove that consensus was reached.
 3. Validator identity is an ECDSA address: the validator list in `extraData`, the proposer rotation, the `coinbase`, the vote recipient, the registry's `claim`, and the peer-forwarding predicate of the Besu-derived client (it forwards Istanbul messages only to peers whose node-key address is in the set, measured 2026-09-02) all name secp256k1 keys. The Falcon registry binds an index to that address; the address itself is classical.
-4. The ECDSA signature of every consensus message and the ECDSA commit seals in every header are still validity criteria. The live security is therefore "ECDSA AND Falcon" for an online node, which is stronger than either alone, and "ECDSA, then Falcon at the next anchor" for a syncing one.
+4. The ECDSA signature of every consensus message and the ECDSA commit seals in every header are still validity criteria. The live security is therefore "ECDSA AND Falcon" for an online node, which is stronger than either alone, and "ECDSA, then Falcon at the next anchor" for a syncing one. (Corrected 2026-10-09: on the second client "ECDSA AND Falcon" holds for commits; it counts proposal, prepare and round-change messages by their ECDSA author until stage 4, whose height is not yet set on chain 2800. See Errata.)
 
 The Foundation's stated goal, restated on 2026-09-22, is a consensus whose safety and finality do not depend on ECDSA at all. This AIP is the path from the measured state above to that goal, with the cost of each step in bytes, disk, bandwidth and latency, and with the founder decisions it needs named.
 
@@ -224,6 +231,7 @@ Every activation height here is a coordinated fork: the same binary and the same
 - **Threat model.** An adversary who holds every classical validator key and no post-quantum key (the posterior-corruption, long-range rewrite; peer-reviewed treatment of the threat: Azouvi, Danezis, Nikolaenko, "Winkle", IACR 2019/1440, AFT 2020; the quantum framing and this defence are Aere's own). "Harvest now, decrypt later" does not apply to signatures and is not what this AIP defends against.
 - **What this AIP achieves against that adversary, per height.** Today: cannot finalize a block online (message seals); can serve a syncing node a tail of up to 127 blocks that the next anchor invalidates. After `H_K` and `H_I`: the same, with the tail bounded at 31 blocks and every covering certificate a quorum. After `H_id`: cannot name a validator, vote, or propose in any set, even for a syncing node. After `H_fin`: cannot cause any node to consider any block final. After `H_hdr`: cannot produce a header that any node admits at all.
 - **Note added 2026-10-07 (how the tail is counted).** The bullet above counts the blocks above an anchor: "up to 127 blocks" for the 128-block interval in force when it was written, "31 blocks" for the 32-block interval; Motivation (1) ("up to 127 blocks") and the negative control of section 4 rule 4 ("a classical-only fork of up to 31 blocks") count the same way. `SPEC.md` 3.1 and the threat-model page ("at most 32 blocks") count the anchor block too: 32 and 128 for the same sets of blocks; the derivation below counts the anchor block because it is replaceable (its certificate is about its parent). With the exception of the Errata entry of 2026-10-01 (honest validators sealed an undecided sibling of the latest anchor's parent, at least as many of them as the node's effective threshold `K_eff`, since this adversary holds no post-quantum key), one block more can be replaced: 33 since block 20,746,736 and 129 in the dated 128-interval window (blocks 17,225,968 to 20,746,736, 2026-09-05 to 2026-09-29); the latest anchor's grandparent and everything below it are kept in every case. The derivation and its machine-checked model are `aere-research/research/rewrite-bound-round-free-seal-2026-10-07.md` and `aere-research/formal-consensus/anchor_rewrite_bound_roundfree_smt.py` (13 proofs with 8 negative controls; `--plant-bounds`, which lowers every claimed bound by one, fails exactly the ten bound proofs). The bound is stated for a node that holds the honest chain to its head, or a reference anchor (a recent anchor's height and hash): in both cases only the tail above the latest anchor's parent (grandparent, with the exception) is rewritable, and with a reference everything through it is kept whatever the length of the alternative; without one, a node syncing from genesis can be served a history that stops before an anchor, at any height, and cannot tell that the honest chain is longer (rule 5 of section 4 and the "Weak subjectivity" bullet below, read with this limit).
+- **Correction added 2026-10-09 (to "After `H_id`" in the bullet "What this AIP achieves against that adversary, per height").** On chain 2800, where `H_id` is active from block 20,836,228, "cannot ... vote, or propose in any set" holds at the nine validators that run the primary client, which refuse all four message types without a valid seal. At the second client it holds only for commits until stage 4 (`H_fin`, whose height is not yet set on chain 2800): until then this adversary can present proposal, prepare and round-change messages in another validator's name to the second client. Alone, that misleads one validator of ten, below `f` = 3, whose own commits stay sealed with its own key; combined with `f` Byzantine validators, the misled second client would count as one more faulty node, and that case is not analyzed. "Today: cannot finalize a block online" stands: every validator refuses a commit without a valid seal. See the Errata entry of that date.
 - **What it does not achieve.** Node-to-node transport (RLPx) is authenticated by secp256k1; an adversary with node keys can impersonate a peer, not a validator. A post-quantum handshake (ML-KEM) is a separate AIP. Nothing here is audited by a third party; AIP-15's external-audit gate applies before `H_fin` on chain 2800. The set is ten validators operated by one party; this AIP changes what a key can do, not who holds the keys.
 - **Hybrid conjunction.** A certificate is valid only with the quorum of every required scheme; forging it needs both a lattice break (Falcon-512) and a hash-function break (SLH-DSA-SHA2-128s) at dual-assumption anchors, and a lattice break alone at the intermediate Falcon anchors. The single-assumption window is at most 32 blocks by design, and the founder can shorten it at the cost in the table.
 - **Liveness tax at K = Q.** With f validators down, an anchor needs every remaining seal to reach its proposer in time; a proposer without them skips by round change. The measured pre-AIP rate is 12 of 12 anchors at round 0; the post-AIP rate is a testnet gate. The threshold guard's warning text is the operator's acknowledgment of this trade.
@@ -344,6 +352,22 @@ Two refinements to the text above, recorded rather than silently applied: the Me
   against 32 and 128 without the exception; the latest anchor's grandparent and everything below it are kept (13 proofs, 8
   negative controls, `--plant-bounds` fails exactly the ten bound proofs). Nothing in the entry above is withdrawn by this one.
 
+- 2026-10-09, Preamble (Requires), Motivation (the measured shape and point 4) and Security Considerations ("After `H_id`"):
+  the text said that every QBFT message on the hot path (proposal, prepare, commit, round-change) is refused without a valid
+  Falcon-512 seal of its author "since block 17,700,000 on both clients". Every validator refuses a commit without one; all
+  four message types are refused by the nine validators that run the primary client (commit since block 17,250,000, proposal
+  since 17,400,000, round-change since 17,550,000, prepare since 17,700,000). The second client, whose validator joined the set
+  at block 18,083,404, has one enforcement height, for commits, in force on chain 2800 since block 18,131,633 (2026-09-11); it
+  counts a proposal, a prepare and a round-change by their ECDSA author and applies the post-quantum rule to them from stage 4
+  (`H_fin`), whose height is not yet set on chain 2800. Read in its code and configuration on 2026-10-09; this matches item (a)
+  of the stage 4 record of 2026-09-23 above, which describes the same code path on testnet 28001, and AIP-20 (Security
+  Considerations, note of 2026-10-05). Corrected in place, dated. Unchanged: an online validator of either client counts no
+  commit without a valid seal, so the Motivation's sentence "A validator that is online therefore finalizes nothing without
+  post-quantum seals" stands. The adversary of Security Considerations (one who can forge ECDSA signatures) can, until stage
+  4, present proposal, prepare and round-change messages in another validator's name to the second client. Alone, that
+  misleads one validator of ten, below `f` = 3, whose own commits stay sealed with its own key; combined with `f` Byzantine
+  validators, the misled second client would count as one more faulty node, and that case is not analyzed.
+
 ## Post-Acceptance Outcome Record
 
 Not accepted; nothing to record.

aips/README.md

@@ -68,19 +68,29 @@ package for the exact rules and heights):** the anchor certificate under the blo
 hash (every 32nd block from 13,014,000, every 128th from 17,225,968 to 20,746,736, every
 32nd again since, with SLH-DSA every 128th; hybrid Falcon-512 + SLH-DSA since 17,047,600;
 at least seven valid seals per scheme of the ten validators, as many as the quorum, since 20,715,632 (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01), six from 14,961,456), post-quantum validator ids in consensus since 20,836,228
-(AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement on every QBFT
+(AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement: every validator
-message (heights 17,250,000 to 17,700,000, September 2026). AIP-21's record is live
+refuses a commit without a seal, and the nine validators that run the primary, Besu-derived client refuse every
+QBFT message without one (heights 17,250,000 to 17,700,000, September 2026); the second, Nethermind-derived
+client enforces commits since 18,131,633 and the other three message types from AIP-22 stage 4, whose height is
+not yet set on chain 2800. (Corrected 2026-10-09: until that date this line named the enforcement on every QBFT
+message without the second client's exception.) AIP-21's record is live
 on chain 2800 since 2026-09-22; AIP-20 is deployed and armed for 19,900,000.
 
 **Not live:** AIP-8 (needs a hard fork), AIP-15 as written (its testnet R&D form;
 what is live is the dated list above), AIP-16 (a skeleton that verifies nothing),
-AIP-19 (a process change under review), AIP-22 (design only).
+AIP-19 (a process change under review), AIP-22 from stage 4 (its stages 1 to 3 are
+live, above; stages 4 and 5 run on the public testnet 28001, and their heights are
+not yet set on chain 2800).
 
 **Not claimed:** consensus whose safety does not depend on ECDSA. Aere consensus is
 QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block
 and every message, with the post-quantum layers above added to it (hybrid, never
-"post-quantum only"); AIP-22 is the design for removing that dependence and nothing
+"post-quantum only"); AIP-22 is the design for removing that dependence: its stages
-in it is implemented. The precompiles `0x0AE6` and `0x0AE7` are testnet-only.
+1 to 3 are live (above), and its later stages, from stage 4, are not set on chain
+2800. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22
+is design only and that nothing in it is implemented; its stages 1 to 3 have been
+live on chain 2800 since 2026-09-29 and 2026-09-30.) The precompiles `0x0AE6` and
+`0x0AE7` are testnet-only.
 
 ## Governance, stated plainly