Account Abstraction

Objective

Account abstraction enables users to customize how transactions from their account are authorized. This flexibility supports alternative signing methods, multi-signature requirements, and account recovery mechanisms. Examples include:

• Alternative Signing Methods Passkey, YubiKey, or TouchID to sign transactions directly in the browser without extensions like MetaMask.

• Multi-Signature Wallets Requiring multiple signatures before a transaction can be executed.

• Social Recovery Allowing a group of trusted contacts to override or replace the account’s controlling key.

Solution

ERC-4337 introduces a framework where user wallets are implemented as smart contracts. This allows the wallet’s transaction authorization logic to be fully customizable. Transactions are sent as UserOperations and processed according to the smart account’s rules.

EIP-7702 extends this flexibility by allowing a regular externally owned account (EOA) with a standard ECDSA private key to deploy a smart contract directly into its account. Once a smart account implementation is deployed, the user can send transactions in two ways:

1. Regular Transactions Signed with their private key.

2. UserOperations Authorized according to the custom logic defined in their smart account.

Example Authorization Logic Options

1. Passkey / YubiKey / TouchID [account-abstraction-webauthn]

   • Signs UserOperations directly in the browser, without extensions like MetaMask.

   • Currently a research project—experimental and not recommended for production.

2. Google OAuth JWT signing [solidity-based-social-auth]

   • Signs UserOperations in the browser without MetaMask.

   • Requires publishing the user’s email and account name as part of the JWT on-chain.

   • Relies on an on-chain oracle to provide Google’s current public key (JWKS, rotated every 48 hours).

   • Gas-expensive; suitable for social recovery but not optimal for everyday use.

3. n-of-m signature requirements via Web3Auth

   • Supports conventional social login (e.g. Google account plus additional factors).

   • Depends on the trustworthiness of the third-party service (Web3Auth servers).

4. Social Recovery (ERC-7093)

   • Allows the account owner to designate “guardians” who can replace the owner key.

   • ERC-7093 is currently a proposal without a reference implementation.

   • For EIP-7702 smart accounts, the ability to send regular transactions signed with the account’s private key remains unaffected.