Dated correction 2026-11-04 (third pass) to vote attribution since block 24,300,000: the second client's proposal, prepare and round-change layers in AIP-20, AIP-22 and the AIP index carry the correction (one path of the second client until 2026-10-31 12:27Z; AIP-22 rule 3, correction of 2026-11-01); a dated note to the note of 2026-09-24 in seven documents outside aips/

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
-since block 24,300,000 (AIP-22 stage 4, 2026-10-25). Consensus also binds every 128th
+since block 24,300,000 (AIP-22 stage 4, 2026-10-25) (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says). 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.)
@@ -241,7 +241,7 @@ early is safe.
   criterion of a consensus message. The seal is already required beside the classical signature: the
   validators that run the primary client count a commit only with a valid Falcon-512 seal of its author
   since block 17,250,000, and all four QBFT message types since block 17,700,000; the second client
-  requires the seal on commits and applies the rule to the other three types from AIP-22 stage 4. The
+  requires the seal on commits and applies the rule to the other three types from AIP-22 stage 4 (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says). The
   decision recorded in each header remains the classical commit quorum.
 - **Key reuse and the empty context.** The signature covers the 32-byte `signing_hash` with the
   empty FIPS 204 context. A key that authorizes a type-`0x50` account MUST NOT be used by a signer

aips/AIP-22.md

@@ -46,7 +46,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, active on chain 2800 since block 24,300,000 (2026-10-25); 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-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says); 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) |
@@ -57,7 +57,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 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.)
+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) (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says); 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

@@ -72,7 +72,7 @@ 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 since block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since block 24,148,752 (AIP-22 stage R, 2026-10-24) every post-quantum commit seal is bound to its consensus round and every anchor certificate is v3, carrying that round; since block 25,080,000 (AIP-22 stage 5, 2026-10-30) headers no longer carry ECDSA commit seals, and each carries the Falcon-512 seal of its proposer. (Corrected 2026-10-09: until that date this line named the enforcement on every QBFT
+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-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says). Since block 24,148,752 (AIP-22 stage R, 2026-10-24) every post-quantum commit seal is bound to its consensus round and every anchor certificate is v3, carrying that round; since block 25,080,000 (AIP-22 stage 5, 2026-10-30) headers no longer carry ECDSA commit seals, and each carries the Falcon-512 seal of its proposer. (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.
 

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

@@ -1,5 +1,7 @@
 # AERE consensus, machine-checked SAFETY + LIVENESS verification (with Falcon quorum extension)
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

pq-finality-circuit/README.md

@@ -1,5 +1,7 @@
 # pq-finality-circuit
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

pq-stark/README.md

@@ -1,5 +1,7 @@
 # pqc-fork/pq-stark - PQ STARK-verify precompile 0x0AE8 (BabyBear/Plonky3 FRI/STARK verify skeleton)
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

research/aip-draft-pqc-precompiles.md

@@ -11,6 +11,8 @@ created: 2026-07-11
 requires: EIP-7825 (per-transaction gas cap), RIP-7951 (P-256 precompile precedent), EIP-2537 (BLS12-381 precompiles precedent), FIPS 202, FIPS 204, FIPS 205, Falcon (NIST PQC round-3)
 ---
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

research/pqc-onchain-verification.md

@@ -1,5 +1,7 @@
 # On-Chain Post-Quantum Signature Verification on an EVM Layer-1 (AERE, Chain 2800)
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

research/specs/spec-antimev-mempool.md

@@ -1,5 +1,7 @@
 # AERE Anti-MEV Design: Threshold-Encrypted Mempool and Batch-Atomic Fair Settlement
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

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

@@ -1,5 +1,7 @@
 # AERE Network: Proven Results (status as of 2026-07-11)
 
+> **Note added 2026-11-04 (to the note of 2026-09-24 below).** Its sentence on vote attribution since block 24,300,000 had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height. See the correction of 2026-11-01 to rule 3 in section 4 of AIP-22 (`aips/AIP-22.md` in this repository). The note below is kept as it was written.
+
 > **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
 
 > **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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)