Account abstraction lets smart contract code decide how an Ethereum account approves transactions, instead of one private key being the only rule. A smart wallet uses this to add passkey login, gas sponsorship, batched actions and account recovery. ERC-4337 delivers it through contract accounts and a separate transaction flow. EIP-7702, live since May 2025, lets ordinary key-based addresses borrow contract code while keeping their original key.
EOAs vs. contract accounts
Ethereum has two kinds of account, and their limits explain why account abstraction exists.
| Externally owned account (EOA) | Contract account | |
|---|---|---|
| Controlled by | One private key | Code |
| Cost to create | Free | Costs gas to deploy |
| Can start a transaction | Yes | No, it only reacts to one |
| Lose the key | Funds are gone | Depends on the rules in the code |
Most wallets have traditionally been EOAs. That means one seed phrase is a single point of failure. Whoever has it can do anything, and nobody can recover the account without it.
Contract accounts can have any rules you like, such as two approvals for large transfers. Their problem was the third row: a contract can't start a transaction, so someone with an EOA and some ETH had to kick things off. ERC-4337 solves that problem.
How ERC-4337 works, step by step
ERC-4337 adds account abstraction without changing Ethereum's consensus rules. Its central EntryPoint contract went live on mainnet on March 1, 2023. Instead of a normal transaction, your wallet signs a UserOperation, a transaction-like object describing what you want to do.
- Your wallet builds and signs a UserOperation. It names your account, the calls to make, gas limits and fees, and your signature. The signature can use whatever scheme your account accepts.
- It goes to a separate mempool. This is a waiting area for UserOperations, apart from the normal transaction pool.
- A bundler picks it up. A bundler is a node that simulates the operation, drops it if validation fails, and packs many operations into one normal transaction. The bundler pays the gas for that transaction up front.
- The EntryPoint validates. If your account doesn't exist yet, a factory contract deploys it now. The EntryPoint then asks your account's code to check the signature, and confirms that the fee can be covered.
- The EntryPoint executes. It calls your account with the actions you requested.
- Everyone settles up. Unused gas is refunded, and the bundler is repaid from the collected fees.
Validation runs before execution, which is what lets a bundler avoid paying for operations that would never pay it back.
A bundler can't rewrite your operation, because your signature covers its contents. It can refuse or delay it, though, so having many independent bundlers matters.
Paymasters and gas sponsorship
A paymaster is a helper contract that agrees to pay for a UserOperation, instead of the sender. It keeps a deposit with the EntryPoint. During validation, it decides whether to sponsor you. The standard's stated use cases include apps paying fees for their users and users paying fees in ERC-20 tokens.
Here is a worked example, using illustrative prices of 2 gwei for gas and $3,000 for ETH. A new user holds 100 USDC and no ETH, and wants to make a swap.
- With a plain EOA: They are stuck. They must buy ETH first, then send one transaction to approve the token and another to swap on a decentralized exchange.
- With a smart wallet and paymaster: The user signs once. The approval and swap run as one atomic batch, so both succeed or both fail. The paymaster covers the gas.
Sponsorship isn't free, because someone still pays. Vitalik Buterin's roadmap note puts a basic UserOperation at about 42,000 gas, against 21,000 for a basic transaction. At our illustrative prices, that's about $0.25 rather than about $0.13. This overhead matters less on layer 2s, where gas fees are lower.
What EIP-7702 changed in Pectra
ERC-4337 had one big drawback: existing users had to move their assets to a new account. EIP-7702 removes that step. It activated with the Pectra upgrade on May 7, 2025.
It adds a new transaction type carrying a list of signed authorizations. Each one says "my EOA should run the code at this address." The protocol then writes a short pointer into the account, and calls to that address run the chosen contract's code in the context of your account. Your address and your balances stay the same.
Two details are often misunderstood:
- Delegation isn't temporary. It persists until you change it, and you clear it by delegating to the zero address.
- Your original key still rules. Ethereum.org states that the private key retains full control after delegating. Delegating to a multisig contract doesn't make you a multisig, because a single key can still bypass the policy.
The second point is the one to remember. EIP-7702 adds features, and it can't fix a leaked seed phrase.
The two standards also work together. A delegated EOA can send UserOperations through ERC-4337's bundlers and paymasters.
| Plain EOA | EOA with EIP-7702 | ERC-4337 smart account | |
|---|---|---|---|
| Keeps your address | Yes | Yes | No, new address |
| Batching | No | Yes | Yes |
| Gas sponsorship | No | Yes, through the delegate | Yes |
| Seed phrase still has full power | Yes | Yes | No, the code sets the rules |
| Real recovery from a stolen key | No | No | Possible |
What smart wallets let you do
These are the main features, and each one comes from code rather than from the protocol itself.
- Recovery. In a social recovery design, a daily signing key is backed by a set of guardians: your other devices, friends or institutions. If you lose the key, a majority of guardians approves a new one.
- Gas sponsorship. An app can pay for your transactions, or let you pay in a stablecoin.
- Batching. You can approve and swap in one action, which can also avoid leaving a token approval sitting open.
- Passkeys. Your phone's secure hardware can sign. Ethereum's Fusaka upgrade of December 3, 2025 added a built-in checker for passkey-style signatures, so contracts can verify them natively.
- Limited permissions. You can grant a key narrow rights, such as a daily spending limit. This is also useful for software agents that hold a wallet.
The risks
Smart wallets remove some risks and add others. Here's what can go wrong, with real cases.
Contract bugs
Your wallet is now software, and software has bugs. In November 2017, a flaw in Parity's shared wallet library froze 513,774 ETH across multisig wallets, after a user triggered the bug and disabled the library. No key was stolen.
Phishing through delegation
EIP-7702 gives attackers a new thing to ask you to sign. The delegated code has unrestricted access to the account. One signed authorization with a chain ID of 0 applies on every EVM chain. Wallets are told not to let apps request these signatures, and that's a good rule to apply yourself.
Batching helps attackers too. In May 2025, a victim lost $146,551 after signing a malicious batch that a researcher linked to the Inferno Drainer group. In August 2025, a single user reportedly lost about $1.5 million to a similar scam. Read more on how wallet drainers work.
A figure you may see quoted needs context. In June 2025, Wintermute reported that more than 80% of EIP-7702 delegations pointed to copies of one sweeper contract. Those target wallets whose keys had already leaked, so the number says little about ordinary users of EIP-7702.
A lying interface
Strong account rules don't help if signers can't see what they are approving. In February 2025, about $1.5 billion was stolen from Bybit. Attackers had altered a JavaScript file served by Safe's website, and signers saw what looked like a transfer to the correct address. Safe said its smart contracts were not affected.
Addresses that don't exist on every chain
A smart account's address can be known before it is deployed, and it lives only on chains where it has been deployed. In 2022, the foundation behind Optimism sent 20 million OP to a Wintermute multisig address that existed on Ethereum but not yet on that network. An attacker deployed a multisig to that address first and took control of the tokens. Check before sending funds to a smart account on a new chain.
Dependence on outside services
Bundlers can censor you, and a paymaster can stop sponsoring you, so you may need a fallback way to pay. Guardians can collude, or lose interest over the years. Switching delegates can also leave old storage data that the new contract misreads. For more on this topic, see account abstraction.
Questions to ask before you use a smart wallet
- Who can change the rules? Is the contract upgradable, and by whom?
- Has the code been audited, and how long has it held real money?
- How do I recover, and have I tested it with small amounts?
- Does my original key still have full power? With EIP-7702, the answer is yes.
- What does the wallet show me before signing? You want to see the real target and every call in a batch.
Key takeaways
- Account abstraction replaces "one key controls everything" with rules written in code.
- ERC-4337 uses UserOperations, bundlers, an EntryPoint contract and optional paymasters, with no consensus change.
- EIP-7702, live since May 7, 2025, lets an EOA run contract code at the same address. The delegation lasts until changed, and the original key keeps full control.
- Smart wallets enable recovery, sponsored gas, batching and passkeys, at a higher base gas cost.
- The main risks are contract bugs, phishing for delegations and batches, misleading interfaces and cross-chain address mistakes.
Sources
Get the weekly commit
New blockchain deep dives every week.
