aere-docs/AERE-QUANTUM-MIGRATION.md

Aere Quantum Migration: Accounts and Network Keys

Status: user account migration is REAL and TESTED (contract + Hardhat suite, below). Network key rotation is DESIGN ONLY and founder + audit gated. This document is the last quantum-resistance layer at the key-management level (quantum layer 11), and it is honest about which half is a user-callable contract today and which half is a gated network operation.

Scope boundary, stated once and never crossed in this document: moving an account (or a network operator) from a classical ECDSA key to a post-quantum key changes who can authorize. It does NOT make Aere consensus post-quantum. Mainnet chain 2800 still seals blocks with classical secp256k1 QBFT, and the on-chain ZK verifiers (BN254 Groth16) are classical. Validator-key rotation to a post-quantum scheme is therefore coupled to the separate, gated consensus-PQC activation, not implied by anything here.

Two flag conventions are used throughout:

• [VERIFY] a claim that should be confirmed against live chain state or a deployment record before it is relied on.
• [MEASURE] a number or outcome that depends on a measurement or an operational run that has not been performed here.

---

Part A. User account migration (real, tested)

A.1 Why migrate at all: harvest-now-decrypt-later

An Aere externally-owned account (EOA) is authorized by a secp256k1 ECDSA key. Two facts make that a long-term liability once a cryptographically relevant quantum computer exists:

1. ECDSA over secp256k1 is broken by Shor's algorithm. A sufficiently large quantum computer recovers the private key from the public key.
2. An EOA reveals its public key the first time it sends a transaction (the public key is recovered from the signature). So the exposure is not hypothetical for any account that has ever transacted; the key material an attacker needs is already on chain.

The threat is not "funds move today." It is "an adversary records the chain now and breaks the keys later." That is the harvest-now-decrypt-later threat applied to account authorization: long-dormant, high-value holdings sitting under a classical key are exactly the accounts most worth attacking on a horizon of years. The mitigation is to move such holdings, while the classical key is still safe, onto an account whose spending authority is a post-quantum key.

Aere already ships the destinations for that move as live primitives. What was missing, and what this document delivers, is a clean, no-custody path to perform the move. That gap is quantum layer 11 in aerenew/build-tracker/control.json.

A.2 The destinations: Aere's live post-quantum account primitives

The migration does not invent a new account type. It targets the ones Aere already runs:

Primitive	What it is	Auth	Status
AerePQCAccount	ERC-4337 v0.7 smart account owned solely by a NIST Falcon-512 key (897-byte pubkey)	Falcon-512 only, no ECDSA fallback	live sample 0xa42a5e7F...4326f [VERIFY]
AerePQCAccountFactory	CREATE2 factory; account address is a pure function of (falconPubKey, salt)	n/a (permissionless deploy)	live 0xd5315Ea7...CE58 [VERIFY]
AereHybridAuth	Defense-in-depth: authorizes only if BOTH an ECDSA leg and a Falcon-512 leg verify over the same 32-byte hash	ECDSA AND Falcon-512	repo source, no mainnet address [VERIFY]
AereFalcon512Verifier	Live Solidity Falcon-512 verifier the accounts delegate to	n/a	live 0x4E8e9682...D8fFC [VERIFY]
AerePQCKeyRegistry	Proof-of-possession key registry	n/a	live 0x1eCa3c5A...3691 [VERIFY]

Two destination shapes matter for a holder:

• PQC account (Falcon-512 only). Spending authority becomes a single lattice key. Strongest post-quantum posture, but there is no ECDSA fallback: lose the Falcon key and the account is gone. Register the key in AerePQCKeyRegistry and set PQC social-recovery guardians BEFORE moving material value.
• Hybrid account (ECDSA + Falcon-512, via AereHybridAuth). Transition-era: an attacker must break BOTH secp256k1 and Falcon-512. Good for a staged move while a holder still wants a classical leg. AereHybridAuth is repo source with no mainnet address as of 2026-07-19, so standing it up is a founder/deployer step [VERIFY].

The counterfactual address of a Falcon key's PQC account is pure CREATE2 math and can be derived off-chain (see the migration toolkit, aerenew/pqc-migration-toolkit, predictPqcAccountAddress, verified there against the live sample account). The account can receive assets at that address before it is deployed, and be deployed later via createAccount, which is permissionless and idempotent.

A.3 The contract: AereAccountMigrator

File: aere-contracts/contracts/pqc/AereAccountMigrator.sol (solc 0.8.23, OpenZeppelin SafeERC20 + ReentrancyGuard).

It is a pure conduit that atomically moves a caller-specified set of ERC-20 balances, and optionally native AERE, from the caller (the old EOA) to a destination post-quantum account, in one transaction authorized by the caller's ECDSA key. Two entrypoints:

• migrate(destination, tokens[], amounts[], moveNative): move to an explicit destination address.
• migrateToPqcAccount(factory, falconPubKey, salt, expectedDestination, tokens[], amounts[], moveNative): DERIVE the destination from a Falcon-512 key via the live AerePQCAccountFactory.predictAddress, so the holder gets cryptographic assurance they are sweeping into the post-quantum account their Falcon key controls, and nowhere else. expectedDestination is an optional guard: if non-zero it must equal the derived address, else the call reverts.

A read-only predictPqcAccount(factory, falconPubKey, salt) lets a frontend confirm the destination before signing.

Authorization: pre-approval, or EIP-7702

The move is authorized by the caller's classical ECDSA key. The migrator does not invent an authorization scheme; it uses ordinary ERC-20 allowances. Two supply patterns, both documented:

1. Pre-approval (default, works today, no protocol feature). The holder sends one approve(migrator, amount) per ERC-20, then calls migrate. Each safeTransferFrom consumes the allowance and moves the tokens straight to the destination.
2. EIP-7702 delegation (single-transaction UX). Aere supports EIP-7702 (see aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md, row 7702 "Supported", the EOA-delegation primitive Aere carries in place of EIP-3074). The EOA can, in one transaction, temporarily set its account code to a batching delegate that both approves and calls migrate, removing the separate approve transactions. The migrator is agnostic to which pattern is used; under EIP-7702 the caller is still the EOA and every invariant below is unchanged.

No custody, no admin (the core safety property)

• In migrate the caller is the from of every SafeERC20.safeTransferFrom, and the caller-specified destination is the to. Tokens move caller to destination in one hop. The migrator is never the recipient, so it never holds an ERC-20 balance.
• Native AERE (msg.value) is forwarded, in full, to that same destination, inside the same call, guarded by nonReentrant.
• There is no owner, no admin, no upgrade, no initializer. There is no withdraw, rescue, or sweep function, so anything accidentally sent to the migrator can never be pulled out by anyone (stuck-but-safe, not drainable).
• There is no code path that sends value to any address other than the caller-specified destination.

Fail-closed and atomic

• destination must be non-zero (ZeroDestination).
• Token and amount arrays must be equal length (LengthMismatch); each token non-zero (ZeroToken); each amount non-zero (ZeroAmount).
• Native is strict: moveNative true requires non-zero msg.value (ZeroNative); any msg.value sent while moveNative is false reverts (StrayNative), so value can never be stranded. An empty request (no tokens, no native) reverts (NothingToMigrate).
• A single failing transfer reverts the WHOLE transaction (SafeERC20 reverts on a false/failing ERC-20), so the migration is all-or-nothing. It can never leave a holder with a partially drained old account.

The Migrated event

Migrated(address indexed oldAccount, address indexed newAccount, address[] tokens, uint256[] amounts, uint256 nativeAmount) binds the old classical account, the new post-quantum account, and the exact asset set that moved. This is the on-chain, auditable record of a migration.

A.4 The user flow

1. Choose a destination. Generate (or reuse) a Falcon-512 key; derive its counterfactual AerePQCAccount address off-chain (toolkit predictPqcAccountAddress, or the on-chain view predictPqcAccount). For a hybrid transition, register an AereHybridAuth identity instead.
2. Prepare recovery FIRST. If the destination is Falcon-only, register the key in AerePQCKeyRegistry (proof-of-possession) and set PQC social-recovery guardians before moving material value. A Falcon-only account has no ECDSA fallback.
3. Approve. From the old EOA, approve(migrator, amount) per ERC-20 (or bundle the approvals with the migrate via EIP-7702).
4. Migrate. Call migrateToPqcAccount(...) (recommended, destination is bound to your Falcon key) or migrate(destination, ...). One transaction moves the whole asset set plus optional native AERE to the destination. The Migrated event is your receipt.
5. Deploy the account when convenient. AerePQCAccountFactory.createAccount is permissionless and idempotent; the account can be deployed before or after the assets arrive at its counterfactual address.

The migration toolkit (aerenew/pqc-migration-toolkit) is the companion that scans an account's quantum exposure (RED/YELLOW/GREEN), derives the destination address, and prints a step-by-step plan and a gas estimate. This contract is the on-chain executor for step 4.

A.5 Test result (real)

Suite: aere-contracts/test/account-migrator.test.js. Run from aerenew/contracts with npx hardhat test test/account-migrator.test.js.

Result on 2026-07-19: 9 passing.

The destination in the strong-path tests is a REAL AerePQCAccount deployed through the REAL AerePQCAccountFactory (the Falcon verifier is mocked because a genuine Falcon-512 signature cannot be produced inside the hardhat process; the CREATE2 derivation and every asset movement are fully real). Covered:

• a user migrates ERC-20 balances from an EOA to a destination in one tx (both migrate and the Falcon-derived migrateToPqcAccount);
• native AERE forwards to the destination, with nothing stuck in the migrator;
• a zero destination reverts (ZeroDestination);
• a failed token transfer reverts the whole migration, and the first (would-be successful) token is NOT moved (atomicity);
• the migrator sends only to the specified destination; an unrelated third party receives nothing;
• no admin function exists (no owner/withdraw/rescue/sweep/transferOwnership/ initialize in the ABI), and tokens force-sent to the migrator cannot be pulled out by anyone;
• fail-closed native handling (StrayNative, ZeroNative, NothingToMigrate) and malformed asset sets (LengthMismatch, ZeroToken, ZeroAmount).

---

Part B. Network key rotation (design only, founder + audit gated)

This half is DESIGN. Nothing here is a today-action, and nothing here is executed by any contract in this repository. It is documented so the end-to-end quantum-resistance picture is complete and honest about what remains.

There are two network-level classical keys, and they are NOT the same kind of problem.

B.1 Foundation operator key rotation (operational key management) [MEASURE]

What it is. The Foundation operator key is the ECDSA key that holds privileged roles on operational contracts (for example NavOracle attestation, compliance registries, the deployer/owner roles that have not yet been handed to the Timelock). It is a normal account key, not a consensus key.

Why rotate it. Same harvest-now-decrypt-later logic as a user account: a long-lived operator key under ECDSA is a standing liability on a multi-year horizon.

How, honestly. This is an operational key-management step, not a protocol change:

1. Stand up the post-quantum destination for the operator authority. The natural choice is an AerePQCAccount (Falcon-512) or, better for an operator, a post-quantum threshold account (the AereThresholdAccount family, PQC t-of-n 4337) so operator authority is not a single key. [VERIFY] which threshold account is the intended operator destination.
2. Transfer each privileged role from the old ECDSA operator to the new post-quantum account. On contracts that expose role transfer (owner / role-grant), this is a sequence of ordinary role-transfer transactions. On immutable core-economic contracts (Sink, sAERE, burn) there is no admin to rotate, by design, so they need nothing.
3. Where governance is the intended long-term authority, the path is role to Timelock, and the Post-Quantum Governance design (aerenew/docs/AERE-POST-QUANTUM-GOVERNANCE.md) covers granting a PQC threshold account the proposer/executor role on the Timelock.

Gating. This is founder-gated because it moves real privileged authority over live contracts, and it is signed by the Foundation key, not by any contract here. It is NOT coupled to consensus. The cost/outcome of a full rotation across the live role set is [MEASURE] (it depends on the exact contracts and roles enumerated at rotation time). No role is rotated by publishing this document.

B.2 Validator signing key rotation (coupled to consensus-PQC) [MEASURE]

What it is. Each validator seals QBFT blocks with a classical secp256k1 key. This is the consensus signing key, not an application account key.

The honest coupling. Today validator seals are classical ECDSA QBFT. Rotating a validator's signing key to a post-quantum scheme is NOT an isolated key swap: the consensus protocol itself has to accept and verify post-quantum seals. In other words, a validator cannot "rotate to a Falcon seal" while the rest of the network still expects an ECDSA seal. Validator-key rotation to PQ is therefore coupled to the consensus-PQC activation, which is tracked as its own gated item:

• The in-place PQC activation work (hybrid ECDSA + Falcon BLOCKING seal, activated via an anchor contract on the live chain, proven at small N in isolation) is the mechanism that would let the seal set become post-quantum without a re-genesis.
• That flip is HIGH risk (it can halt the chain), and its gates are: N greater than or equal to 9 validators, a soak period, an external consensus audit, and the founder's explicit GO. See the mainnet queue in aerenew/build-tracker/control.json ("Consens post-quantum LIVE", risk MARE).

So the sequence is: consensus-PQC activation FIRST (gated), and validator signing keys rotate to their post-quantum form AS PART OF that activation, not before it and not independently. Doing validator-key rotation "early" has no meaning while consensus verifies classical seals.

Gating. Founder-gated AND external-audit-gated AND dependent on the consensus-PQC item. Not a today-action. Nothing in this repository activates it. The outcome (fork-freedom, halt/recover behavior at the target N) is [MEASURE] against a real soak at N greater than or equal to 9.

B.3 Summary of the network half

Network key	Kind of change	Coupled to consensus?	Gate	Today-action?
Foundation operator key	Operational role transfer to a PQC account	No	Founder	No (founder-signed op)
Validator signing keys	Consensus seal scheme change	Yes	Founder + external audit + N>=9 + soak	No

The single most important honesty point: none of this makes consensus post-quantum by itself. The user account migration in Part A is a real, deployable-today, no-custody contract that hardens ACCOUNT authorization. The network half in Part B is the operator-key rotation (an operational step) plus the validator-key rotation (inseparable from the gated consensus-PQC flip). This is the last quantum-resistance layer, and it is largely gated, not a switch to flip tonight.

---

Part C. Authority residue: why moving the assets is not finishing the job

Added 2026-07-19. Part A moves an account's ASSETS. This part addresses what Part A leaves behind, which is the more dangerous half.

C.1 The gap

After a perfect Part A migration, the old classical EOA is empty. It is not harmless. It still carries:

1. Every ERC-20 allowance it ever granted. approve state lives on the token contract keyed by owner, and sweeping a balance does not touch it. Any token that later arrives at the old EOA is immediately drainable by every spender still holding a non-zero allowance.
2. Any role, ownership, or membership granted to it on other contracts. Sweeping an ERC-20 balance does not transfer an onlyOwner role.
3. Its status as a valid payment destination. Airdrops, refunds, vesting unlocks, exchange withdrawals, and counterparties working from an address book keep sending to it. The account keeps re-accruing value under a Shor-breakable key.
4. Its status as a valid signer for any EIP-712 or EIP-1271 flow that checks only ECDSA.

So an account that has "migrated" can be empty today and hold a meaningful balance again in six months, under exactly the key the migration was meant to retire. The adversary in the model does not need to act now. Harvest-now-decrypt-later means they break the key years later and then collect whatever has pooled there since.

C.2 Which accounts are actually exposed, precisely

The exposure that matters is exposure of the PUBLIC KEY, not of the address. An Aere address is keccak(pubkey)[12:], a hash, and a hash is not Shor-breakable. The public key itself is what Shor's algorithm needs.

Account state	Public key on chain?	Exposed to a future quantum adversary?
Never sent a transaction (receive-only)	No. Only the address hash is public	NOT exposed today. The preimage has never been published
Has sent at least one transaction	Yes. The pubkey is recoverable from the signature	EXPOSED. The material an adversary needs is already public and already archived
Has signed any off-chain message that was published (EIP-191, EIP-712, a permit)	Yes, same recovery applies	EXPOSED, even with zero on-chain transactions
Deployed contract / smart account	No secp256k1 key of its own	Not exposed as a key. Exposure is whatever its OWNER key is

The practical reading: any address that has ever spent anything is already exposed, and that is the overwhelming majority of active accounts. Nothing can un-expose them. The only remaining lever is to stop keeping value there, and to stop the old key from carrying authority. That is what Part A and this part do respectively.

A receive-only account is genuinely in a better position, and it has a strictly better migration: move the funds in a single transaction to a post-quantum account. That first spend does expose the key, but it exposes it at the moment the value is already leaving, which is the one moment exposure costs nothing.

This document does NOT claim a count or percentage of exposed accounts on chain 2800. That would require indexing the full chain history and it was not measured.

C.3 What is a contract, and what deliberately is not

Two things are needed. Only one of them should be a contract, and saying so plainly is the point.

Allowance revocation is NOT a new contract. approve can only be called by the token owner, so no third-party contract can revoke on an EOA's behalf. The revocation has to be executed BY the account. Aere Network already ships the tool: AereDelegate7702V2.executeBatch in aerenew/contracts/contracts/delegation batches the approve(spender, 0) calls into one EIP-7702 transaction from the EOA itself. Writing a second contract for this would add a security surface and buy nothing, so none was written. Enumerating the live spender set per token is an indexer job and belongs in the migration toolkit, not in Solidity.

Retirement declaration IS a contract, because it needs to be permanent, public, and machine-readable, and no existing primitive provides that.

C.3.1 Evidence that no account-level retirement registry already existed

"Nothing existing provides it" is the kind of claim that has to be auditable rather than asserted, so here is the full search and the full result. Run from aerenew/contracts/contracts:

grep -rnE "[Rr]etire|RETIRE" --include=*.sol .

Result on 2026-07-20: 68 matching lines across 9 files. 46 of those lines are in the new pqc/AereAccountRetirement.sol itself, leaving 22 pre-existing lines across 8 files. An earlier build note cited only four hits, which was a filtered subset presented as the whole result. That was wrong and this section replaces it. The conclusion is unchanged, but it is now checkable. Every pre-existing hit:

File	Lines	What it actually is	Account-level retirement registry?
AereCoinbaseSplitterV2.sol	1	Prose comment saying the V1 contract was retired	No. English usage in a comment, no code
aere-contracts/contracts/faucet/AereFaucetV2.sol	1	Comment: the faucet can be "retired" by setting dripAmount to 0	No. Describes a parameter, not a registry
aere-contracts/contracts/modular/AerePQCEncryptedIntent.sol	5	retireEncapKey(), EncapKeyRetired, an active flag	No. Retires one advertised ML-KEM encapsulation key so no NEW intent targets it. Scoped to a key, not to the account, and the account stays fully active
aere-contracts/contracts/modular/AerePQCKeyExchange.sol	7	retireKemKey(), KemKeyRetired, active flag, "register / rotate / retire"	No. Same shape: retires one advertised ML-KEM key for handshake targeting. The account keeps transacting
aere-contracts/contracts/mpc/AereThresholdRegistry.sol	3	Status.RETIRED enum member, CommitteeRetired event, one comment	No, and weaker than it looks. The subject is a threshold COMMITTEE, not an EOA. Also, Status.RETIRED is never assigned and CommitteeRetired is never emitted anywhere in the file: the only status writes are ACTIVE (line 174, 358) and PAUSED (line 350). The state is declared and unreachable
aere-contracts/contracts/pqc/AereHybridAuthorizer.sol	1	Comment: the Foundation "retires a scheme" on the registry	No. Subject is a signature SCHEME, protocol-wide
aere-contracts/contracts/pqc/AerePQCOrderAuthorizer.sol	1	Same scheme-retirement comment	No. Same, subject is a scheme
aere-contracts/contracts/pqc/AerePQCKeyRegistry.sol	3	Rotation "retires the old one", plus append-only key lists that include retired keys	No. Subject is a PQC KEY belonging to an identity. Retiring a key is the opposite direction of travel: it presumes the identity continues, under a new key. There is no way to mark the classical account itself as retired, and no successor pointer

The pattern across all 22 is the same and it is the reason the gap was real. Every pre-existing use retires a KEY, a SCHEME or a COMMITTEE, always as a rotation step that presumes the subject carries on under new material. None of them takes an EOA as the subject, none of them is a one-way latch, and none of them publishes a successor account. AerePQCKeyRegistry is the closest and still does not fit: it would let an identity mark a Falcon key stale, never the secp256k1 account.

Search limits, stated: this is a text search over *.sol under aerenew/contracts/contracts only. It would not catch a registry that implements the same semantics without ever using the word "retire" (for example one built around "deprecate", "sunset" or "revoke" on an account subject), and it does not cover non-Solidity sources or deployed-but-unsourced contracts. Those are the conditions under which the conclusion could still be wrong.

C.4 AereAccountRetirement, the one-way latch

File: aerenew/contracts/contracts/pqc/AereAccountRetirement.sol (solc 0.8.23, no dependencies, no admin, no payable function, holds nothing).

An account calls retire(successor) and irreversibly declares its classical key retired, optionally naming the post-quantum account that replaces it. retireToPqcAccount(factory, falconPubKey, salt, expectedSuccessor) derives the successor from a Falcon-512 key through an AerePQCAccountFactory rather than taking a literal address. Passing the zero successor is legitimate and supported, for an owner who does not want to publicly link the old address to the new one.

What deriving the successor does and does not guarantee. Because the pointer can never be corrected, it is worth being exact about which mistakes this removes.

It removes the transcription class: a mistyped, truncated, wrong-checksum or clipboard-swapped successor address. The caller never supplies the successor at all, so there is nothing to mistype; the address is CREATE2 math over the Falcon public key the caller holds. That is a real and worthwhile guarantee, and it is why the entrypoint exists.

It does NOT remove the wrong-successor class in general. factory is a caller-supplied address and the contract does not validate it. There is no allowlist, no code check and no interface assertion, so a wrong or hostile factory returns a wrong successor and that successor is latched permanently. A hostile factory can return an address it controls. What the design does is move the trust from "did I type twenty bytes correctly" to "do I trust this factory", which is a better question to have to answer, not the absence of one.

The caller must therefore supply a factory they trust. Verify the factory address out of band against the published deployment record before calling, and prefer passing a non-zero expectedSuccessor so the derived address must additionally match one reviewed off chain. Those two checks together, not the function alone, are what make the permanent statement safe.

An earlier revision of this section and of the contract NatSpec said this made the wrong-successor mistake "impossible". That was an overstatement of a narrower true guarantee and has been corrected here and in aerenew/contracts/contracts/pqc/AereAccountRetirement.sol.

Why the latch is one-way. The adversary is someone who breaks the secp256k1 key LATER and can then sign anything the original owner could. If retirement were revocable that adversary would un-retire the account and continue. If the successor were mutable they would repoint it at themselves and harvest anyone honoring the pointer. Immutability is what lets the declaration survive the compromise it exists to outlive. The honest owner acts once, while the key is still safe, and the statement outlives the key. This is the property the test suite targets directly.

Integrators read isRetired(account), successorOf(account), or call the reverting guard requireActive(account) at the top of a sensitive function.

C.5 What this honestly cannot do

Stated plainly, because a registry is easy to oversell:

• It cannot stop native AERE or a non-integrating ERC-20 from being sent to a retired address. Base-protocol transfers consult no registry, and making them do so would be a consensus change. Aere is not making one. Consensus on chain 2800 is and remains classical secp256k1 ECDSA QBFT.
• It cannot revoke an allowance. See C.3.
• It cannot help an account whose key is ALREADY broken. An adversary holding the key can retire it too, or simply move the assets. This works only in the window where the honest owner acts first, which is the entire argument for migrating early rather than waiting for a quantum event.
• It binds only the contracts, wallets, indexers and counterparties that CHOOSE to read it. It is an opt-in enforcement surface and an advisory signal, not a protocol rule.

Its value is being a permanent, checkable, machine-readable statement of intent that an attacker who later owns the key cannot retract.

C.6 Test result (real)

Suite: aerenew/contracts/test/account-retirement.test.js. Run from aerenew/contracts:

npx hardhat test test/account-migrator.test.js test/account-retirement.test.js

Result on 2026-07-19: 20 passing (9 pre-existing migrator tests, 11 new retirement tests). Covered by the new tests: retirement with and without a published successor; Falcon-derived successor through the real factory; mismatch guard; the latch holds against an attacker who has the key (cannot un-retire, cannot repoint, via either entrypoint); retirement is strictly self-scoped so no third party or admin can retire another account; no admin surface and no payable function; the self-referential successor is rejected; requireActive guards correctly; a never-retired account reads as a clean zero record.

The "no payable function" assertion was checked against a positive control: the same ABI inspection reports 2 payable functions on AereAccountMigrator and 0 on AereAccountRetirement, so the assertion is not passing vacuously.

Deployment status: NOT DEPLOYED. This contract exists in the repository and passes its suite. It is not on mainnet 2800 and no transaction was sent. Deploying it is founder-gated.

---

Files

• aere-contracts/contracts/pqc/AereAccountMigrator.sol (contract)
• aere-contracts/test/account-migrator.test.js (Hardhat suite, 9 passing)
• aerenew/contracts/contracts/pqc/AereAccountRetirement.sol (contract, Part C, NOT deployed)
• aerenew/contracts/test/account-retirement.test.js (Hardhat suite, 11 passing)
• aere-contracts/contracts/delegation/AereDelegate7702V2.sol (executeBatch, the existing tool for batch allowance revocation; no new contract was written for revocation)
• aerenew/pqc-migration-toolkit/ (scanner + derivation + cost simulator)
• aere-contracts/contracts/pqc/AerePQCAccount.sol, AerePQCAccountFactory.sol, AereHybridAuth.sol (destinations)
• aerenew/docs/AERE-POST-QUANTUM-GOVERNANCE.md (Timelock role grant to a PQC threshold account, the governance path for operator authority)
• aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md (EIP-7702 support)