diff --git a/README.md b/README.md
index 747238a..ef87098 100644
--- a/README.md
+++ b/README.md
@@ -319,4 +319,4 @@ able to trust without checking.
   well: every validator refuses a commit without a valid seal, and nine of the ten refuse any consensus message without
   one; the tenth, which runs the second 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. On the testnet the second client's validator enforces
-  commits since block 1,314,403 and all four types since block 3,117,000 (SPEC section 2.6).) (*Added 2026-10-27:* stage 4 is in force on chain 2800 since block 24,300,000, reached on 2026-10-25; from it the second client judges all four message types by their seals.)
+  commits since block 1,314,403 and all four types since block 3,117,000 (SPEC section 2.6).) (*Added 2026-10-27:* stage 4 is in force on chain 2800 since block 24,300,000, reached on 2026-10-25; from it the second client judges all four message types by their seals.) (*Note added 2026-11-04 (to the addition of 2026-10-27 before it):* its clause on the second client 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 (AIP-22, correction of 2026-11-01 to rule 3 of section 4).)
diff --git a/SPEC.md b/SPEC.md
index 0bd68f5..7f0ffeb 100644
--- a/SPEC.md
+++ b/SPEC.md
@@ -41,6 +41,14 @@ force; below `H_hdr` a header is still admitted on the ECDSA commit seals of one
 2026-10-26 to rule 2 of section 4). The notes of 2026-10-14 that call `H_r` not set or inert, and of
 2026-09-17 and 2026-10-09 that say `H_fin` is not set on chain 2800, describe their date; nothing removed).
 
+Amended 2026-11-04 (to the amendment of 2026-10-26 above). Its sentence that from `H_fin` both clients attribute every
+consensus message only through its verified post-quantum seal, and that the second client's proposal, prepare and
+round-change layers are in force, 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 (AIP-22, correction of 2026-11-01 to rule 3 of section 4).
+The amendment above is kept as it was written; section 2.7 carries a dated parenthesis; nothing removed.
+
 ## 0. Conventions, and how every statement here is grounded
 
 Every normative statement in this document carries one of three markers:
@@ -525,7 +533,7 @@ second client applies the rule to the other three from AIP-22 stage 4, whose hei
 on chain 2800 (section 2.6). A forged classical validator key alone therefore no longer opens a
 round, prepares or commits a block on the live network, since nine of the ten validators refuse such
 messages without a seal. Until AIP-22 stage 4 it can still present proposal, prepare and round-change
-messages in that validator's name to the second client. Alone, that misleads one validator of ten,
+messages in that validator's name to the second client (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). 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 (*Corrected 2026-10-09:* until that date this paragraph said that all four messages "carry