SPEC 2.6 and 3.1, README, anchor/README: message-layer enforcement stated per client (corrected 2026-10-09; from 2026-09-17 the text said all four message types are refused on both clients, while the second client enforces commits since block 18,131,633 and applies the other three types from AIP-22 stage 4, whose height is not yet set on chain 2800; on testnet 28001 since 1,314,403 and 3,117,000); dated notes, nothing removed

README.md

@@ -305,4 +305,8 @@ able to trust without checking.
   facilitator at `https://testnet-rpc.aere.network/x402/` settling a test dollar with EIP-3009 (probed every 6 hours,
   result at `https://testnet-rpc.aere.network/sarcina/x402-proba.json`).
 - [`SPEC.md`](SPEC.md) section 2.6: the four post-quantum consensus message layers (emitted on mainnet, enforced on
-  the testnet).
+  the testnet). (*Note added 2026-10-09:* written on 2026-09-02; since then the layers are enforced on chain 2800 as
+  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).)

SPEC.md

@@ -10,6 +10,13 @@ machine-checked that day, enters the table of formal results; the sentence "prot
 permanently" of section 3.1 is corrected to the reference-point form; the reference-point option
 `aere.pq.checkpoint` of patch 0008 is documented; nothing removed).
 
+Amended 2026-10-09 (sections 2.6 and 3.1: the message-layer enforcement is now stated per client;
+from 2026-09-17 the text said that all four message types are refused "on both clients", while the
+second, Nethermind-derived client enforces only commits until AIP-22 stage 4, whose height is not
+yet set on chain 2800; section 2.6 also said that on testnet 28001 all four enforcements have been
+active since 2 September 2026, which holds for its Besu-derived validators only; corrected in place
+with dated notes; nothing removed).
+
 ## 0. Conventions, and how every statement here is grounded
 
 Every normative statement in this document carries one of three markers:
@@ -285,8 +292,13 @@ nine validators on 2026-09-05 [MEASURED 2026-09-05, `docker inspect` of every va
 height a message of that type without a seal, or with an invalid seal, still counts as a vote; from
 it, it does not. Emission heights on 2800: `proposalPq.attachBlock=16620000`,
 `roundChangePq.attachBlock=16660000`, `preparePq.attachBlock=16690000` (COMMIT seals are emitted
-from the anchor). On the public testnet 28001 all four enforcements have been active since
+from the anchor). On the public testnet 28001 all four enforcements have been active on the
-2 September 2026 (source: `testnet-public/CITESTE-MA.md`).
+Besu-derived validators since 2 September 2026 (source: `testnet-public/CITESTE-MA.md`); the
+Nethermind-derived validator there refuses a commit without a valid seal since block 1,314,403
+(2026-09-11) and judges the other three types by their seals since AIP-22 stage 4 (`H_fin` =
+3,117,000, 2026-09-23). (*Corrected 2026-10-09:* until that date this sentence said that all four
+enforcements have been active on testnet 28001 since 2 September 2026, without the second client's
+later heights.)
 
 **Wire format.** Each payload keeps its upstream RLP list and appends, as its LAST element, an
 optional two-element list `[validatorIndex, signature]` (`validatorIndex` an integer index into the
@@ -353,7 +365,11 @@ consensus binding on these heights (the same caveat as section 3.2): two validat
 different heights disagree about which votes count, and the published activation procedure arms
 every validator at the same four heights, one node at a time, with the chain measured to advance between
 restarts (source: `ARMAREA-IMPUNERII-MESAJELOR-2026-09-02.md`,
-`armeaza-impunerea-pe-flota.sh`).
+`armeaza-impunerea-pe-flota.sh`). (*Note added 2026-10-09:* on chain 2800 the tenth validator, which
+runs the second client, is armed only for commits (amendment of 2026-09-17 below): an unsealed
+proposal, prepare or round-change message counts there and not at the other nine. The difference
+matters for a message that carries no seal, such as one forged with a classical key; section 3.1
+states that case.)
 
 **Order of activation, and why.** The published package arms COMMIT first (a commit that does not
 count only delays finality within the round; the liveness margin is measured), then PROPOSAL,
@@ -369,11 +385,20 @@ these rules is `aere-research/formal-consensus/pq_message_enforcement_smt.py` (s
 audited by a third party.
 
 **Amended 2026-09-17 (state of the enforcement).** The four `forkBlock` heights were set uniformly
-on every validator and all four have passed: 17,250,000 (commit, 2026-09-05), 17,400,000
+on the nine validators of the primary (Besu-derived) client, the whole set at the time, and all four
-(proposal, 2026-09-06), 17,550,000 (round-change, 2026-09-07) and 17,700,000 (prepare, 2026-09-08).
+have passed: 17,250,000 (commit, 2026-09-05), 17,400,000 (proposal, 2026-09-06), 17,550,000
-Since 17,700,000 every QBFT message on the hot path (proposal, prepare, commit, round-change) is
+(round-change, 2026-09-07) and 17,700,000 (prepare, 2026-09-08). Today every validator refuses a
-refused unless it carries a valid post-quantum seal, on both clients (the Nethermind validator
+commit without a valid post-quantum seal of its author, and nine of the ten refuse every QBFT
-enforces since 2026-09-11). The hybrid (Falcon-512 + SLH-DSA-SHA2-128s) keys exist on 2800 and
+message on the hot path (proposal, prepare, commit, round-change) without one: the nine that run the
+primary client, since 17,700,000. The tenth validator (in the set since block 18,083,404) runs the
+second, Nethermind-derived client, which has one enforcement height, for commits, in force on chain
+2800 since block 18,131,633 (2026-09-11); it counts a proposal, a prepare and a round-change by their
+ECDSA author until AIP-22 stage 4 (`H_fin`, whose height is not yet set on chain 2800), from which it
+judges all four by their seals. *Corrected 2026-10-09:* until that date this paragraph said that the
+four message types are refused "on both clients (the Nethermind validator enforces since
+2026-09-11)", and did not say that the four heights are those of the nine validators of the primary
+client; on chain 2800 the second client enforces its commit layer only, and its other three layers
+take effect at AIP-22 stage 4 (AIP-22, Errata entry of that date). The hybrid (Falcon-512 + SLH-DSA-SHA2-128s) keys exist on 2800 and
 every anchor certificate is v2 since block 17,047,600 (2026-09-04). Between 2026-09-01 and
 2026-09-08 this paragraph read "post-quantum in EMISSION only"; that was true for those days and
 is history now. What remains classical is named in section 3.1.
@@ -447,10 +472,18 @@ The defensible sentence, and the only form this document endorses: *every anchor
 finalize without a certificate of at least seven valid Falcon-512 validator seals, as many as the quorum of the ten validators, under its hash (seven since block 20,715,632; six from block 14,961,456 and three before it; see the schedule and the historical windows)*. Blocks between
 anchors carry no Falcon seals in the header and their header is finalized by the ECDSA committed
 seals alone. *Amended 2026-09-17:* the consensus MESSAGES that produce every block (proposal,
-prepare, commit, round-change) carry and require post-quantum seals since 2026-09-08 (section
+prepare, commit, round-change) carry post-quantum seals; every validator requires them on commits,
-2.6), so a forged classical validator key alone no longer opens a round, prepares or commits a
+the nine validators that run the primary client require them on all four since 2026-09-08, and the
-block on the live network; node identity and transport (RLPx) remain classical secp256k1 ECDSA,
+second client applies the rule to the other three from AIP-22 stage 4, whose height is not yet set
-and so does the per-block header artifact between anchors. The anchor is a binding, not a
+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,
+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
+and require" seals, without the second client's exception). Node identity and transport (RLPx)
+remain classical secp256k1 ECDSA, and so does the per-block header artifact between anchors. The anchor is a binding, not a
 replacement, and "post-quantum consensus" without these qualifications overstates (source:
 `anchor/README.md`, section 2.6 as amended). None of this code has been audited by a third party (source: `anchor/README.md`,
 "What is not proven here").

anchor/README.md

@@ -64,10 +64,16 @@ per-block quorum rule would have rejected. The earlier statement in this reposit
 overstates: per-block finality and validator identity are classical elliptic-curve cryptography. The
 four QBFT message types carry a post-quantum seal of their author on chain 2800 since blocks
 16,620,000 (PROPOSAL), 16,660,000 (ROUND-CHANGE) and 16,690,000 (PREPARE), COMMIT seals since the
-anchor itself; and a message without a valid seal is REFUSED from blocks 17,250,000 (COMMIT),
+anchor itself; and a message without a valid seal is REFUSED by the Besu-derived validators from
-17,400,000 (PROPOSAL), 17,550,000 (ROUND-CHANGE) and 17,700,000 (PREPARE). Those four enforcement
+blocks 17,250,000 (COMMIT), 17,400,000 (PROPOSAL), 17,550,000 (ROUND-CHANGE) and 17,700,000
-heights were set on all nine validators on 2026-09-05 and take effect as the chain reaches them;
+(PREPARE). Those four enforcement heights were set on all nine validators on 2026-09-05 and take
-until each height passes, that message type is still accepted without a seal. What a quantum
+effect as the chain reaches them; until each height passes, that message type is still accepted
+without a seal. (*Clarified 2026-10-09:* the words "by the Besu-derived validators" were added on
+that date. On chain 2800 these four heights are those of the nine validators that run this, the
+Besu-derived client, the whole set in September; the tenth validator, admitted at block 18,083,404,
+runs the second, Nethermind-derived client, which refuses an unsealed commit since block 18,131,633
+and applies the rule to proposal, prepare and round-change messages from AIP-22 stage 4, whose
+height is not yet set on chain 2800.) What a quantum
 adversary cannot do at any height is rewrite history past the last anchor without also forging
 Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except the
 last anchor's parent while headers carry ECDSA seals, before stage 5 of AIP-22, since an anchor can be
@@ -282,7 +288,9 @@ registry that maps a validator to its keys, the digest, the scheme schedule and
   live fleet; enforcement is armed by height (see the table) and, at the time of writing, none of the
   four heights has passed. The refusal path has been exercised on the public testnet 28001, including
   against a second, independent client implementation; test-network evidence is evidence about a test
-  network.
+  network. (*Note added 2026-10-09:* written before 2026-09-05; all four heights have since passed on
+  the nine Besu-derived validators, the last on 2026-09-08, and the second client's commit height at
+  block 18,131,633; the first sentence of this item is not re-measured here.)
 - **The hybrid certificate is live but young.** Hybrid certificates have been produced on chain 2800
   since 2026-09-04 with real validator keys, and the public verifier reproduces them from the
   internet. What is not shown here is any third-party review of the SLH-DSA engine copy or of the