aere-research/aips/AIP-6.md

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.