AIP-20, AIP-22, index and execution-kernel contract: AIP-22 stage 4 in force on chain 2800 since block 24,300,000 (2026-10-25), dated notes

aips/AIP-20.md

@@ -40,7 +40,7 @@ consensus already requires a post-quantum seal beside the classical signature on
 every validator (at the tenth since block 18,131,633), and on every QBFT message at the nine
 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
+since block 24,300,000 (AIP-22 stage 4, 2026-10-25). 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.)

aips/AIP-22.md

@@ -27,6 +27,8 @@
 > chain 2800. See the Errata entry of that date; the Preamble (Requires), the Motivation and Security Considerations carry
 > dated notes.
 
+> **Note added 2026-10-25.** Stage 4 is active on chain 2800 since block 24,300,000: from it every validator, on both clients, takes the author of a consensus message from its verified post-quantum seal, and the second client's proposal, prepare and round-change layers, named in the notes above as taking effect at stage 4, are in force. Rule 4 of section 4 (the provisional tail and its rollback) is not part of the stage-4 binaries on chain 2800: neither client implements it at this date, a block is final on import as before, and its post-quantum proof is the anchor that covers it; the bound of rule 1 holds because every anchor height must carry a valid certificate. Headers keep their ECDSA commit seals until stage 5.
+
 ## Preamble
 
 | Field | Value |
@@ -38,7 +40,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 (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) |
+| 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, active on chain 2800 since block 24,300,000 (2026-10-25); 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) |
@@ -49,7 +51,7 @@ 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 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 32nd block carries a Falcon-512 certificate over its parent under the block hash and every 128th block a hybrid Falcon-512 + SLH-DSA-SHA2-128s one, with at least seven valid seals per scheme of the ten validators (stages 1 and 2 below, active from blocks 20,715,632 and 20,746,736; before them every 128th block, with at least six); 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.) (Corrected 2026-10-12: the 2026-10-09 version of this paragraph gave, as today's, the certificate grid and threshold of before stages 1 and 2.)
+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 have been in effect since stage 4 below (`H_fin`, block 24,300,000 on chain 2800, 2026-10-25); every 32nd block carries a Falcon-512 certificate over its parent under the block hash and every 128th block a hybrid Falcon-512 + SLH-DSA-SHA2-128s one, with at least seven valid seals per scheme of the ten validators (stages 1 and 2 below, active from blocks 20,715,632 and 20,746,736; before them every 128th block, with at least six); 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.) (Corrected 2026-10-12: the 2026-10-09 version of this paragraph gave, as today's, the certificate grid and threshold of before stages 1 and 2.)
 
 What remains classical is exactly what a node that is NOT online, one that syncs the history, is asked to believe:
 

aips/README.md

@@ -46,7 +46,7 @@ document is current.
 | [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | |
 | [20](./AIP-20.md) | Native Post-Quantum Transactions (Type 0x50, ML-DSA Authorization) | Standards Track / Core | **Draft, not ratified; implemented in both clients and proven conformant on shared vectors (2026-09-17); live on testnet 28001 from block 2,212,000 (first type-0x50 transaction at 2,212,032, both clients); on chain 2800 the implementation runs on every node since 2026-09-22 and is armed, uniformly, for block 19,900,000 (per-node property, not a genesis change); no type-0x50 transaction on chain 2800 before that height** | |
 | [21](./AIP-21.md) | Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) | Standards Track / Interface (non-consensus) | **Draft, not ratified; first half (retention window + `aere_getPqFinality`) implemented in the Besu-derived client with 7 tests and deployed on testnet 28001 (5 nodes, public door `testnet-rpc.aere.network/finality`) on 2026-09-18; Nethermind port the same day (10 tests) and deployed on the testnet Nethermind validator with its own public door; two-client conformance proven live (`aip21-conformitate/DOVEDESTE.sh`, CONFORM on block 2,250,809); second half (the window on disk, same journal format in both clients) deployed on all six testnet nodes the same day: the window survives a restart in both (1,284 and 1,255 seals re-verified, 0 failed), and a round-1 block is `post-quantum` in both on the same hash (CONFORM 08:49Z, block 2,285,481 and round-1 block 2,285,333); on chain 2800 since 2026-09-22 on all ten validators and both clients (`aere_getPqFinality` answers `post-quantum` with 10 of 10 seals re-verified; dated record at the end of AIP-21)** | |
-| [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (2026-09-23 to 2026-09-25, stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stages 4 and 5 not armed (their activation heights are the founder's)** | |
+| [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (2026-09-23 to 2026-09-25, stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stage 4 active since block 24,300,000 (2026-10-25), stage 5 not armed (its activation height is the founder's)** | |
 | [23](./AIP-23.md) | AERE Proof Protocol (Portable Verifiable-Statement Envelope with Optional Post-Quantum On-Chain Finality) | Standards Track / Interface | **Draft, not ratified (2026-09-26); reference verifier and conformance vectors published 2026-09-27; finality proven end to end on testnet 28001** | |
 
 Numbers are permanent and are never reused, including for withdrawn proposals
@@ -71,23 +71,16 @@ at least seven valid seals per scheme of the ten validators, as many as the quor
 (AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement: every validator
 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
+client enforces commits since 18,131,633 and the other three message types since block 24,300,000 (AIP-22 stage 4, 2026-10-25). (Corrected 2026-10-09: until that date this line named the enforcement on every QBFT
-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 from stage 4 (its stages 1 to 3 are
+AIP-19 (a process change under review), AIP-22 from stage 5 (its stages 1 to 4 are live, above, stage 4 since block 24,300,000, 2026-10-25; stage 5 runs on the public testnet 28001, and its height is not yet set on chain 2800).
-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
+QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block header (its commit seals), with the post-quantum layers above added to it (hybrid, never "post-quantum only"), and since block 24,300,000 (stage 4) a consensus message counts only through its verified post-quantum seal; AIP-22 is the design for removing that dependence: its stages 1 to 4 are live (above), and its later stages, from stage 5, are not set on chain 2800. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22
-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: its stages
-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.

execution-kernel/MACHINE-INTERFACE-CONTRACT.md

@@ -316,8 +316,7 @@ The harness prints a NOT MEASURED block naming these on every run, and its JSON
 them in the `honesty` field, so the non-claims travel with every result rather than living only
 in this document:
 
-- **That consensus is post-quantum.** It is not. Consensus finality is classical secp256k1 ECDSA
+- **That consensus is post-quantum.** It is not. Consensus finality is QBFT whose votes every validator attributes only through their verified post-quantum seals since block 24,300,000 (AIP-22 stage 4), with classical secp256k1 ECDSA commit seals in the header until AIP-22 stage 5 and a Falcon certificate at every anchor. MI is an execution seam and says nothing about consensus.
-  QBFT plus a Falcon certificate. MI is an execution seam and says nothing about consensus.
 - **That equal header roots prove independent execution by themselves.** See the honesty boundary
   in section 5. The load-bearing fact is Nethermind's reject-on-disagreement behaviour, not the
   served bytes.