AIP-22 erratum 2026-10-01: the post-quantum commit seal carries no round, so a certificate of seals does not prove that the anchor's parent was decided

Measured in the reference client: at N = 10, seven valid Falcon-512 seals over M(p) from rounds 0 and 2 while p' is decided in
round 3, and an anchor over p carrying them passes the certificate rules. Withdrawn as written until the commit seal binds the
round: the finality definition of section 1, the Rationale's implication that a quorum of seals proves consensus, and the
Security Considerations claim for H_fin. Chain 2800 below stage 5 is not affected. The original text stays; the correction is
dated in a note at the top and in the Errata.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

aips/AIP-22.md

@@ -6,6 +6,11 @@
 > stage 2 (Falcon-512 every 32nd block, SLH-DSA every 128th) from block 20,746,736, both on 2026-09-29, and stage 3
 > (post-quantum validator ids in the header and in `qbft_getValidatorsByBlockNumber`) from block 20,836,228, on
 > 2026-09-30. Stages 4 and 5 (per-block post-quantum finality, the header without ECDSA) are not active on chain 2800.
+>
+> **Correction added 2026-10-01.** The post-quantum commit seal `M(B)` carries no round, and a certificate of seals over
+> `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.
 
 ## Preamble
 
@@ -302,6 +307,25 @@ Two refinements to the text above, recorded rather than silently applied: the Me
 - 2026-09-24, section 9: the text said that conformance vectors "are published" with the reference implementation. No AIP-22 vector corpus is published yet; the sentence now says they are to be, and says what has been done instead (both clients checked against each other on chain 28001 at every stage).
 - 2026-09-25, section 5: the text admitted a header's proposer seal only for the `coinbase`'s `id`. A block prepared in one round and re-proposed unchanged in a later one keeps its builder's `coinbase` and carries the later round's proposer's seal, and every node refused it (stage record of 2026-09-25). Corrected in place in the working text on 2026-09-25; the published text carried the old rule until 2026-09-27 (stage record of that date).
 
+- 2026-10-01, sections 1, 4 and 6, Rationale and Security Considerations: the post-quantum commit seal is made over
+  `M(B) = keccak256(RLP["AERE-PQ-COMMIT-1", chainId, number(B), hash(B)])`, which has no round. In QBFT an honest validator can
+  commit a block `p` in one round while a different block `p'` is decided in a later round (the round-change justification
+  does not need every honest lock to be in its quorum), and seals over `M(p)` made in different rounds cannot be told apart.
+  Measured on 2026-10-01 in the reference client (test classes `AereRoundFreeCertificateTest`, `AereRoundFreeRestartTest`,
+  `AereRoundFreeCommitTest`): at N = 10, seven valid Falcon-512 seals over `M(p)` from rounds 0 and 2, `p'` decided in round 3,
+  and an anchor over `p` carrying those seven seals passes the certificate rules; the same holds up to ten seals with more
+  round changes (derived, not run). Withdrawn as written, until the commit seal binds the round: (1) the definition of
+  post-quantum finality in section 1, which takes a certificate of `Q` seals over `M(parent(A))` as proof that `parent(A)`
+  is final; what such a certificate does prove, when every honest validator runs the clients' decided-head rule, is that
+  the anchor's grandparent was decided; (2) the Rationale's "below the quorum the certificate proves participation, not
+  consensus", which implies that at the quorum it proves consensus; (3) in Security Considerations, "after `H_fin`: cannot
+  cause any node to consider any block final": from `H_fin` the author of a commit is taken from its post-quantum seal and
+  the round is bound only by the ECDSA commit seal, which the adversary of that section holds. Not affected: chain 2800 below
+  stage 5 (every header carries the ECDSA commit quorum of one round), the anchor certificate as evidence of participation,
+  and the message-layer seals, which carry the round. On testnet 28001, where stage 5 is active, the `finalized` tag can name
+  a block no round decided; not exercised as an attack. The remedy proposed is a commit seal that binds the round, with a
+  certificate of `Q` seals of one round; it is a coordinated fork and is not scheduled.
+
 ## Post-Acceptance Outcome Record
 
 Not accepted; nothing to record.