diff --git a/aips/AIP-22.md b/aips/AIP-22.md
index 52c448b..6089aea 100644
--- a/aips/AIP-22.md
+++ b/aips/AIP-22.md
@@ -205,7 +205,7 @@ Both clients of chain 2800 MUST: compute the same `id` from the same key; load,
 
 ## Backwards Compatibility
 
-Every activation height here is a coordinated fork: the same binary and the same schedule on every node that validates or reads blocks (the validators of both clients and every reader, whoever operates it), armed before the height, one node at a time with cooling between restarts (SPEC section 2.6 and the published activation procedure): a node that judges headers on a different binary or a different schedule diverges from the validators at the height, so readers are armed with the validators, never after them. Below each height nothing changes. Headers produced before `H_hdr` keep their ECDSA seals and remain valid at their heights; the strict codec round-trips them unchanged. The public verifier `aere-node/tools/verify-anchor.mjs` needs the scheme-interval schedule (Stage 2), the v3 registry and `id`s (Stage 3), and the proposer seal (Stage 5), each published in the same hour as the fleet change (a registry epoch that the public verifier does not know makes it reject every anchor the new signer takes part in). The published follower configuration in `RUN-A-NODE.md` and the SPEC gain the new properties at each stage. The ZK light client contracts (`AereZkQbftLightClient`, canonical verifiers anchored to the seven-validator set; findings register, 2026-09-05 and 2026-09-11) verify ECDSA quorums with an elliptic-curve SNARK and cannot attest post-quantum finality; after `H_fin` a light client either verifies anchor certificates directly (the published verifier already does) or waits for a hash-based proof system (section 7). Integrators that read `extraData` element 1 as ECDSA addresses must read `id`s from `H_id`; `eth_getBlockByNumber` is otherwise unchanged; `coinbase` becomes an `id`.
+Every activation height here is a coordinated fork: the same binary and the same schedule on every node that validates or reads blocks (the validators of both clients and every reader, whoever operates it), armed before the height, one node at a time with cooling between restarts (SPEC section 2.6 and the published activation procedure): a node that judges headers on a different binary or a different schedule diverges from the validators at the height, so readers are armed with the validators, never after them. Below each height nothing changes. Headers produced before `H_hdr` keep their ECDSA seals and remain valid at their heights; the strict codec round-trips them unchanged. The public verifier `aere-node/tools/verify-anchor.mjs` needs the scheme-interval schedule (Stage 2), the v3 registry and `id`s (Stage 3), and the proposer seal (Stage 5), each published in the same hour as the fleet change (a registry epoch that the public verifier does not know makes it reject every anchor the new signer takes part in). The published follower configuration in `RUN-A-NODE.md` and the SPEC gain the new properties at each stage. The ZK light client contracts (`AereZkQbftLightClient`, canonical verifiers anchored to the seven-validator set; findings register, 2026-09-05 and 2026-09-11) verify ECDSA quorums with an elliptic-curve SNARK and cannot attest post-quantum finality. They also stop following the chain at `H_id`, which is earlier than `H_fin`: their guest program requires the sealing set (the parent's validator list) to equal the trusted set of ECDSA addresses and counts only seals whose ECDSA recovery lands in that set, so the block at `H_id` is the last one it can prove (its parent still lists addresses), every later header lists `id`s that no ECDSA recovery can match, and from `H_hdr` no header carries an ECDSA seal at all. From `H_id` a light client either verifies anchor certificates directly (the published verifier already does) or waits for a hash-based proof system (section 7). Integrators that read `extraData` element 1 as ECDSA addresses must read `id`s from `H_id`; `eth_getBlockByNumber` is otherwise unchanged; `coinbase` becomes an `id`.
 
 ## Security Considerations
 
@@ -281,7 +281,7 @@ Two refinements to the text above, recorded rather than silently applied: the Me
 
 ## Errata
 
-None.
+- 2026-09-24, Backwards Compatibility: the text said that ECDSA-quorum light clients need another path "after `H_fin`". Read in their guest program (`verify_finality` in the QBFT finality crate of the ZK light client), they stop earlier, at `H_id`, because the set they match seals against becomes a list of `id`s there. Corrected in place; nothing else in the section changes.
 
 ## Post-Acceptance Outcome Record