Engineering · Universal Login

Universal Login on AERE, multi-key wallets, recovery, gasless onboarding

By AERE Network June 1, 2026 6 min read

Tier 1.15 shipped passkey wallets, tap your fingerprint, get an AERE wallet. The audit that followed flagged two SEV-1 gaps: no recovery (lose your phone + iCloud, lose your funds) and no ERC-4337 compatibility (standard bundlers can't sponsor AERE wallets). Today we closed both.

What's new: AerePasskeyAccountV2 with MultiOwnable (multiple keys per account, passkey + EOA + add/remove freely), real ERC-4337 validateUserOp shim, EIP-1271 isValidSignature for DeFi integrations, and a Foundation-funded relayer at aere.network/relay that submits transactions on behalf of users who don't hold AERE yet.

What's deployed

Component	Address on chain 2800
AereEntryPointV2	0x8D6f40598d552fF0Cb358b6012cF4227B86aF770
AerePasskeyAccountFactoryV2	0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA
Account init code hash	0x59b39b48…1dc1
Foundation relayer (HTTP endpoint)	https://aere.network/relay/
Relayer EOA	0x0c8e643510Ee21f72de501FE27F8882C517cdA38

End-to-end test transcript

Every code path was verified on chain 2800. Account 0x2e0757962e72C3e25f7f287907fC9687CE9D956b:

Test	Tx hash	Gas
Deploy multi-owner account (1 passkey + 1 EOA)	0xae18…293a	1,991,894
Execute via passkey (owner idx 0)	0xae18…293a	130,816
Execute via EOA (owner idx 1)	0x2322…ea69	53,592
EIP-1271 isValidSignature → 0x1626ba7e	view call	,
Recovery: passkey adds second passkey via self-call	0xc349…ac2a	,
Execute via newly-added passkey (owner idx 2)	0xf2d8…8b88	113,716

How recovery works

Every owner-management op (addOwnerPublicKey, addOwnerAddress, removeOwnerAtIndex) is gated by onlyOwner which requires msg.sender == address(this). To add an owner, you call account.executeWithPasskey(sig, address(this), 0, addOwnerCalldata), your existing signer authorizes a self-call that adds a new key.

Result: if you have a YubiKey paired with your Touch ID, lose both, but kept an old MetaMask EOA as a third owner, you sign with that EOA and add a fresh passkey from your new phone. Funds preserved.

Why the relayer matters

New users don't have AERE. Without a relayer, they can't deploy their own wallet or send their first transaction. With the Foundation-funded relayer at https://aere.network/relay/:

User taps Face ID → browser creates passkey, computes counterfactual address
Browser POSTs (initialOwners, salt) to /relay/createAccount
Relayer EOA submits factory.createAccount(...) + pays gas (~2M gas, ~0 AERE because min-gas-price=0)
Account is live on chain, ready to receive funds
User signs a transaction with their passkey, browser POSTs to /relay/execute
Relayer submits, transaction lands

The relayer NEVER sees the user's private key. The smart account validates every signature itself, the relayer is just a gas-payer. Compromising the relayer doesn't compromise any user funds; it just halts gasless submission until a new relayer is stood up.

Phase 1 honest limits

Single relayer EOA, no HA. If the relayer goes down, users with their own AERE can still sign + submit directly. New onboarding stalls until it's back.
No rate-limiting, anyone can spam the relayer. Phase 2: Pimlico-style 10 RPS/IP, 100 ops/wallet/day, HMAC-nonced API requests with 60s replay window.
Relayer balance: 2 AERE, that funds thousands of transactions at AERE's zero gas price, but the EOA needs periodic top-ups from Foundation. Phase 2 wires AereOnboardingPaymaster so the paymaster's deposit at the EntryPoint covers gas instead of the relayer EOA.
No external bundler support yet, Pimlico/Stackup/ZeroDev can target our V2 EntryPoint if they configure chain 2800; outreach is Phase 2.

What's next

Tier 1.17, bring external users in. Cross-chain swap UI at bridge.aere.network: swap USDT on Ethereum to AERE on chain 2800 in one click, fund a passkey wallet you created via Touch ID, send your first AERE transaction without any prior interaction with the AERE ecosystem. The pieces are all live; the UX wrapper is the work.

→ Try wallet.aere.network ← Back to all posts