6cb0140fae
The public history carried kat/__pycache__/mlkem768_reference.cpython-314.pyc, a compiled Python artifact embedding the operator's absolute local path. Text secret scanners do not read compiled binaries, which is exactly how it slipped through, and removing it from the tip would have left it reachable through the old root commits. So this repository is republished from a single clean root. This root also carries, from the previously unpublished line of work: - corrected LICENSE year, LICENSING.md, VERIFY-POLICY.md, and CITATIONS-UNRESOLVED.md remeasured 2026-08-11 (101 paths, README aligned) - O-018: run_consensus_verification.py ran 19 of 29 models and reported PASS; it now runs all 29, and computemarket_smt.py gains resolveByTimeout / reclaimUnsettled cases plus a negative control - O-006: the word 'audited' removed from next to Bouncy Castle, twice, after a concurrent edit resurrected it - O-014: prior art named and dated - Algorand's native falcon_verify shipped about ten months before AERE's precompiles; the primacy claim is withdrawn where it was implied - bench/ scripts parametrized so they actually run for an outsider (the earlier textual sanitization left $STAGING unexpanded inside Python strings) - AIP-2/AIP-3 errata with measured figures, spec remeasurements at 2026-08-01, and the spec-zk-stack retractions (owner is an operational key, not the Foundation; 'maximally sound' withdrawn; aggregator V1 deprecated) The redacted bench-host environment files from the sanitized line are kept exactly as published; the unredacted local variants are not carried.
156 lines
7.5 KiB
Markdown
156 lines
7.5 KiB
Markdown
# 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,597).
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|
|
</content>
|