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`.