aere-docs/AERE-QUANTUM-MIGRATION-SUMMARY.md

Spec #14: Account migration + network key rotation (quantum layer 11)

Note added 2026-10-30 (consensus). Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.

Note added 2026-09-24 (consensus). Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified 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 still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

Built the LAST account-layer quantum-resistance piece: a real, no-custody, tested contract for moving assets off a classical ECDSA EOA onto a post-quantum account, plus a design doc covering both that and network key rotation (gated).

Deliverables

1. Contract: aere-contracts/contracts/pqc/AereAccountMigrator.sol (solc 0.8.23, OZ SafeERC20 + ReentrancyGuard). New file; deployed contracts untouched.

   • migrate(destination, tokens[], amounts[], moveNative): atomic sweep of ERC-20 balances + optional native AERE from caller (old EOA) to a destination PQC account, one tx, authorized by caller's ECDSA key.
   • migrateToPqcAccount(factory, falconPubKey, salt, expectedDestination, ...): DERIVES the destination from the Falcon-512 key via the live AerePQCAccountFactory.predictAddress, so the sweep is cryptographically bound to the PQC account that Falcon key controls. Optional expectedDestination guard.
   • predictPqcAccount(...) view for frontends.
   • Authorization documented BOTH ways: pre-approval (default) OR EIP-7702 delegation (Aere supports 7702 per the EIP matrix; single-tx approve+migrate).
   • No custody (caller is from, destination is to, one hop; native forwarded in full same-call). No owner/admin/upgrade/withdraw/rescue/sweep. Only recipient is the caller-specified destination.
   • Fail-closed + atomic: zero destination reverts; length/zero-token/zero-amount checks; strict native (StrayNative / ZeroNative / NothingToMigrate); any failed transfer reverts the WHOLE tx (SafeERC20). Emits Migrated(old, new, tokens, amounts, nativeAmount).

2. Test: aere-contracts/test/account-migrator.test.js. RAN it: npx hardhat test test/account-migrator.test.js -> 9 passing (2026-07-19). Destination in strong-path tests is a REAL AerePQCAccount deployed via the REAL AerePQCAccountFactory (Falcon verify mocked; CREATE2 + asset moves fully real). Covers: one-tx ERC-20 migration (both entrypoints), native forward, zero-dest revert, atomicity (first token NOT moved on a failed second leg), only-destination (third party gets nothing), no-admin-drain (ABI has no owner/withdraw/rescue/ sweep; force-sent tokens unrecoverable), fail-closed native + malformed sets.

3. Doc: aerenew/docs/AERE-QUANTUM-MIGRATION.md. Dual:

   • Part A (real): harvest-now-decrypt-later rationale, the live PQC destinations (AerePQCAccount / AerePQCAccountFactory / AereHybridAuth / verifier / key registry), the contract, user flow, and the real 9/9 test result. References the pqc-migration-toolkit as the companion scanner/derivation/simulator.
   • Part B (design only, gated): Foundation operator key rotation = operational role transfer to a PQC/threshold account, founder-gated, NOT coupled to consensus. Validator signing key rotation = coupled to the gated consensus-PQC activation (seals are classical ECDSA QBFT today), founder + external-audit + N>=9 + soak gated. Explicit: none of this makes consensus post-quantum by itself.

Honesty flags carried in the doc

• [VERIFY]: live addresses (factory 0xd5315Ea7...CE58, sample account 0xa42a5e7F...4326f, verifier 0x4E8e9682...D8fFC, key registry 0x1eCa3c5A...3691); AereHybridAuth is repo source, no mainnet address; which threshold account is the intended operator destination.
• [MEASURE]: full operator role-rotation cost across the live role set; consensus-PQC flip fork-freedom / halt-recover behavior at N>=9 soak.

Scope boundary kept

Account migration hardens ACCOUNT authorization only. It does NOT make consensus post-quantum. Validator-key rotation is coupled to the separate gated consensus-PQC item, not a today-action. No new token; no real user/Foundation funds moved (this is the mechanism, not an executed migration). No em-dashes in prose; brand "Aere Network"/"Aere", ticker AERE.