Until now you had to pick: keep your familiar externally owned account (EOA) with its single private key, or migrate to an Account Abstraction (AA) smart wallet such as those built on EIP‑4337. Introduced in the Ethereum Mainnet Pectra upgrade on May 7, 2025, EIP‑7702 removes that fork in the road. It adds transaction type 4 that lets an EOA “borrow” a piece of contract code. In practice that means an address can be used both as an EOA, as well as a smart wallet: batch multiple calls, have someone else pay the gas, enforce custom spending rules, etc.
Account Abstraction is really about user experience: hiding gas fees, reducing the number of clicks, and making account recovery and gas payments in stablecoins possible. ERC-4337 wallets proved the concept, but they require brand new addresses and special infrastructure. EIP-7702 builds on this incrementally without requiring protocol changes or new opcodes. This backwards compatibility also lets an EIP-7702 transaction point to existing ERC-4337 wallet logic, or ride inside a standard ERC-4337 bundle, so blockchain apps and AA bundler can adopt it with minimal code changes.
EOAs vs. ERC-4337 vs. EIP-7702
With an EOA wallet, like MetaMask, the user approves an unsigned transaction created by a blockchain app, typically by clicking some equivalent of “confirm” in the wallet’s user interface. The EOA private key inside of the wallet then signs the transaction, and the wallet submits the signed transaction to the blockchain. The EOA pays all of the gas fees, can execute at most a single transaction, the user has to “be in the loop” to approve the transaction, and care must be taken with the EOA’s private key (usually a seed phrase).
An EOA wallet and transaction
The title of the ERC-4337 standard itself is Account Abstraction Using Alt Mempool. The “alternative mempool” refers to the fact that transactions using ERC-4337 are processed by an off-chain service called a Bundler, that gathers User Operations into an on-chain transaction, and submits them to a canonical Entry Point smart contract for execution. The scheme relies on standard interfaces between the various components, including an on-chain smart wallet that takes the place of the off-chain EOA. The benefits include alternative gas payment schemes and transaction batching, but at the expense of having to deploy a per-wallet smart contract.
The approval step can be more nuanced, in that the wallet is supposedly more aware of the contents of the transaction, and is often tightly coupled with the app, so that a user might provide blanket approval for multiple transactions at once, all transactions below a certain value threshold, etc.
An ERC-4337 wallet and transaction
Wallets with EOAs that support EIP-7702 will ask the user to sign a “set code” authorization that delegates a specified on-chain smart contract to act as that EOA. The authorization stays in place until replaced by another authorization, or revoked by setting the zero address as the delegate. The authorization includes the current nonce of the EOA and the chain ID, to protect against replay attacks. Authorizations can be collected and batched, and the transaction with the authorization(s) itself acts as a type 2 EIP-1559 transaction such that a smart contract can be called and ETH transferred.
EIP-7702 is kind of the best of both worlds, in that the wallet can function as a regular EOA, or as a smart wallet, or both. Existing EOAs can also be retrofitted with smart wallet functionality. It is expected that, at least initially, most EIP-7702 wallets will plug into existing ERC-4337 infrastructure, although the standard does not require it.
An EIP-7702 wallet with two different types of transactions: a type-4 EIP-7702 transaction, and a type-2 EOA transaction
Security and Design Philosophy
It is critical that both the wallet software, and the smart contract, be absolutely trusted: they can do anything that the EOA can do. This is called out in the EIP itself, which admonishes that there is no safe way to allow a third party application to have any kind of control over the authorization itself. There are almost certain to be exploits whereby a user is cajoled into authorizing a malicious 3rd party smart contract to be the delegate of an existing EOA, which then promptly steals all of the assets.
From a design philosophy perspective, EIP-7702 is about “smart wallets” rather than “EOA scripts”, in order to not distract from future AA enhancements and to keep implementation efforts manageable. That means that EIP-7702 type 4 transactions cannot deploy a new smart contract, specify a pre-compile as delegate, attach blobs, or leave the authorisation list empty, although early testing indicates that some L2s appear to ignore this last rule.
Conclusion
At launch the only wallet promising out‑of‑box support is Ambire, but others are sure to follow. MultiBaas also supports type 4 transactions and signing authorization lists with Cloud Wallets. Get in touch to learn more or if there’s something we can do to help you build with EIP-7702.
Eagle-eyed readers might be wondering, why ERC-4337 but EIP-7702? Because ERC-4337 lives purely at the smart‑contract layer, it sits in the “ERC” (Ethereum Request for Comments) bucket alongside classics like ERC‑20 and ERC‑721. By contrast, EIP-7702 tweaks the core consensus rules, so it keeps the more formal “EIP” (Ethereum Improvement Proposal) badge reserved for protocol‑level upgrades.
.png)
