AIP-22 stage R and stage 4 in force on chain 2800 (2026-10-24, 2026-10-25): dated corrections to the README, pq-stark README and AIP index (votes attributed only through verified post-quantum seals since block 24,300,000; headers still admitted on ECDSA commit seals until stage 5), AIP-1 and CONTRIBUTING editorial rules corrected with their date, AIP-22 dated correction to rule 2 of section 4, AIP-3 interval dated

README.md

@@ -14,8 +14,7 @@ Falcon-1024 (`0x0AE2`), ML-DSA-44 (`0x0AE3`), SLH-DSA-128s (`0x0AE4`) and SHAKE2
 have been live as precompiles since block 9,189,161. You can call them yourself against
 `https://rpc.aere.network` without asking us for anything.
 
-**Consensus on chain 2800 is classical secp256k1 ECDSA QBFT on every block, with a post-quantum
-checkpoint every 32 blocks.** Since block 13,014,000 anchor blocks carry, under the block hash, a
+**Consensus on chain 2800 is QBFT, with a post-quantum checkpoint every 32 blocks; since block 24,300,000 (AIP-22 stage 4) every validator attributes each consensus vote only through the verified post-quantum seal of its author (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5).** Since block 13,014,000 anchor blocks carry, under the block hash, a
 certificate of validator post-quantum seals (Falcon-512, with SLH-DSA-SHA2-128s as well since
 2026-09-04, at every 128th block since 2026-09-29; every anchor was 128 blocks apart from block
 17,225,968 to block 20,746,736). Since block 20,715,632 (2026-09-29) a node rejects an anchor block

aips/AIP-1.md

@@ -235,9 +235,15 @@ correctly formed is not the same person deciding whether the idea wins.*
 - Every number carries its provenance: **measured**, **spec**, or **estimate**.
 - Design ceilings (a theoretical maximum throughput) are never presented as
   measured throughput.
-- Aere consensus is classical secp256k1 ECDSA QBFT. No AIP claims or implies
-  post-quantum consensus. Post-quantum applies to signatures, accounts and
-  applications only.
+- Aere consensus is QBFT on chain 2800: anchor blocks carry a post-quantum
+  certificate under their hash since block 13,014,000, and since block
+  24,300,000 (AIP-22 stage 4) a consensus vote counts only with the verified
+  post-quantum seal of its author (headers still carry ECDSA commit seals until
+  AIP-22 stage 5). No AIP claims or implies post-quantum consensus without the
+  limits it states. Post-quantum also applies to signatures, accounts and
+  applications (this rule corrected on 2026-10-26: until that date it said that
+  Aere consensus is classical secp256k1 ECDSA QBFT and that post-quantum applies
+  to signatures, accounts and applications only).
 
 ### 10. Where AIPs live
 
@@ -282,8 +288,10 @@ AIP carries the label **"Foundation-ratified (pre-decentralization)"** so that n
 reader mistakes editorial ratification for trustless governance.
 
 The intended migration, each step its own Meta AIP: (1) open the validator set
-beyond the current seven Foundation-operated validators and run a second client
-as a live producer; (2) introduce a public review period the Foundation cannot
+beyond the Foundation-operated validators and run a second client as a live
+producer (seven validators when this was written; ten since 2026-09-11, the
+tenth running the second client, which produces blocks; this clause corrected
+on 2026-10-26); (2) introduce a public review period the Foundation cannot
 unilaterally shorten; (3) move ratification to stake-weighted or
 validator-weighted approval once an independent staker and validator base exists.
 

aips/AIP-22.md

@@ -186,6 +186,8 @@ From `H_fin` (a height at or above `H_id`), on every node that validates or read
 5. **Weak subjectivity, named.** A node that syncs from genesis with no other knowledge can be served, by an eclipsing peer, a fork that ends before the first enforced anchor (block 13,034,000, where the certificate schedule first required a seal); such a fork can never carry a later certificate and so can never reach the height of the honest chain, but an eclipsed node does not know that height. A syncing node therefore SHOULD be given a recent anchor (height and hash) out of band, from the published registry epoch or from the operator, and MUST refuse to consider a chain canonical that does not reach it with valid certificates. This is the same requirement every finality-gadget chain has, and it is the honest replacement for the statement "history below H is protected by ECDSA only": with the checkpoint, a rewrite at any height, including below 13,014,000, would have to reproduce every certificate above it, and the strongest of those requires Q post-quantum keys.
 6. **Fallback and crypto-agility.** The schemes required at an anchor are named by the scheme-interval schedule, by height; the keys are bound by the registry epoch, by height; the on-chain scheme registry (`CryptoRegistry`, AIP-4 and AIP-7) names what verifiers exist. Retiring a scheme, adding one (ML-DSA-65 keys would be a founder ceremony: new keys), or changing an interval is a schedule step at a future height on every node that judges headers, the procedure the fleet has executed for the base-fee floor, the seal threshold, the hybrid, the interval and the four message layers. Because the hybrid rule is a conjunction, a scheme that is *broken* does not weaken the certificate (the adversary still needs the other); a scheme whose *implementation* stops producing seals halts anchors, and the answer is a uniform schedule step or the existing uniform emergency options, never a single node's setting.
 
+**Correction added 2026-10-26 (to rule 2 above).** On chain 2800 since block 24,300,000 both clients still apply the upstream rule to every header below `H_hdr`: it must carry at least Q ECDSA committed seals of one round of the parent's set, and a header that does not is refused (the Besu-derived client through `PqHeaderSealRule`, which below `H_hdr` is the upstream `BftCommitSealsValidationRule`; the Nethermind-derived client in `QbftHeaderValidator`). This is the admission filter that the second sentence of rule 2 allows until section 5, and its failure is a refusal, so in effect it is still a validity criterion: the first sentence of rule 2 ("is no longer applied to headers at or above `H_fin`") does not describe the stage-4 binaries. Because rule 4 is not implemented either (note of 2026-10-25 at the top of this document), a header admitted on those seals is final on import, as before; its post-quantum proof is the anchor that covers it. What `H_fin` changed is rule 3: the author of every consensus message is taken only from its verified post-quantum seal, on both clients and all four message types. Rule 2 above is kept as it was written.
+
 ### 5. ECDSA out of the header
 
 From `H_hdr` (at or above `H_fin`), `extraData` gains element 6, `proposerSeal = [index, signature]`, a Falcon-512 seal by the proposer over the message the proposal already signs, `keccak256(RLP["AERE-PQ-PROPOSAL-1", chainId, height, round, proposalDigest])`, where `proposalDigest` is the QBFT proposal digest recomputable from the stored header (the round is element 3 of the stored `extraData`; the digest is the `EXCLUDE_COMMIT_SEALS` encoding hash, SPEC 2.3). Element 6 is outside both hashes (like the commit seals and the certificate) and subject to the strict codec; when it is present, element 5 is present too, an empty list where the header carries no certificate, so position alone says which element is which (a six-element header whose element 5 is an empty list is not canonical and is refused). From `H_hdr` every header, anchors included, is admitted iff its ECDSA committed seals element is empty and the proposer seal verifies, over the round in element 3, for the `coinbase` `id` at that height or, when that round is above zero, for the `id` of the proposer of that round (the proposer rotation computed from the parent's `coinbase` and the header's validator list); the round in element 3 is at most 1024 (no honest round gets near it, the round timer doubling each round), and, the parent being known, the `coinbase` is the proposer of some round from 0 to the round in element 3, that is, the block's builder; an anchor is judged by the anchor rule as well. The second case is the block prepared in one round and re-proposed unchanged in a later one: QBFT keeps the locked block, so its `coinbase` stays its builder's, and the accepted proposal, whose seal every node writes, is the later round's proposer's. (Corrected 2026-09-25: the text until then named the `coinbase` only, both clients implemented it so, and on testnet 28001 block 3,314,873, prepared at round 0 under load, was re-proposed at rounds 1 to 4 and refused by every node each time, 128 s, until round 5 was its builder's turn again; at N = 10 that wait is ten rounds, and with the builder down after the prepare it does not end.) Cost: +663 B and -455 B (7 x 65) per block at N = 10, net +208 B, that is **+11.6 GB per node per year** (208 x 55,854,159 / 10^9). After `H_hdr` no ECDSA signature appears in any header or is examined in any consensus message; the last classical use is the RLPx transport.

aips/CONTRIBUTING.md

@@ -78,9 +78,15 @@ The rules that get proposals bounced fastest:
   fixture), **spec** (a configured or standardized value), or **estimate**.
 - **Write "to be measured"** rather than guessing. A guessed gas figure is worse
   than an absent one, because the reader cannot tell it is a guess.
-- **Do not claim post-quantum consensus.** Aere consensus is classical secp256k1
-  ECDSA QBFT. Aere's post-quantum work is at the signature, account and
-  application layers. A proposal that blurs this will be sent back.
+- **Do not claim post-quantum consensus without its limits.** On chain 2800
+  anchor blocks carry a post-quantum certificate under their hash since block
+  13,014,000, and since block 24,300,000 (AIP-22 stage 4) a consensus vote
+  counts only with the verified post-quantum seal of its author (headers still
+  carry ECDSA commit seals until AIP-22 stage 5); the transport between nodes is
+  still secp256k1. Aere's post-quantum work is also at the signature, account
+  and application layers. A proposal that blurs this will be sent back (this
+  rule corrected on 2026-10-26: until that date it said that Aere consensus is
+  classical secp256k1 ECDSA QBFT).
 
 ### Step 2: submit it
 

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), stage 4 active since block 24,300,000 (2026-10-25), stage 5 not armed (its activation height is 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 R active since block 24,148,752 (2026-10-24), 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
@@ -58,7 +58,8 @@ Numbers are permanent and are never reused, including for withdrawn proposals
 Read this before citing anything here as a network capability.
 
 **Live:** AIP-2 (burn routing; see its outcome record for the measured amount),
-AIP-3 (500 ms target, 516.4 ms measured), AIP-4, AIP-5, AIP-6, AIP-7
+AIP-3 (500 ms target, 516.4 ms measured when its outcome record was written; the live
+interval is on https://aere.network/capabilities), AIP-4, AIP-5, AIP-6, AIP-7
 (precompiles `0x0AE1`..`0x0AE5` from block 9,189,161), AIP-17 (base-fee floor from
 block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14
 describe the decisions behind the live system.
@@ -77,10 +78,10 @@ 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 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).
+AIP-19 (a process change under review), AIP-22 from stage 5 (its stages 1 to 4 and stage R are live, above, stage R since block 24,148,752, 2026-10-24, and 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; rule 4 of section 4, the provisional tail, is implemented in neither client).
 
 **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 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
+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 and stage R are live (above); rule 4 of section 4 and stages 5 and 6 are not. (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.

pq-stark/README.md

@@ -91,7 +91,7 @@ from an SP1 6.1.0 proof chain. Next free precompile address after Falcon-HashToP
   the real path), so the top level still returns EMPTY for every real SP1 proof. See sections (a), (b),
   (c), (d), (e), (f), and 8 below and `../../docs/AERE-STARK-VERIFIER-PORT-SPEC.md`.
 - Mainnet chain 2800 has exactly the FIVE PQC precompiles 0x0AE1..0x0AE5. 0x0AE8 is not on any Aere
-  network. Consensus stays classical secp256k1 ECDSA QBFT - this is an EVM-layer precompile only.
+  network. Consensus is a separate layer - this is an EVM-layer precompile only.
 
 ## Layout