Runda 11 a reviziei prozei (2026-10-28): corecturi datate (nota de consens 17,250,000 / 17,700,000; clientul 2 al zecelea validator din 2026-09-11; 0,62 s masurat fata de tinta de 0,5 s; zece validatori, cvorum 7) si declaratiile de citari aduse la zi

README.md

@@ -34,7 +34,7 @@ address book of 130+ live contracts on chain 2800.
 |---|---|
 | Chain name | AERE Network |
 | Chain ID | 2800 (`0xAF0`) |
-| Consensus | QBFT; per-block finality on classical secp256k1 ECDSA commit seals, with post-quantum validator seals on consensus messages and a post-quantum certificate under every 32nd block's hash (details on aere.network) |
+| Consensus | QBFT, final on commit at the validators; since block 24,300,000 (AIP-22 stage 4) the Besu-derived validators count a vote only through its 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 are still admitted on their ECDSA commit seals until AIP-22 stage 5); every 32nd block carries a post-quantum certificate whose digest sits under its hash (details on aere.network; corrected 2026-10-28: this row said per-block finality on classical secp256k1 ECDSA commit seals) |
 | Validators | 10 since 2026-09-11, Byzantine-fault tolerance f=3, commit quorum 7 of 10 |
 | Operator / client diversity | Single operator (the Foundation); two client implementations, Besu-derived and Nethermind-derived (one validator, since 2026-09-11) |
 | Block period | 0.5 s target; measured 0.62 s (median of five 20,000-block windows, 2026-10-15); deterministic finality |
@@ -44,24 +44,35 @@ address book of 130+ live contracts on chain 2800.
 | HTTP RPC | `https://rpc.aere.network` |
 | WebSocket RPC | `wss://wss.aere.network` |
 | Explorer (Blockscout) | `https://explorer.aere.network` |
-| Indexer REST | `https://api.aere.network` |
+| Data API (recent blocks and transactions, no indexed history) | `https://api.aere.network` |
 
 ## Consensus and post-quantum boundary (read this)
 
 AERE draws a hard line between consensus and the application layer, and this SDK
 keeps it:
 
-- **Consensus is classical ECDSA on every block, with a post-quantum checkpoint
+- **Consensus is QBFT with post-quantum layers on top of it, each dated
-  every 32 blocks.** Blocks are proposed and sealed under Besu QBFT with secp256k1
+  (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5).** Blocks are proposed and committed
-  ECDSA signatures (nine Foundation validators, quorum 6 of 9, f=2). Since block
+  by ten Foundation validators since 2026-09-11 (quorum 7 of 10, f=3; nine, quorum 6 of 9, f=2,
-  13,014,000 anchor blocks also carry, under the block hash, a certificate of
+  until then): nine run the Besu-derived client, and the tenth, since 2026-09-11, a second,
-  validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block
+  Nethermind-derived client that proposes and seals blocks (its public read endpoint is
-  with fewer than three valid seals (f+1 of nine, not a quorum). That is the whole
+  client2.aere.network). Since block 13,014,000 every anchor block carries a certificate of
-  post-quantum part of consensus: not a per-block quorum (the claim published on
+  validator post-quantum seals whose 32-byte digest sits under the block hash, and since block
-  2026-08-15 was withdrawn on 2026-08-19). A second client (Nethermind) validates
+  20,715,632 (2026-09-29) a node rejects an anchor block with fewer than seven valid seals per
-  and follows the public chain at client2.aere.network; it does not produce blocks.
+  scheme, as many as the quorum (three, f+1 of nine, from 2026-08-14; six from 2026-08-21); from
-- **PQC lives at the application layer.** Five NIST post-quantum verification
+  block 24,148,752 (AIP-22 stage R) a certificate that carries the quorum of one round proves the
-  precompiles are live on mainnet (see below). Contracts and this SDK use them for
+  decision. Every validator refuses a commit without a valid Falcon-512 seal of its author, and
+  since block 24,300,000 (AIP-22 stage 4, 2026-10-25) the Besu-derived validators count a
+  consensus vote only through the verified post-quantum seal of its author. Aere does not claim
+  post-quantum consensus: the transport between nodes is still authenticated by secp256k1, the
+  ten validators are run by one operator, and no third party has audited the system. (Corrected
+  2026-10-28: until that date this paragraph described the network of August 2026 at the present
+  tense: classical ECDSA on every block, nine validators, a minimum of three seals per anchor and
+  a second client that does not produce blocks. A per-block post-quantum quorum claimed on
+  2026-08-15 was withdrawn on 2026-08-19.)
+- **PQC lives at the application layer.** Five NIST post-quantum precompiles are live on
+  mainnet (see below), four signature verifiers and the SHAKE256 hash (corrected 2026-10-28: this
+  called all five verification precompiles). Contracts and this SDK use them for
   application-layer signatures, attestations, key registries, agent DIDs, t-of-n
   custody and a seedless wallet. None of that makes mainnet consensus
   post-quantum, and the SDK never claims it does.

src/wallet/hybridAuth.ts

@@ -8,8 +8,11 @@
 // classical secp256k1-routed, fast. The Falcon root is the QUANTUM-DURABLE
 // authority for the high-assurance actions (the upgrade itself, recovery,
 // high-value / co-signed ops). Only the ROOT is post-quantum; the hot session is
-// not, by design. The AERE chain's own consensus remains classical QBFT/ECDSA —
+// not, by design. The AERE chain's own consensus is QBFT whose headers are still
-// this is application-layer PQC, not post-quantum consensus.
+// admitted on classical ECDSA commit seals until AIP-22 stage 5 (post-quantum layers
+// on top of it are dated in AIP-22; comment corrected 2026-10-28: it said consensus
+// remains classical QBFT/ECDSA): this is application-layer PQC, not post-quantum
+// consensus.
 
 import {
   keccak256, AbiCoder, getBytes, hexlify, toUtf8Bytes, concat,