# AIP-6: ERC-4337 Passkey and Gasless Onboarding Stack ## Preamble | Field | Value | | --- | --- | | AIP | 6 | | Title | ERC-4337 Passkey and Gasless Onboarding Stack | | Author | AERE Foundation | | Type | Standards Track | | Category | ARC | | Status | Final | | Created | 2026-07-11 | | Requires | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract This AIP documents AERE's account-abstraction onboarding stack: ERC-4337-shaped EntryPoints, passkey (WebAuthn / secp256r1) smart accounts that use the Fusaka P-256 precompile, and a set of paymasters that let a new user transact without first holding AERE for gas. It is a retro-filed record of contracts already live on chain 2800. ## Motivation The single hardest step in crypto onboarding is the cold start: a new user needs gas to make their first transaction, but they cannot get gas without already transacting or bridging in. AERE's answer is account abstraction plus paymasters, so a user can create a wallet secured by a device passkey (Face ID, Touch ID, Windows Hello, a security key) and have their first transactions sponsored, with no seed phrase and no pre-funded gas. Fusaka makes the passkey half cheap. Its RIP-7951 precompile at address `0x100` verifies a secp256r1 / P-256 signature natively for a fixed cost of about 3,450 gas, versus roughly 250,000 gas to do the same check in Solidity. That is what makes a passkey-signed userOp economical. ## Specification ### EntryPoints - **AereEntryPoint** at `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2`. A lightweight ERC-4337-compatible EntryPoint used by the paymasters. - **AereEntryPointV2** at `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770`. The current ERC-4337-shaped EntryPoint that the V2 accounts validate against. ### Passkey accounts - **AerePasskeyAccountFactory** at `0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739`. V1, legacy. Single-passkey-owner smart account. Retained for the original demo account. - **AerePasskeyAccountFactoryV2** at `0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA`. V2. Accounts are MultiOwnable (passkey owners and EOA owners), expose an ERC-4337 `validateUserOp` shim and EIP-1271 `isValidSignature`, and support recovery by an existing owner adding a new owner. `predictAddress(initialOwners, salt)` gives the counterfactual address. Signature verification for passkey owners routes through the Fusaka P-256 precompile at `0x100`. ### Paymasters - **AereOnboardingPaymaster** at `0x4058E406475Dbed7056Aee0c808f293F05fEa879`. Foundation-funded sponsorship for cold-start users. Rate-limited to 3 lifetime userOps per sender and a sitewide cap of 100 sponsored userOps per day. This is the "your first few transactions are free" primitive. - **AereAppPaymasterFactory** at `0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0`. A permissionless factory: any dApp clones its own AereAppPaymaster to sponsor its own users on its own budget. - **AereTokenPaymasterV2** at `0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243`. Pay gas in any whitelisted ERC-20 instead of AERE. `withdrawToken` uses `transfer()` so the Foundation can sweep collected gas revenue (the V1 bug that stranded collected tokens is fixed here). - **AereStakeQuotaPaymasterV2** at `0xE50464ca7E8E7F542D1816B3172a2330cFE384E8`. Stake AERE to earn a daily free-transaction quota, a Tron-style UX. It reads the real AereStaking and AereLockedStaking state with bounded loops. These V2 paymasters are the canonical ones; the relayer, website, and SDK point here, not at the deprecated V1 paymasters. ## Rationale The stack follows ERC-4337 rather than inventing a bespoke account model so that existing bundler and account-abstraction tooling transfers directly, and so that accounts are contracts (upgradable ownership, recovery, EIP-1271) rather than raw EOAs. Passkeys were chosen for the owner key because they remove the seed phrase, which is the biggest single cause of self-custody loss, and because Fusaka's native P-256 precompile makes on-chain WebAuthn verification cheap enough to use in every userOp. The V2 accounts are MultiOwnable specifically to provide a recovery path: an existing owner can add a new owner, so losing one device does not brick the account. Multiple paymasters exist because "gasless" means different things in different contexts: a one-time cold-start subsidy (onboarding), a dApp sponsoring its own users (app factory), paying gas in a stable ERC-20 (token paymaster), or earning free transactions by staking (stake-quota). Each is a distinct policy, so each is a distinct, narrowly-scoped paymaster rather than one over-configurable contract. ## Backwards Compatibility None. These are additive contracts. Ordinary EOAs and existing contracts are unaffected. Builders opt in by deploying accounts through the factories and wiring a paymaster. ## Security Considerations - **The EntryPoints are AERE's own implementations.** They are ERC-4337-compatible in shape and interface, not the canonical audited Ethereum ERC-4337 EntryPoint singleton. Integrators should treat them as AERE-specific and not assume byte-level parity with mainnet Ethereum's EntryPoint. - **Gasless is subsidized, not free.** AereOnboardingPaymaster spends Foundation funds. Its 3-per-sender lifetime limit and 100-per-day sitewide cap exist to bound abuse and cost; sponsorship is not an unlimited, permanent entitlement and can be exhausted or turned down. Users past the free tier pay gas normally (in AERE, in a whitelisted ERC-20, or via a stake quota). - **Recovery is owner-mediated.** V2 account recovery works by an existing owner adding a new owner. If all owner devices are lost and no recovery owner was pre-registered, the account is not recoverable. Users should add a backup owner. - **Passkey trust model.** Passkey security depends on the device's secure element and the platform WebAuthn implementation. A compromised device or a platform vulnerability is outside what the contract can defend against. - **Single client, unaudited.** As with the rest of AERE today, this runs on a single client (Besu QBFT) under a small Foundation-operated validator set, and these contracts have not had an external security audit. The V1 passkey account and V1 paymasters had known gaps (V1 was a demo-grade single-owner account with no recovery, and two V1 paymasters had confirmed bugs); V2 closed those, and the V1 contracts are left on-chain but deprecated. New integrations MUST use the V2 addresses. ## Reference Implementation and On-Chain Deployment Sources under `contracts/contracts/passkey/` (accounts, factories, MultiOwnable, EntryPointV2, WebAuthn, P256Probe) and `contracts/contracts/` plus `contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses: - AereEntryPoint `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2` - AereEntryPointV2 `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770` - AerePasskeyAccountFactory (V1) `0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739` - AerePasskeyAccountFactoryV2 `0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA` - AereOnboardingPaymaster `0x4058E406475Dbed7056Aee0c808f293F05fEa879` - AereAppPaymasterFactory `0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0` - AereTokenPaymasterV2 `0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243` - AereStakeQuotaPaymasterV2 `0xE50464ca7E8E7F542D1816B3172a2330cFE384E8` All addresses copied verbatim from `sdk-js/src/addresses.ts`. The Fusaka P-256 precompile at `0x100` (RIP-7951) is active on chain 2800 from the Fusaka activation (unix 1780220351, block 2,106,606). ## Copyright Released to the public domain (CC0). No rights reserved.