Account abstraction (ERC-4337) - smart wallets, gas sponsorship and access recovery
What account abstraction and ERC-4337 are: UserOperation, bundler, paymaster, smart-wallet advantages over an EOA, social recovery and the risks.
In this article
An ordinary wallet (EOA) is rigidly built: one private key, gas only in ETH, lose the key - lose everything (Ethereum accounts). Account abstraction turns a wallet into a programmable contract to which you can give your own rules. The ERC-4337 standard implements this without changing the Ethereum protocol itself.
Problems of an ordinary wallet
- One key = a single point of failure (HD wallets).
- Any operation needs ETH for gas, even if you only hold USDC.
- Every action is a separate signature and transaction (approve, then swap).
- You cannot set limits, add a delay or allow temporary access.
- Access can be recovered only through the seed phrase.
The smart wallet
Instead of an EOA, a contract wallet is used. Its rules are code: who and how can sign, what the limits are, who can recover access. A multisig is a special case of a smart wallet.
The problem is that a contract cannot initiate a transaction itself (only an EOA can). ERC-4337 solves this with separate infrastructure.
How ERC-4337 works
Instead of an ordinary transaction the user creates a UserOperation - a structure describing the desired action. Then:
- The UserOperation is sent to a separate "alternative mempool".
- A bundler collects operations into one ordinary transaction and pays its gas.
- The transaction calls the EntryPoint - a single dispatcher contract.
- The EntryPoint calls the smart wallet's validation function
validateUserOp: are the signature and rules right? - If so, it performs the action. The bundler is compensated from the wallet's funds or a paymaster.
User → UserOperation → Bundler → EntryPoint → Smart wallet → Action
↑
Paymaster (optional)The paymaster: gas without ETH
A paymaster is a contract that pays gas for the user. Variants:
- an application sponsors gas for newcomers: a "free" first experience;
- the user pays the fee in a token (for example USDC) and the paymaster converts;
- an organisation pays for its employees.
For services like ours this potentially lowers the entry barrier: no need to hunt for ETH first for the first operation (choosing a network).
What smart wallets can do
| Capability | What it gives |
|---|---|
| Social recovery | trusted people or devices help regain access if a key is lost |
| Batched operations | approve and the call in one operation instead of two (approve) |
| Session keys | a temporary limited key for a game or app |
| Limits and delays | a daily maximum, a pause on large transfers |
| Passkeys | signing with a device's biometrics (the secp256r1 curve) instead of a seed phrase |
| Multiple keys | several devices, 2-of-3 and so on |
| Swappable signature algorithm | to a post-quantum one in the future |
Verifying a smart wallet's signature is based on EIP-1271 (signatures).
The link with EIP-7702
The Pectra upgrade (2025) added EIP-7702: an ordinary address (EOA) can temporarily "attach" contract code and gain smart-wallet abilities (batching, sponsorship) without moving to a new address. This complements ERC-4337 rather than replacing it.
Risks and limitations
- Wallet bugs. A smart wallet is a contract, and a bug in it can cost money (catalogue of vulnerabilities). Use proven, audited implementations.
- Dependence on infrastructure. A bundler and paymaster can refuse, delay or censor operations.
- Complexity. More parts means more bugs and extra gas for validation.
- Different addresses across networks. A smart wallet's address may differ between networks if deployed differently (CREATE2).
- Social recovery adds new "guardians" who must be trusted.
- Phishing is still possible: a signed operation is a signed operation (attacks).
How this relates to escrow
The Coin-Trust contract accepts calls from any address - an EOA or a smart wallet. So a deal participant can use a smart wallet: for instance, an organisation guarantor with a multisig that issues rulings. An important condition: the address must be able to receive payouts; otherwise the payment turns into a credit that must be claimed separately (credits).
Example
Maria uses a crypto service for the first time. She has a smart wallet with a passkey on her phone and some USDC. The application sponsors the gas for her first deal. In one operation the wallet performs approve and creates the offer. Phone lost? Two of three trusted contacts approve replacing the device, and access is restored without a seed phrase.
What to read next
Let us reinforce security: the wallet protection checklist. Or move on to development and testing: the Foundry tutorial.
Keep reading
- 3 · Under the hood
Signatures in Ethereum - ECDSA, ecrecover, personal_sign and EIP-712
How a signature (r, s, v) is built, how a contract verifies it via ecrecover, how personal_sign and EIP-712 differ, and what permit and EIP-1271 are.
4 min read - 2 · Practice
Multisig and timelock - managing a contract without a single point of failure
What a multisig (m of n) and a timelock are, how wallets like Safe work, which risks they close and which they do not, and how to use them for an owner or guarantor.
4 min read
Mentioned in
- Ethereum accounts and state - EOAs, contracts and the world state
- Signatures in Ethereum - ECDSA, ecrecover, personal_sign and EIP-712
- Gas optimization in Solidity - 12 techniques and when they apply
- Rollups under the hood - batches, fraud proofs, ZK, blobs and withdrawals
- MEV and front-running - who earns from transaction order and how
- HD wallets - how 12 words yield all your keys (BIP-39, BIP-32, BIP-44)
Ready to try it?
Create your first deal in a couple of minutes. The money is locked in a smart contract and paid out by rules you can see in advance.