Account Abstraction (ERC-4337): Bringing Familiar UX to Web3

For many people, the hardest part of using a decentralised application is not the application at all. It is managing a seed phrase and holding the right native token to pay transaction fees.

What ERC-4337 changes

ERC-4337 enables smart contract accounts without changes to Ethereum's consensus layer. Users submit UserOperations, bundlers package them into transactions, and a shared EntryPoint contract validates and executes them according to the account's own logic.

Passkeys and flexible signing

Because validation is programmable, an account can accept signatures from WebAuthn passkeys secured by a device's biometrics, use multiple signers, or apply spending limits and session keys for specific applications.

Paymasters

Paymasters allow an application to sponsor transaction fees, or let users pay fees in a token such as a stablecoin. This removes one of the most confusing first steps for new users.

The trade-offs

Smart accounts add gas overhead compared with simple transfers, depend on bundler and paymaster infrastructure, and require careful security review of the account and recovery logic. Signature verification for passkeys can also be costly on networks without dedicated support for the relevant curve.

Where it is heading

EIP-7702, introduced with Ethereum's Pectra upgrade, lets existing externally owned accounts delegate to smart contract code. Together with ERC-4337, it points towards wallets where security and recovery feel familiar to mainstream users.

Our approach

We start from the user journey — sign-up, first transaction, recovery — and choose the simplest account model that supports it, then test the account logic as rigorously as any other contract holding value.