aere-research/research/specs/spec-account-abstraction.md

# AERE Account Abstraction and Onboarding Stack

**Chain:** AERE Network, chain ID 2800 (`0xAF0`)
**Consensus:** Hyperledger Besu QBFT, 0.5-second target blocks, sub-second finality, seven validators
**EVM ruleset:** Pectra (Prague/Cancun) plus Fusaka (Osaka), functional parity with Ethereum mainnet
**Source of truth for addresses:** `aerenew/sdk-js/src/addresses.ts`
**Contract source:** `aerenew/contracts/contracts/`

This document specifies the wallet and onboarding layer of AERE: passkey smart accounts, the ERC-4337 EntryPoint, the four gasless paymasters, EIP-7702 EOA delegation, the ERC-7579 modular account line, ERC-6551 token-bound accounts, and the post-quantum smart account. It states plainly what is live on mainnet 2800 today, what is source-complete but not yet deployed, and where the current design has seams. Honesty about the seams is deliberate: this is an engineering reference, not marketing copy.

---

## 1. Substrate: what the chain gives the wallet layer

Two hardfork features do the heavy lifting for account abstraction on AERE.

**RIP-7951 secp256r1 (P-256) precompile at `0x100`.** Fusaka activated at unix `1780220351`, block `2,106,606`. From that block onward the P-256 verification precompile is unconditionally present at address `0x100`. It takes a 160 byte input (`msgHash || r || s || x || y`, five 32 byte words) and returns a 32 byte word whose low bit is set on a valid signature. Per the registry notes the fixed cost is roughly 3,450 gas, versus roughly 250,000 gas for a pure-Solidity P-256 verification. This is what makes native passkey (WebAuthn) signatures affordable to check on chain, so a user's Face ID, Touch ID, Windows Hello, Android biometric, YubiKey, or EU Digital Identity Wallet key can directly authorize account operations with no seed phrase.

**EIP-7702 EOA delegation (Pectra).** An existing externally owned account can sign a 7702 authorization tuple that makes its account temporarily execute a designated contract's deployed bytecode, while remaining controlled by the original secp256k1 key. AERE uses this to upgrade a plain MetaMask style EOA into a batching, session-key, passkey-capable account without moving funds to a new address.

One substrate constraint shapes the account designs below. AERE's own EntryPoint keeps a strictly sequential, single-dimension per-sender nonce in its own storage (no 2D nonce keys of the kind canonical ERC-4337 v0.7 uses for validator routing). Accounts that want to route between multiple validators therefore cannot encode the route in a nonce key, and instead route on a signature prefix byte. This is called out explicitly in the modular account (Section 6).

---

## 2. Passkey smart accounts (live)

The passkey account is a smart contract wallet whose owner set can be WebAuthn P-256 keys, plain EOA keys, or a mix. It is the production onboarding path for "no seed phrase" users.

### 2.1 Components and addresses

| Component | Address (chain 2800) | Status |
|---|---|---|
| `AereEntryPointV2` | `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770` | Live |
| `AerePasskeyAccountFactoryV2` | `0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA` | Live (canonical) |
| `AerePasskeyAccountFactory` (V1) | `0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739` | Legacy, retained for the original demo account |

Source: `contracts/passkey/AerePasskeyAccountV2.sol`, `MultiOwnable.sol`, `WebAuthn.sol`, `AerePasskeyAccountFactoryV2.sol`.

### 2.2 WebAuthn verification (`WebAuthn.sol`)

`WebAuthn.verify` is a precompile-only port adapted from Coinbase's `base-org/webauthn-sol` library. Given the 32 byte challenge, a `requireUV` flag, the parsed `WebAuthnAuth` assertion, and the public key `(x, y)`, it:

1. Rejects malleable signatures (`s > n/2`, guarding against the secp256r1 curve order half).
2. Confirms `clientDataJSON` contains `"type":"webauthn.get"` at the declared `typeIndex`.
3. Reconstructs `"challenge":"<base64url(challenge)>"` and confirms it appears at `challengeIndex`, binding the signed browser payload to the on-chain challenge.
4. Checks the authenticator data flags: User Present always, User Verified when `requireUV` is set (the passkey account passes `requireUV = true`, so a biometric or PIN gesture is required, not a bare presence tap).
5. Computes `sha256(authenticatorData || sha256(clientDataJSON))` and calls the `0x100` precompile.

The FreshCryptoLib fallback path present in the upstream library is stripped, because the precompile is guaranteed on AERE from the Fusaka block.

### 2.3 Ownership model (`MultiOwnable.sol`)

Owners are stored as raw bytes: 32 bytes for an EOA (a `uint160` address left-padded, top 12 bytes must be zero) or 64 bytes for a P-256 public key (`x || y`). Each owner has a monotonic index that is never reused. The authorization gate is a self-call check: `onlyOwner` requires `msg.sender == address(this)`. That means every owner-management action (add EOA owner, add passkey owner, remove owner) must arrive as an authenticated self-call through one of the account's execute paths. Any single registered owner can add or remove other owners, and the set can never be emptied (`removeOwnerAtIndex` reverts `LastOwner` at count 1).

This is the account's recovery model in its live form: keep at least one owner, and optionally pre-register a backup key (for example a hardware EOA) so loss of the primary passkey does not lose the account. A guardian-and-timelock recovery flow is a separate module and lives in the in-development ERC-7579 line (Section 6), not in the passkey account itself.

### 2.4 Authorization paths (`AerePasskeyAccountV2.sol`)

The account exposes three ways to authorize a call, all resolving through the same `_verifyWrappedSignature` routine that selects the owner by index and dispatches to ECDSA recovery (EOA owners, EIP-191 personal_sign envelope, MetaMask compatible) or WebAuthn (passkey owners):

- **ERC-4337 path.** `validateUserOp` is callable only by the account's `entryPoint`. It verifies the wrapped signature over `userOpHash`, returns `0` on success or `1` (`SIG_VALIDATION_FAILED`) on failure per spec (it does not revert on a bad signature), and forwards any `missingAccountFunds` prefund to the EntryPoint. Execution is dispatched by `executeFromEntryPoint` / `executeBatchFromEntryPoint`, both EntryPoint-gated.
- **Direct passkey path.** `executeWithPasskey` / `executeBatchWithPasskey` let the Foundation relayer (or the user self-relaying) drive the account without a bundler. The signer signs a domain-separated `getExecuteChallenge` that binds `address(this)`, `block.chainid`, a monotonic `passkeyNonce`, and the call payload, giving replay protection independent of the EntryPoint nonce.
- **EIP-1271.** `isValidSignature` wraps the queried hash in an `AereAccount1271(address account,uint256 chainid,bytes32 hash)` digest before verifying, preventing cross-account signature replay. This makes the account usable with Permit2, OpenSea, Snapshot, and dapp login flows.

### 2.5 Deployment (`AerePasskeyAccountFactoryV2.sol`)

A CREATE2 factory. `predictAddress(initialOwners[], salt)` returns the counterfactual address; the initial owner set is mixed into the salt, so the same passkey with a different initial owner set produces a different address and multi-owner accounts cannot be front-run at their counterfactual address. `createAccount` is idempotent (returns the existing account if already deployed) and pins every new account to the factory's immutable `defaultEntryPoint`.

---

## 3. ERC-4337 EntryPoint (live) and an honest note on two EntryPoints

AERE ships two EntryPoint contracts, and the distinction matters for anyone integrating.

**`AereEntryPointV2`** at `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770` (source `contracts/passkey/AereEntryPointV2.sol`) is the account-facing EntryPoint. It implements the canonical `handleOps(PackedUserOperation[], beneficiary)` flow: a validation phase that calls `account.validateUserOp` for every op and reverts the whole batch on any non-zero return, then an execution phase that calls `sender.call(op.callData)`, meters gas, and charges the paymaster's deposit if `paymasterAndData` names one, else the account's own deposit. It computes the canonical v0.7 `userOpHash` (binding the op fields, `address(this)`, and `block.chainid`), keeps per-account deposits, and emits standard `UserOperationEvent` records so bundlers and indexers can subscribe. AERE hosts its own relayer while bootstrapping; the contract is shaped so external bundlers (Pimlico, Stackup, ZeroDev) can target it via per-chain config.

**`AereEntryPoint`** at `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2` (source `contracts/paymaster/AereEntryPoint.sol`) is a lightweight, paymaster-oriented EntryPoint from the Tier-1.3 stack. It implements the deposit and stake surface (`depositTo`, `balanceOf`, `withdrawTo`, `addStake`, `unlockStake`, `withdrawStake`) plus a `relayUserOp` that calls a paymaster's `validatePaymasterUserOp`, executes the sender call, and deducts the paymaster's deposit.

Two honest consequences of this split:

1. **The four paymasters bind to the staking-capable EntryPoint interface.** `PaymasterBase` (Section 4) declares an `IEntryPoint` with `addStake` / `unlockStake` / `withdrawStake`. `AereEntryPointV2` exposes deposit accounting but not staking, whereas the lightweight `AereEntryPoint` implements the full stake surface. The paymaster validation hook (`validatePaymasterUserOp`) is therefore exercised through the lightweight EntryPoint's `relayUserOp` path or through an off-chain relayer that calls the hook directly.

2. **`AereEntryPointV2.handleOps` charges a paymaster's deposit but does not itself call `validatePaymasterUserOp`.** It reads the paymaster address from `paymasterAndData[0:20]` and debits that deposit for `actualGasUsed * maxFee`, but the paymaster's own policy checks (per-sender caps, token pull, quota) are not invoked inside `handleOps`. Unifying paymaster validation into `handleOps` (so a single EntryPoint runs both account and paymaster validation in one batch) is a roadmap item. Until then, gasless sponsorship runs through the relayer-plus-lightweight-EntryPoint path where the hook is actually called.

Also note `handleOps` charges `actualGasUsed * maxFee` (the max fee, not an effective basefee-plus-tip price) and does not implement the full canonical prefund-and-refund economics. It is a compatible subset sufficient for the hosted relayer, not a byte-for-byte reimplementation of eth-infinitism v0.7.

---

## 4. The four gasless paymasters (live)

All four inherit `PaymasterBase` (`contracts/paymaster/PaymasterBase.sol`), an in-house `Ownable` (OpenZeppelin v4.9) base that exposes `validatePaymasterUserOp` / `postOp` guarded by `onlyEntryPoint`, plus deposit and stake helpers. Each paymaster overrides `_validatePaymasterUserOp` with its own sponsorship policy. "Gasless" here means the user needs no native AERE: either the Foundation, a dApp, the user's stake, or an ERC-20 covers the gas.

### 4.1 Address map

| Paymaster | Address (chain 2800) | Status |
|---|---|---|
| `AereOnboardingPaymaster` | `0x4058E406475Dbed7056Aee0c808f293F05fEa879` | Live |
| `AereAppPaymasterFactory` | `0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0` | Live (permissionless factory) |
| `AereTokenPaymasterV2` | `0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243` | Live (canonical) |
| `AereStakeQuotaPaymasterV2` | `0xE50464ca7E8E7F542D1816B3172a2330cFE384E8` | Live (canonical) |
| `AereTokenPaymaster` (V1) | `0xEb6e2Eb24e597C85392DdCD68a1F9b654FffdcB2` | Deprecated, do not use |
| `AereStakeQuotaPaymaster` (V1) | `0xD16C86D792444c2667A26dB62f01b90FC0DaB87b` | Deprecated, do not use |

### 4.2 `AereOnboardingPaymaster` (Foundation-funded)

The first-touch paymaster. It sponsors a hard-capped number of UserOps per address (`sponsoredOpsPerSender`, default 3, lifetime, never resets) under a sitewide per-UTC-day cap (`dailySitewideCap`, default 100) for Sybil resistance, with an optional target-contract whitelist. When its Foundation-funded balance drains it refuses all ops until a governance top-up. The design intent recorded in source is that 3 sponsored ops per address plus a sitewide daily cap lets a fixed, small AERE budget onboard a large number of first-time users without an automated refill.

### 4.3 `AereAppPaymaster` via `AereAppPaymasterFactory` (dApp-funded)

Any dApp calls `createPaymaster()` on the factory (no fee, permissionless) and becomes owner of its own `AereAppPaymaster`. The dApp funds it from its own treasury and sets a required target whitelist, an optional sender allowlist, and an optional per-sender lifetime cap. The Foundation contributes nothing. This is the standard pattern for a game, marketplace, or app to sponsor its own users' gas.

### 4.4 `AereTokenPaymasterV2` (pay gas in an ERC-20)

Lets a user pay for gas in any whitelisted ERC-20 rather than native AERE. It reads the token's USD price and the AERE/USD price from an oracle, converts the op's AERE cost to a token amount, applies a markup in basis points (`markupBps`, default 500 = 5%, capped at 3000), and pulls the tokens via `transferFrom` (the user pre-approves). V2 fixes a V1 medium-severity bug: V1's `withdrawToken` used `transferFrom(address(this), ...)`, which needs a self-allowance that never exists, permanently stranding collected token revenue; V2 uses `transfer`, the correct primitive for moving the contract's own balance, so the Foundation can sweep collected fees. Honest dependency: the paymaster's oracle reference is immutable and, per the registry, currently resolves to the legacy price source; repointing it to `AereOracleV2` requires a fresh paymaster deploy.

### 4.5 `AereStakeQuotaPaymasterV2` (stake AERE, get free transactions)

A Tron-style UX: a user's effective AERE stake buys a daily quota of sponsored UserOps (`quotaPerDay = stakedAERE * txPerKiloAerePerDay / 1000`, default 20 free ops per 1000 AERE staked, resetting each UTC day, no rollover). Effective stake is the sum of delegated stake across the validator set, the user's own validator self-stake, and active locked-staking positions. V2 fixes two confirmed high-severity liveness bugs in V1: V1 called a non-existent `balanceOf` on the real staking contract (so the delegated read always returned 0), and V1 decoded `AereLockedStaking.getLock` with the wrong field order (so any real lock hard-reverted validation and the user could never be sponsored). V2 reads the real public getters and aggregates them, matches the real `getLock` field order (amount first), bounds both scan loops at 100 entries so validation cannot be griefed out of gas, and wraps every external read in try/catch so a paused source degrades the quota to 0 rather than bricking validation. It reads the canonical `AereStakingV2` (`0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC`) and `AereLockedStaking` (`0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad`) getters.

---

## 5. EIP-7702 EOA delegation (live)

For users who already hold a MetaMask style EOA and do not want a new address, EIP-7702 lets that EOA point its delegation tuple at a shared implementation and gain smart-account behavior in place.

| Component | Address (chain 2800) |
|---|---|
| `AereDelegate7702` | `0x5673D92080efbd0987402E9335c14200d0a5EaeF` |
| `AereDelegationRegistry` | `0x6c25c07D134713b6C2F8E19D807423f022903D63` |

**`AereDelegate7702`** (`contracts/delegation/AereDelegate7702.sol`) is the code an EOA delegates to. Because EIP-7702 transmits only code, not storage, every EOA delegating to this one implementation gets independent storage at its own account, and can re-point its delegation at any time with no migration. Its surface:

- `executeBatch(Call[])`: atomic multicall, authorized by the EOA's own transaction signature. The owner check is `msg.sender == address(this)`, which under 7702 is the EOA acting on itself. A transient reentrancy guard protects the batch path.
- `executeWithPasskey(Call, P256Signature)`: a single call authorized by a registered WebAuthn passkey, verified through the `0x100` precompile, with a relayer paying gas. A round-3 fix binds the signed `clientDataJSON` to the specific call by recomputing the expected challenge `keccak256(address(this), passkeyNonce, call)`, base64url-encoding it, and requiring the canonical `"challenge":"<expected>"` substring, which closes a replay hole where an unrelated WebAuthn login signature could have authorized arbitrary calls. A `passkeyNonce` gives replay protection.
- `addSessionKey` / `revokeSessionKey` / `executeWithSessionKey`: register a scoped secondary key with an expiry and a selector allowlist for low-risk, popup-free dApp flows, plus a kill switch.
- `setPasskey(x, y)`: register one WebAuthn key. Phase 1 supports a single passkey; the source notes a Phase 2 extension to a MultiOwnable-style set is planned.

**`AereDelegationRegistry`** is a purely informational, permissionless index: an EOA self-registers (`register()`), the registry records the account's delegated code hash and timestamps, and dApps query it to render a "smart-wallet enabled" badge, discover batch-eligible EOAs, and coordinate paymaster eligibility. It holds no funds and has no authority over any account; wrong data only affects the registrant's own UX.

---

## 6. ERC-7579 modular accounts, session keys, social recovery (in development, not yet on mainnet)

A modular account line exists in source but is **not present in the canonical registry (`addresses.ts`) and is therefore not deployed to mainnet 2800**. It is documented here as the intended next-generation account, marked in-development. No mainnet address is cited because none exists yet.

Source files: `contracts/modular/AereModularAccount.sol`, `AereModularAccountFactory.sol`, `AereSessionKeyValidator.sol`, `AereSessionKeyValidatorV2.sol`, `AereSocialRecoveryModule.sol`.

**`AereModularAccount`** is an ERC-4337 account with ERC-7579-style pluggable modules of two types: validators (type 1, signature validation) and executors (type 2, may call `executeFromExecutor` and `setRootOwner`). It targets `AereEntryPointV2` exactly, and because that EntryPoint uses a single-dimension nonce, the account routes validation on the first signature byte: `0x00` selects the root-owner ECDSA fallback (`0x00 || 65-byte sig` over the EIP-191 envelope), `0x01` selects an installed validator module (`0x01 || 20-byte validator address || payload`). Validators return the canonical 4337 validation-data packing (`authorizer | validUntil<<160 | validAfter<<208`); since `AereEntryPointV2` reverts on any non-zero return and cannot unpack time bounds, the account unpacks the packing itself, enforces the time window against `block.timestamp`, and returns strictly `0` or `1`. It supports `execute` / `executeBatch`, EIP-1271 with the same domain-wrapping convention as the passkey account, and root-owner rotation gated to a self-call or an installed executor.

**`AereSessionKeyValidator` / `AereSessionKeyValidatorV2`** (ERC-7579 type 1) grant a session key a window (`validAfter`, `validUntil`), a per-op native value cap, and an allowlist of `(target, selector)` pairs, with `0x00000000` as the native-transfer sentinel. V2 is a hardened redeploy of the module logic that fixes a confirmed per-batch value-cap bypass (V1 checked each `executeBatch` sub-call's value independently against the per-op cap with no running sum, so a session key could move `maxValuePerOp * N` in one batch); V2 caps the sum of sub-call values, adds a defense-in-depth rule that a session key can never call account-admin selectors (`installModule`, `uninstallModule`, `setRootOwner`, `execute`, `executeBatch`) back into its own account regardless of the allowlist, and adds an optional rolling cumulative spend cap.

**`AereSocialRecoveryModule`** (ERC-7579 type 2 executor) is the guardian-based recovery the live passkey account lacks. An M-of-N guardian set, per account, drives an `initiateRecovery` then `supportRecovery` flow; after a 48 hour timelock and at least the threshold approvals, any guardian may `executeRecovery`, which calls `account.setRootOwner`. The current owner or the account can `cancelRecovery` at any time before execution. Guardian and threshold changes are owner-only (they require `msg.sender == account`).

When this line is audited and deployed, its addresses will be added to `addresses.ts` and this section updated to "live".

---

## 7. ERC-6551 token-bound accounts (live)

ERC-6551 gives every NFT its own wallet. These are account and registry primitives, not tokens: they mint nothing and have no supply.

| Component | Address (chain 2800) |
|---|---|
| `ERC6551Registry` | `0x7fFdA0AcDeB919938dB91dbEa779D841c833EF68` |
| `AereTokenBoundAccount` | `0xBc5e24180f3F75DC6b1965E4aaD3D4F184b6F9E2` |

**`ERC6551Registry`** (`contracts/tokenbound/ERC6551Registry.sol`) is the verbatim `erc6551/reference` registry: a stateless, owner-less CREATE2 factory that deploys deterministic ERC-1167 minimal-proxy accounts bound to a `(chainId, tokenContract, tokenId)` tuple. The source notes the canonical public deployment lives at `0x000000006551c19487814612e58FE06813775758` on chains that received the deterministic Nick-factory deploy; on AERE the identical source was deployed at the address above (the address differs only because the deterministic factory salt was not replayed here, the bytecode and behavior are identical).

**`AereTokenBoundAccount`** (`contracts/tokenbound/AereTokenBoundAccount.sol`) is the implementation the proxies point at. Its sole authority source is `ownerOf(tokenId)` on the bound ERC-721, read live. Whoever holds the NFT controls the account: they can `execute` arbitrary calls (operation 0, CALL only; DELEGATECALL and CREATE are rejected so the account can never be hijacked into changing its own logic), and the account produces EIP-1271 signatures on their behalf via OpenZeppelin `SignatureChecker` (so both EOA and smart-contract holders work). It also implements the ERC-4337 path against `AereEntryPointV2` (hardcoded as `ENTRY_POINT`), so a bundler or paymaster can sponsor the NFT wallet's gas. A live demo binds `AereNFT` (`0x3f9A9D9CAB005327869396C69bE226ef98039f1c`) token #1 to account `0x82D24cC4E09CaBfD9B00233438B8B6321CBC13Dd`.

---

## 8. Post-quantum smart account (live, roadmap #270)

The most experimental account in the stack, and the one whose scope needs the most careful statement. It is a working ERC-4337 v0.7 account whose sole owner is a NIST Falcon-512 lattice public key, with no classical ECDSA fallback.

| Component | Address (chain 2800) |
|---|---|
| `AerePQCAccountFactory` | `0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58` |
| `AerePQCAccount_sample` | `0xa42a5e7F72E46BadC11367650Ec34D676194326f` |
| `AereFalcon512Verifier` | `0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC` |

**`AerePQCAccount`** (`contracts/pqc/AerePQCAccount.sol`) owns exactly one Falcon-512 public key (897 bytes, NIST encoding, header byte `0x09`). Every authorization, a bundled UserOperation, an EIP-1271 check, or the direct `executeWithFalcon` path, is decided by the live on-chain `AereFalcon512Verifier`, which runs real lattice cryptography: SHAKE256 HashToPoint, 14-bit public-key decode, compressed-signature decode, negacyclic NTT multiply mod q=12289 in the ring, centering, and an l2-norm bound check. The signature envelope is `abi.encode(bytes nonce, bytes compSig)` (the 40-byte Falcon salt and the compressed s2 body); the message handed to the verifier is the raw 32 bytes of the relevant hash, which for a UserOperation is the userOpHash that already binds sender and chain. `validateUserOp` returns `0` or `1` per spec; `isValidSignature` is a `view`, so integrators can verify a post-quantum signature for free via `eth_call`. `AerePQCAccountFactory` is a CREATE2 factory keyed on `(falconPubKey, salt)`, mirroring the passkey factory, binding each account to an immutable EntryPoint and Falcon verifier.

**Honest scope, stated exactly as the registry frames it.** This is Falcon-512 (NIST security level 1), not Falcon-1024. A Falcon-512 verify is heavy: roughly 10.5M gas per PQC authorization. That is real and it fits under the Fusaka EIP-7825 per-transaction cap of 2^24 = 16,777,216 gas, and a full UserOperation through `AereEntryPointV2.handleOps` was demonstrated end-to-end with estimated 10,641,716 and measured 10,278,313 gas used, under the cap, `opSuccess=true`. A native SHAKE or keccak precompile would cut this sharply and is tracked as a separate roadmap item. PQC authorization here is app-layer and account-layer: it secures how this account authorizes operations. It does not change consensus. AERE's validators sign classical QBFT, and the native PQC precompiles that would make lattice verification cheap are proposed and in development on a scratch fork, not live on mainnet 2800. On the broader PQC verifier suite that this account draws on, we are not aware of any other public chain that verifies all of these on-chain; that is the claim, stated with that exact hedge, and nothing stronger.

---

## 9. Honest limitations

This layer is real and on chain, but a credible reader should weigh it against the following, all true today.

- **Decentralization.** AERE runs seven QBFT validators under one operator, one client (Besu), with no external security audit of these contracts and thin real-world usage. The wallet layer inherits that trust profile. Sponsorship and relaying currently depend on a Foundation-hosted relayer.
- **Two EntryPoints, one seam.** As described in Section 3, the account-facing `AereEntryPointV2` and the paymaster-facing lightweight `AereEntryPoint` are distinct, and `handleOps` charges but does not itself invoke the paymaster validation hook. Gasless flows run through the relayer-plus-lightweight-EntryPoint path. Unifying the two is a roadmap item.
- **EntryPoint economics are a subset.** `AereEntryPointV2` uses `maxFee` for gas charging and does not implement full canonical prefund-and-refund. It is sufficient for the hosted relayer, not a drop-in reimplementation of eth-infinitism v0.7.
- **Recovery.** The live passkey account's recovery is "keep at least one owner / add a backup owner". Guardian-and-timelock social recovery is source-complete in the ERC-7579 line but not yet deployed (Section 6).
- **ERC-7579 modular line is not live.** The modular account, its factory, both session-key validators, and the social recovery module are in-development. They carry no mainnet address and must not be presented as deployed.
- **Post-quantum cost.** The Falcon-512 account is genuinely quantum-resistant at the account layer but costs roughly 10.5M gas per authorization and is level 1, not 1024. It is a real primitive with a heavy price, pending a SHAKE precompile.
- **Deprecated contracts remain on chain.** The V1 token and stake-quota paymasters, and the V1 passkey factory, are retained at their addresses; integrators must point at the canonical V2 addresses listed above.

---

## 10. Address appendix (verbatim from `addresses.ts`)

**EntryPoints**
- `AereEntryPointV2` (accounts): `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770`
- `AereEntryPoint` (lightweight, paymaster relay): `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2`

**Passkey wallets**
- `AerePasskeyAccountFactoryV2`: `0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA`
- `AerePasskeyAccountFactory` (V1, legacy): `0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739`

**Paymasters**
- `AereOnboardingPaymaster`: `0x4058E406475Dbed7056Aee0c808f293F05fEa879`
- `AereAppPaymasterFactory`: `0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0`
- `AereTokenPaymasterV2`: `0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243`
- `AereStakeQuotaPaymasterV2`: `0xE50464ca7E8E7F542D1816B3172a2330cFE384E8`
- `AereTokenPaymaster` (V1, deprecated): `0xEb6e2Eb24e597C85392DdCD68a1F9b654FffdcB2`
- `AereStakeQuotaPaymaster` (V1, deprecated): `0xD16C86D792444c2667A26dB62f01b90FC0DaB87b`

**EIP-7702**
- `AereDelegate7702`: `0x5673D92080efbd0987402E9335c14200d0a5EaeF`
- `AereDelegationRegistry`: `0x6c25c07D134713b6C2F8E19D807423f022903D63`

**ERC-6551**
- `ERC6551Registry`: `0x7fFdA0AcDeB919938dB91dbEa779D841c833EF68`
- `AereTokenBoundAccount`: `0xBc5e24180f3F75DC6b1965E4aaD3D4F184b6F9E2`
- Demo NFT (`AereNFT`): `0x3f9A9D9CAB005327869396C69bE226ef98039f1c`
- Demo bound account: `0x82D24cC4E09CaBfD9B00233438B8B6321CBC13Dd`

**Post-quantum account**
- `AerePQCAccountFactory`: `0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58`
- `AerePQCAccount_sample`: `0xa42a5e7F72E46BadC11367650Ec34D676194326f`
- `AereFalcon512Verifier`: `0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC`

**Supporting**
- `AereStakingV2`: `0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC`
- `AereLockedStaking`: `0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad`
- Foundation (owner of all `Ownable` contracts): `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`

**In development, no mainnet address (ERC-7579 modular line):** `AereModularAccount`, `AereModularAccountFactory`, `AereSessionKeyValidator`, `AereSessionKeyValidatorV2`, `AereSocialRecoveryModule`.