aere-docs/AERE-POST-QUANTUM-GOVERNANCE.md

Spec 29: Post-Quantum Governance

Aere Network, chain ID 2800. Design specification. Status: DESIGN plus a capability on already-deployed primitives. Not activated.

Honest scope, stated first

This document specifies how Aere's governance layer becomes post-quantum-authenticated: votes signed with a post-quantum key, threshold approval by a post-quantum committee, and upgrades authorized by a post-quantum-signed governance action end to end.

Read the following before anything else in this document.

1. This is a DESIGN plus a capability built on primitives that are already deployed and live on mainnet. It is not, itself, a live governance system.
2. Aere's governance is INERT today. The Governor and Timelock own nothing and control nothing; live voting power is zero because no AERE is staked yet. This is true of the classical governance stack and it is equally true of the post-quantum design layered on top of it.
3. Activating any funds-bearing or control-bearing governance path is founder-gated and audit-gated, exactly like the rest of mainnet. Nothing in this document authorizes a transfer of ownership, a funding action, or a consensus change.
4. This is governance-layer authentication only. It does NOT make consensus post-quantum. Aere consensus remains classical secp256k1 ECDSA QBFT. See Section 5.

Where an address or claim is not independently confirmed on-chain, it is flagged [VERIFY: ...] inline.

1. The coherence argument

Aere leads on post-quantum cryptography at the application and account layer. Five signature and hash precompiles are live on mainnet (activated at block 9,189,161) in the 0x0AE1..0x0AE5 band: Falcon-512 (0x0AE1), Falcon-1024 (0x0AE2), ML-DSA-44 (0x0AE3), SLH-DSA-SHA2-128s (0x0AE4), and SHAKE256 (0x0AE5). On top of these sit a Falcon-owned smart account, a hybrid ECDSA-plus-Falcon authorizer, a post-quantum threshold account, and a post-quantum attestation registry, all verifying in full, on-chain, through those precompiles.

A chain that authenticates payments, identities, and custody with post-quantum signatures should not authenticate its own governance with classical-only signatures. If a future adversary with a cryptographically relevant quantum computer could forge the ECDSA signature that casts a decisive vote, or the ECDSA multisig that approves a queued upgrade, then governance is the weakest link on an otherwise post-quantum-forward chain. The control plane would be softer than the assets it controls.

This is the same class of problem as an earlier honesty fix on Aere, where a randomness surface that returned a fixed true was corrected so that what the system claimed and what the system did were the same thing. Here the incoherence is not a false return value but a cryptographic asymmetry: strong authentication everywhere except the layer that decides upgrades and spends. This document closes that gap by specifying three things:

• Post-quantum-signed votes. A voter authenticates a ballot with a Falcon-512 signature, verified by the live 0x0AE1 precompile, instead of, or in addition to, an ECDSA signature.
• Post-quantum threshold approval. The multisig control path over the Timelock (guardian veto, and optionally proposal and execution) is an AereThresholdAccount, a t-of-n Falcon committee, instead of a classical ECDSA multisig.
• Post-quantum-authorized upgrades. A parameter change or contract upgrade is authorized by a governance action that is post-quantum-signed from the ballot through to the Timelock-gated execution.

The result is a governance layer whose authentication strength matches the rest of the chain. What follows is deliberately explicit about which of these is a straightforward capability on primitives that already exist, and which is new contract work.

2. The existing primitives

Every building block this design needs is already deployed on chain 2800. This section is the inventory. Addresses are cited from the canonical registry (aerenew/sdk-js/src/addresses.ts) and the governance and threshold docs (aerenew/docs/GOVERNANCE.md, aerenew/docs/THRESHOLD-PQC-2026-07-12.md, aerenew/docs/AUDIT-FINDING-THRESHOLD-DUPLICATE-KEYS-2026-07-15.md).

2.1 The Governor and Timelock (INERT)

The canonical governance stack is a standard OpenZeppelin v4.9.6 Governor plus TimelockController, deployed and proven binding on a throwaway target, but staged: it owns nothing and must pass an external audit before the Foundation migrates any ownership to it.

Contract	Address	Role	Owns anything real?
AereGovernorV2	0x03251BD9A115385B76220b17914f56eAC0773047	Proposal and voting engine; executes through the Timelock. Robust-quorum fix (pre-proposal denominator plus a floor and cap band).	No
AereGovernorV2Timelock	0x9d618c5AB5f40c7187fc8D644d1aC9Bae0805f85	2-day delay queue; the only address a future migration would grant power to; Governor is PROPOSER, EXECUTOR, CANCELLER; deployer admin renounced.	No (owns nothing today)
AereGovLockV2 (govAERE)	0x547F58B087BEbB1746d6159070E755b868C27731	Custody-lock, non-transferable, checkpointed vote source; voting power cannot detach from capital.	No

Live governance parameters on the deployed Governor: proposal threshold 100,000 govAERE, voting delay about 1 day, voting period about 7 days, quorum 10% of past total supply, simple-majority pass rule, Timelock delay exactly 2 days (timestamp based). The Timelock separates three powers: PROPOSER (queue), EXECUTOR (run), and CANCELLER (cancel a queued item), which is the role structure the threshold design in Section 3.2 attaches to.

Provenance and lineage (retained for the record, not migration targets):

• Deprecated first stack: AereGovernor 0xd16C2551Bf4f3d0DDF961282078917b2e8679999, AereTimelockController 0xf95738Cf366Dd2ea76fBa1b2736163BDc11D2e55, AereStakedGovVotes (the original gAERE) 0xD7575795A055cb093957B86f0607871A2D37805C. Carries a lazy-sync vote source and a quorum-inflation finding.
• Deprecated custody-lock stack: AereGovLock 0xec7994D1Cf8C00b5674AEBd786b0680E56A8eeF8, AereGovLockGovernor 0xb7657b15bFa6369c84a431fc4e47f7f8234B39Cf, AereGovLockTimelock 0x87E1874f3d78925671a889EaBf64d2001f27dD81. Superseded by the V2 stack above.
• Legacy advisory governor: AereGovernanceStaked 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb, structurally inert.

2.2 The governance token (gAERE / govAERE)

Voting power is a non-custodial, checkpointed mirror of real staking, never a new token (AERE is the only token).

• The original gAERE, AereStakedGovVotes 0xD7575795A055cb093957B86f0607871A2D37805C, is a checkpointed ERC20Votes adapter over AereStakingV2 (0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC) and AereLockedStaking (0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad). It custodies nothing, is non-transferable, and is minted or burned by a permissionless sync. It is superseded together with the deprecated stack it served.
• The canonical vote source is govAERE, AereGovLockV2 0x547F58B087BEbB1746d6159070E755b868C27731, a custody-lock veToken-style non-transferable checkpointed votes source paired with AereGovernorV2.

Both expose the IVotes interface that OpenZeppelin's Governor reads via getPastVotes(account, snapshotBlock), so a vote's weight is fixed at a past snapshot and is flash-stake resistant. Live supply is 0 today because live stake is 0.

2.3 The post-quantum threshold account

AereThresholdAccount (source aerenew/contracts/contracts/mpc/AereThresholdAccount.sol) is a non-custodial ERC-4337 v0.7 smart account whose owner is a t-of-n post-quantum committee. A call is authorized only when at least threshold DISTINCT committee members each supply a valid NIST post-quantum signature (Falcon-512 or Falcon-1024 or ML-DSA-44 or SLH-DSA-128s) over the account's domain-separated challenge, every leg verified in full, on-chain, through the live precompiles. No single party's key can move funds; there is no admin, owner override, or recovery backdoor. It exposes two domain-separated paths: an ERC-4337 validateUserOp path (bundler), and a direct executeThreshold(target, value, data, legs) self-relay path with its own execNonce replay barrier. Each leg is verified through the shared library AerePQCThreshold, whose scheme-to-precompile routing is 1 = Falcon-512 (0x0AE1), 2 = Falcon-1024 (0x0AE2), 3 = ML-DSA-44 (0x0AE3), 4 = SLH-DSA-128s (0x0AE4).

Deployment status of the threshold family:

Component	Address	Status
AereThresholdAccountFactory (CREATE2 factory for the account)	0xf8fCC337d7749Ff2935D755C5F3934e2B70779E8	LIVE on mainnet, but carries a duplicate-committee-key finding; 0 accounts ever created (zero exposure). Superseded by a source-only fix.
Account factory V2 (fixed, rejects duplicate keys)	not on mainnet	Source-fixed; mainnet redeploy is founder-gated. [VERIFY: a session note recorded a V2 factory at 0x69734E4044B1C5943B9256A73De41B101BFA2633, but it was not independently confirmed on-chain and is treated here as not deployed. Confirm before citing as live.]
AereThresholdPQCRegistry (registry-style t-of-n PQC authorization, buggy)	0x9a6096F6FB3a7E54cF70DE12Cb3903Ae79D1C213	LIVE, same duplicate-key finding, 0 committees (zero exposure). Superseded.
AereThresholdPQCRegistry V2 (fixed)	0x8Fbfe1C72E8c83ca2a0c475ce3648D47bCC8643c	Deployed and live on mainnet, inert (0 committees).
AereThresholdRegistry (classical threshold-ECDSA sibling, clean)	0x875BA0dbA1806Ad9aE57627d705ecA12139D1EF4	LIVE, no fund custody, 0 committees. Metadata plus ecrecover, not post-quantum.

The registry V2 (0x8Fbfe1...) proves the t-of-n Falcon verification path end to end on live precompiles today. The account factory that would mint a control-bearing threshold account with the duplicate-key fix is not yet on mainnet; its redeploy is founder-gated (see Section 4).

2.4 The Falcon precompile and the Falcon-owned account

• Falcon-512 verification precompile: 0x0AE1, live on mainnet since block 9,189,161, marginal verify cost 40,000 gas, fail-closed (returns a 32-byte zero word on a bad or malformed signature; never reverts). This is the single primitive every part of the design below leans on.
• AerePQCAccount: an ERC-4337 v0.7 smart account whose sole owner is a Falcon-512 public key (897 bytes, no classical ECDSA fallback), with validateUserOp and EIP-1271 isValidSignature both decided by Falcon. The live sample account is AerePQCAccount_sample 0xa42a5e7F72E46BadC11367650Ec34D676194326f; its EIP-1271 path was demonstrated live (accept magic 0x1626ba7e, tampered signature to 0x0). Honest cost note: the live sample decides isValidSignature through the pure-Solidity AereFalcon512Verifier 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC at about 10.5M gas per verify; a precompile-backed isValidSignature (routing to 0x0AE1, 40,000 gas) is the variant the vote path in Section 3.1 should use.
• AerePQCAttestation 0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A demonstrates the full pattern already: a contract that takes a NIST post-quantum public key and a signature and verifies, on-chain, through the live precompile, that the signature covers a domain-separated challenge, with strict nonce replay protection. The vote path reuses this exact shape.

3. The design

Three parts. Each states the mechanism, then whether it is a capability on the primitives above or new contract work.

3.1 Part A: post-quantum-signed votes

Goal. A voter authenticates a ballot with a Falcon-512 signature, verified by 0x0AE1, instead of or in addition to an ECDSA signature, so that a decisive vote cannot be forged by breaking secp256k1 alone.

OpenZeppelin's Governor already exposes two authenticated vote entry points: castVote (authenticated by msg.sender) and castVoteBySig (authenticated by an EIP-712 signature over the ballot, so a vote can be relayed by a third party). castVoteBySig resolves the signature through SignatureChecker.isValidSignatureNow(voter, hash, signature), which accepts EITHER an ECDSA signature from an EOA voter OR, when voter is a contract, an EIP-1271 isValidSignature result from that contract.

There are two mechanisms, at two different levels of effort.

Mechanism A1 (EIP-1271 path, capability on existing primitives). Let the voter be a Falcon-owned smart account (AerePQCAccount, or an AereThresholdAccount for a committee voter). The voter delegates its govAERE voting weight to itself in the standard ERC20Votes way. A relayer submits castVoteBySig(proposalId, support, voterAccount, falconBallotSignature). The unmodified Governor calls voterAccount.isValidSignature(ballotHash, falconBallotSignature), the account verifies the Falcon signature through 0x0AE1, and returns the EIP-1271 magic value on success. The Governor counts the vote. No Governor change is required, because the standard castVoteBySig plus EIP-1271 path already routes signature authority to the voter's own account. This is the important honesty point for Part A: a Falcon-authenticated ballot is expressible today, on the deployed Governor, using an AerePQCAccount voter, provided that account's isValidSignature is backed by the 0x0AE1 precompile (40,000 gas) rather than the ~10.5M-gas Solidity verifier the live sample uses. Recommended concrete step: deploy a precompile-backed AerePQCAccount variant and use it as the voter.

Mechanism A2 (explicit-verify path, new contract work). For a voter that has no deployed smart account (a raw Falcon keypair), add a Governor extension, AerePQCGovernor, with an explicit ballot entry point:

castVoteWithFalconSig(
    uint256 proposalId,
    uint8   support,
    address voter,            // the govAERE-weighted identity
    bytes   falconPubKey,     // 897-byte Falcon-512 public key bound to `voter`
    bytes   falconSignature   // Falcon signature over the domain-separated ballot
)

The extension recomputes the ballot challenge keccak256(BALLOT_DOMAIN, block.chainid, address(this), proposalId, support, voter, nonce), calls 0x0AE1 with (falconPubKey, challenge, falconSignature), and on a verified result records the vote with weight getPastVotes(voter, proposalSnapshot). The public-key-to-voter binding is established once through a proof-of-possession registration, exactly as AerePQCAttestation and AerePQCKeyRegistry 0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691 already do on live precompiles, so a voter cannot claim a Falcon key it does not control. A strictly increasing per-voter ballot nonce prevents replay. This path is a new, small, audit-scoped extension of the OpenZeppelin counting module; it does not touch the vote-weight source or the Timelock.

Either mechanism can be offered as an additional path alongside ECDSA rather than a replacement, so classical and post-quantum voters coexist during a transition.

3.2 Part B: post-quantum threshold timelock control

Goal. The multisig approval that guards queued upgrades is a t-of-n Falcon committee, not a classical ECDSA multisig, so the control path over the Timelock is post-quantum.

In the classical governance design (GOVERNANCE.md, Section 6.2) the Timelock's safety valve is a guardian multisig that holds only the CANCELLER role: it can veto a queued proposal during the 2-day delay, but it cannot propose, execute, or change parameters. In a conventional deployment that guardian is a Gnosis-Safe-style ECDSA multisig. The design replaces it with an AereThresholdAccount.

Mechanism. Because AereThresholdAccount is an ERC-4337 account that can make an arbitrary authorized call through executeThreshold(target, value, data, legs), and because the OpenZeppelin TimelockController grants and checks roles by address, the threshold account can hold a Timelock role directly:

• Grant the CANCELLER role on AereGovernorV2Timelock 0x9d618c5A...5f85 to an AereThresholdAccount whose committee is the guardian set. A veto then requires at least threshold distinct guardians to each Falcon-sign the exact cancel(id) challenge; the account verifies each leg through 0x0AE1 and only then issues the cancel. The veto control path is now post-quantum and t-of-n, with no single guardian key able to veto alone and no ECDSA key on the safety valve.
• Optionally, the same construction extends to PROPOSER and EXECUTOR. A committee-gated PROPOSER means queuing a Timelock action requires a Falcon t-of-n approval; a committee-gated EXECUTOR means running a matured action does too. Least-authority still applies: grant only the roles the deployment intends the committee to hold.

The distinctness guarantee is load-bearing here, which is exactly why the duplicate-key finding matters: a committee that accepted the same public key at two indices could let one keyholder fill multiple slots and reach threshold alone, collapsing the t-of-n property. The fixed account source rejects duplicate committee keys at initialization, and the fixed PQC registry (0x8Fbfe1...) proves the corrected verification path on live precompiles. This is why a control-bearing threshold guardian must wait for the founder-gated account-factory V2 redeploy (Section 4), not the live V1 factory.

3.3 Part C: post-quantum-authorized upgrades end to end

Goal. A parameter change or contract upgrade is authorized by a post-quantum-signed governance action from the ballot to the Timelock-gated execution, with no classical-only choke point on the control path.

Mechanism. Compose Parts A and B along the standard proposal lifecycle (propose, voting delay, active voting, queue, Timelock delay, execute), replacing the classical authentication at each authority-bearing step with a post-quantum one:

1. Propose. A proposer whose snapshot govAERE weight meets the 100,000 threshold submits (targets[], values[], calldatas[], description). If the proposer is a Falcon-owned account, the proposal transaction itself is authorized post-quantum (Part A account as the sender).
2. Vote. Holders cast Falcon-signed ballots via Mechanism A1 or A2. A proposal succeeds on quorum plus simple majority, read from the past snapshot.
3. Queue. The succeeded proposal is queued into AereGovernorV2Timelock. If PROPOSER is the threshold committee (Part B), queuing requires a Falcon t-of-n approval.
4. Timelock delay and veto. During the 2-day delay, the post-quantum guardian committee (Part B, CANCELLER) can veto with a Falcon t-of-n signature. The delay is timestamp based and exact regardless of block time.
5. Execute. After the delay, execution makes the calls: a transferOwnership, a parameter setter, a treasury spend, or an upgrade call. If EXECUTOR is the threshold committee, execution requires a Falcon t-of-n approval too.

The end-to-end property is that every authority-bearing decision on the path, who may vote, whether the vote counted, who may queue, who may veto, who may execute, rests on a NIST post-quantum signature verified by the live 0x0AE1 precompile, not on an ECDSA signature alone. The vote-weight source (govAERE) and the delay semantics are unchanged; only the authentication is upgraded. What an upgrade can reach is unchanged from the classical framework: Ownable protocol contracts whose ownership the Foundation migrates to the Timelock are governable; immutable, ownerless contracts (AereSink 0x69581B86A48161b067Ff4E01544780625B231676, the post-quantum verifier suite, the state-channel and rollup-validity contracts) remain permanently outside governance and cannot be reached by any proposal, post-quantum-signed or not.

4. Honest status and gates

4.1 Capability on existing primitives versus new contract work

Element	Classification	Basis
Falcon-512 verification of a governance signature	Capability, live	0x0AE1 live since block 9,189,161; used in production by AerePQCAttestation, AerePQCKeyRegistry, AereThresholdPQCRegistry V2.
Falcon-authenticated ballot via EIP-1271 voter (A1)	Capability, on existing primitives	Unmodified OpenZeppelin castVoteBySig plus EIP-1271 already routes signature authority to the voter account; needs a precompile-backed AerePQCAccount voter, no Governor change.
Explicit castVoteWithFalconSig extension (A2)	New contract work	A new, small AerePQCGovernor counting extension plus a proof-of-possession key binding. Audit-scoped.
t-of-n Falcon committee holding a Timelock role (B)	Capability in principle, gated in practice	AereThresholdAccount exists and its verification path is proven; a control-bearing account needs the founder-gated factory V2 redeploy (below). Wiring is a role grant on the Timelock.
End-to-end post-quantum-authorized upgrade (C)	Composition of the above	No new consensus or protocol change; a composition of A, B, and the standard lifecycle.

4.2 Governance is inert today

Nothing in this design is live governance. The Governor and Timelock own nothing and control nothing until an audit-gated ownership transfer, live voting power is zero because no AERE is staked, and the Foundation key (a single-key EOA, not yet a multisig) still owns effectively every Ownable protocol contract across 7 Foundation-operated QBFT validators. A passed proposal, classical or post-quantum-signed, changes nothing about the protocol until stake exists and ownership is migrated. This design does not change that status; it specifies the authentication the governance layer should use if and when it is activated.

4.3 Cost note

Post-quantum verification is more expensive than ECDSA, and the design accepts that cost because governance actions are low-frequency. The marginal verify cost, measured on the live precompiles, relative to ecrecover at 3,000 gas:

Operation	Marginal verify gas	Ratio to ecrecover
ecrecover (secp256k1)	3,000	1x
Falcon-512 (0x0AE1)	40,000	about 13x
ML-DSA-44 (0x0AE3)	55,000	about 18x
Falcon-1024 (0x0AE2)	75,000	about 25x
SLH-DSA-SHA2-128s (0x0AE4)	350,000	about 115x

So a post-quantum verify costs roughly 13x to 115x an ECDSA recovery depending on scheme, and a Falcon-512-signed vote or veto carries the 40,000-gas leg (about 13x) on top of the ordinary vote or cancel transaction. Every figure is well under the EIP-7825 per-transaction cap of 2^24 (16,777,216) gas, and a t-of-n veto pays that leg once per participating member. For a vote cast once per proposal and a veto used rarely, this is acceptable, but it is a real and stated cost, not a free upgrade. It should not be applied to a high-frequency hot path; governance is precisely the low-frequency, high-value setting where it is worth paying.

4.4 Activation is founder-gated and audit-gated

Three independent gates, in order, exactly as the classical governance framework already commits to:

1. External audit (blocking). The Governor, Timelock, and vote source, plus any new AerePQCGovernor extension and the threshold-account factory V2, must be reviewed by an external auditor before the Timelock owns anything of value.
2. Real, distributed stake. Quorum and threshold are meaningful only once real AERE is staked and delegated, and only once operation decentralizes beyond a single operator.
3. Foundation migrates ownership (staged). For each contract to be governed, the Foundation key calls transferOwnership(Timelock). This design performs no such transfer.

Two post-quantum-specific gates sit inside these:

• The control-bearing AereThresholdAccount for Part B requires the founder-gated account-factory V2 redeploy. The current live factory (0xf8fCC337...) carries the duplicate-key finding; the fix is applied to source but its mainnet redeploy has not occurred and is founder-gated. A t-of-n governance guardian must be minted by the fixed factory, not the live one. [VERIFY: confirm the account-factory V2 mainnet address once the founder-gated redeploy is executed; no confirmed on-chain V2 factory address exists at the time of writing.]
• The A1 vote path should use a precompile-backed AerePQCAccount variant (40,000 gas) rather than the live sample's Solidity verifier (~10.5M gas). [VERIFY: confirm the deployed address of the precompile-backed AerePQCAccount variant used as the vote identity; the live sample 0xa42a5e...326f uses the Solidity verifier path.]

5. Scope boundary

This is governance-layer post-quantum authentication and nothing more.

• It does NOT make Aere consensus post-quantum. Consensus stays Hyperledger Besu QBFT with classical secp256k1 ECDSA, N=7 validators, f=2, commit quorum 5 of 7, and roughly 0.5-second blocks. Validator identity is by ECDSA ecrecover over committed seals; that is unchanged.
• The precompiles this design uses are application-layer and account-layer. A contract verifying a Falcon signature is not the chain reaching post-quantum consensus, and this document must never be read as claiming otherwise.
• Post-quantum-authenticated governance can decide, subject to audit and founder gating, to pursue post-quantum consensus as a separate, higher-risk program. That is a different and much larger change (a supervised consensus activation, not a contract deployment), out of scope here.
• Post-quantum authentication of a governance signature does not make the interop and zk light-client contracts post-quantum: those still rely on classical secp256k1 seals and Groth16 over BN254, and are trust-minimized, not trustless. This design does not touch them.

The one-sentence statement of scope: this specifies how governance authenticates itself with post-quantum signatures on already-live precompiles, as an audit-gated and founder-gated design over an inert governance layer, and it changes nothing about consensus.

Appendix: cited addresses (chain 2800)

Name	Address	Notes
Falcon-512 precompile	0x0AE1	Live since block 9,189,161; 40,000 gas; fail-closed.
Falcon-1024 / ML-DSA-44 / SLH-DSA-128s / SHAKE256 precompiles	0x0AE2 / 0x0AE3 / 0x0AE4 / 0x0AE5	Live, same band.
AereGovernorV2	0x03251BD9A115385B76220b17914f56eAC0773047	Canonical Governor, inert.
AereGovernorV2Timelock	0x9d618c5AB5f40c7187fc8D644d1aC9Bae0805f85	Canonical Timelock, owns nothing.
AereGovLockV2 (govAERE)	0x547F58B087BEbB1746d6159070E755b868C27731	Canonical vote source.
AereStakedGovVotes (original gAERE)	0xD7575795A055cb093957B86f0607871A2D37805C	Deprecated ERC20Votes adapter.
AereThresholdAccountFactory (live V1)	0xf8fCC337d7749Ff2935D755C5F3934e2B70779E8	Duplicate-key finding; 0 accounts; superseded.
Account factory V2 (fixed)	not on mainnet	Founder-gated redeploy. [VERIFY: 0x69734E4044B1C5943B9256A73De41B101BFA2633 recorded in a session note, not confirmed on-chain; treated as not deployed.]
AereThresholdPQCRegistry V1 (buggy)	0x9a6096F6FB3a7E54cF70DE12Cb3903Ae79D1C213	0 committees; superseded.
AereThresholdPQCRegistry V2 (fixed)	0x8Fbfe1C72E8c83ca2a0c475ce3648D47bCC8643c	Deployed and live, inert.
AereThresholdRegistry (ECDSA sibling)	0x875BA0dbA1806Ad9aE57627d705ecA12139D1EF4	Classical threshold-ECDSA, not post-quantum.
AerePQCAccount_sample	0xa42a5e7F72E46BadC11367650Ec34D676194326f	Falcon-512-owned; Solidity-verifier EIP-1271 path.
AereFalcon512Verifier (Solidity)	0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC	~10.5M-gas view verifier; the precompile is the cheap path.
AerePQCKeyRegistry	0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691	Proof-of-possession key binding on live precompiles.
AerePQCAttestation	0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A	Reference pattern: on-chain precompile-verified, domain-separated, replay-protected.
AereGovernorV2Timelock guardian (design)	to be an AereThresholdAccount	Minted by the fixed factory V2 once founder-gated redeploy occurs.

Source files: aerenew/contracts/contracts/mpc/AereThresholdAccount.sol, aerenew/contracts/contracts/mpc/AerePQCThreshold.sol, aerenew/docs/GOVERNANCE.md, aerenew/docs/AERE-ENGINEERING-SECURITY-SPEC.md, aerenew/docs/AUDIT-FINDING-THRESHOLD-DUPLICATE-KEYS-2026-07-15.md, aerenew/sdk-js/src/addresses.ts.