Ethereum wallets have traditionally worked in a simple way: one private key controls one externally owned account, or EOA. That model is predictable, but it makes modern wallet features such as transaction batching, sponsored gas, spending limits, alternative authentication, and recovery much harder to implement.
EIP-3074, EIP-7702, and ERC-4337 approach that problem from different directions. EIP-3074 proposed giving EOAs delegated execution through new EVM opcodes, EIP-7702 lets existing EOAs delegate their execution to smart contract code, and ERC-4337 builds full smart accounts through an application-layer system of UserOperations, bundlers, EntryPoint contracts, and optional paymasters.
The status difference matters in 2026. EIP-3074 is useful mainly as architectural history, EIP-7702 has been live on Ethereum since the Pectra upgrade on May 7, 2025, and ERC-4337 is an established account-abstraction standard that works without requiring a consensus-layer change.
What Problem Are Ethereum Account Upgrades Trying to Solve?
Traditional EOAs are intentionally limited. They can sign and send transactions, but they do not natively contain programmable validation logic comparable to a smart contract account.
That creates friction whenever a wallet wants to offer functionality beyond the basic private-key model. The features developers commonly want include:
- Transaction batching: combine several related actions into one user flow.
- Gas sponsorship: allow an application or another account to pay transaction fees.
- Alternative authentication: use authorization systems beyond a conventional Ethereum private key.
- Spending controls: restrict what an application or secondary key can spend.
- Recovery: introduce mechanisms that do not depend entirely on one seed phrase.
- Session permissions: authorize limited actions without exposing unrestricted control of the wallet.
Ethereum’s own description of EIP-7702 highlights batching, sponsorship, alternative authentication, spending controls, and recovery as important wallet capabilities enabled by programmable accounts.
The disagreement has never really been about whether wallets need better UX. The harder question is where that programmability should live: inside Ethereum’s protocol, through delegated EOA code, or through smart accounts built above the protocol.
EIP-3074 vs EIP-7702 vs ERC-4337: What Is the Difference?
The three designs all move Ethereum away from the rigid “private key signs one transaction” experience, but they do not implement the idea in the same way.
| Feature | EIP-3074 | EIP-7702 | ERC-4337 |
|---|---|---|---|
| Core model | EOA authorizes an invoker | EOA delegates execution to contract code | Smart contract account |
| Main mechanism | AUTH and AUTHCALL | Set-code transaction + authorization tuples | UserOperation + EntryPoint |
| Protocol change required | Yes | Yes | No |
| New EVM opcodes | Yes | No | No |
| Existing EOA address | Preserved | Preserved | Usually uses a smart account |
| Batching | Yes | Yes | Yes |
| Gas sponsorship | Possible | Possible | Paymasters |
| Custom account logic | Invoker-dependent | Delegated implementation | Native to smart account |
| Specialized infrastructure | Invoker | Wallet/delegation infrastructure | Bundlers, EntryPoint, optional paymasters |
| Current relevance | Historical/superseded direction | Live on Ethereum | Live and established |
This table also clears up a common eip vs erc question. An Ethereum Improvement Proposal can describe changes to Ethereum itself, while an ERC is a standards-track category focused on application-level conventions; ERC-4337 deliberately achieves account abstraction without changing Ethereum consensus rules.
So when people search erc vs eip, the distinction is not that one is automatically newer or better. They describe different scopes of standardization.
What Was the Earlier Delegation Proposal?
EIP-3074 was an attempt to give existing EOAs smart-account-like powers without requiring users to migrate to entirely new wallet addresses. It proposed adding two opcodes to the EVM: AUTH and AUTHCALL.
The design centered on three pieces:
- AUTH verified that an EOA had signed an authorization.
- AUTHCALL allowed an authorized contract to make calls using that EOA’s authority.
- Invoker contracts contained the logic governing how the delegated authority could be used.
This could enable useful wallet behavior such as sponsored transactions and batching. A user might authorize an invoker once and then let that contract coordinate several operations that would otherwise require separate transactions.
The problem was authority. An invoker could become a powerful intermediary between the EOA and everything it owned, which meant poorly designed authorization or compromised invoker logic could have serious consequences.
That does not make eip 3074 a failed idea in the useless sense. It helped expose the requirements and security questions involved in making EOAs programmable, and those lessons influenced the direction that followed.
How Does the New EOA Delegation Model Work?
EIP-7702 adds a set-code transaction containing one or more authorization tuples. Each tuple identifies the chain, delegated code address, nonce, and signature information required to verify the authorization.
The simplified flow looks like this:
- The EOA owner selects trusted delegation code. This is the smart contract implementation whose behavior the account will adopt.
- The owner signs an authorization. The authorization identifies the delegation target and includes replay-protection information such as the nonce.
- A set-code transaction carries the authorization. Ethereum processes the authorization list before normal transaction execution.
- Ethereum writes a delegation indicator to the EOA. Calls to that account then load and execute the delegated code in the EOA’s context.
- The account keeps its existing address and assets. It gains programmable behavior without requiring the user to transfer everything into a newly created account.
- The delegation can later be replaced or cleared. A subsequent valid authorization can point the account elsewhere or reset its delegated code.
One nuance is important: the delegation is persistent, not automatically discarded at the end of the transaction. Earlier drafts explored temporary code, but the final specification deliberately adopted persistent delegation to better align EOA upgrades with smart-account development.
That persistence is useful, but it also raises the stakes. Users should not casually approve arbitrary delegation code because the implementation receives broad power over how their account behaves.
What Can Programmable EOAs Actually Do?
The protocol change matters only if it improves real wallet behavior. The practical capabilities are more interesting than the transaction-format plumbing underneath them.
Batching is the clearest example. Instead of approving a token in one transaction and swapping it in another, compatible wallet logic can package related operations into a more coherent flow.
Gas sponsorship is another major use case. One account or application can cover transaction fees for another user, reducing the familiar onboarding problem where someone owns tokens but cannot do anything because they first need ETH for gas.
Privilege de-escalation can give secondary keys narrower permissions. The EIP itself gives examples such as permitting a key to spend ERC-20 tokens but not ETH, limiting daily spending, or restricting interactions to a particular application.
Wallet developers can also build alternative authentication and recovery systems around delegated logic. The Ethereum Foundation specifically points to passkeys, spending controls, and recovery mechanisms as potential benefits.
What Is ERC-4337?
ERC-4337 takes a more complete approach to account abstraction. Instead of upgrading an ordinary EOA into something more programmable at the protocol level, it uses smart contract accounts with their own validation logic.
The standard deliberately avoids consensus-layer changes. Users submit objects called UserOperations, bundlers collect them, and a singleton EntryPoint contract validates and executes them on-chain.
This gives account developers far more freedom over how authorization works. The signature field, for example, is interpreted by the smart account implementation rather than being hardcoded into Ethereum’s normal EOA transaction rules.
That flexibility is why the common phrase eip 4337 is technically imprecise. The standard is ERC-4337, and its defining feature is precisely that it implements account abstraction at a higher layer instead of modifying Ethereum consensus.
How Does the Smart-Account Flow Work?
ERC-4337 introduces more moving parts than an ordinary Ethereum transaction. That complexity buys flexibility, but developers need to understand what each component actually does.
A typical operation follows this sequence:
- The wallet creates a UserOperation. It contains the sender, nonce, call data, gas parameters, signature, and other information required to execute the action.
- The operation reaches a UserOperation mempool. It does not initially enter Ethereum’s normal transaction mempool.
- A bundler validates and collects operations. Bundlers package valid UserOperations together.
- The bundler submits a transaction to the EntryPoint contract. The EntryPoint is the shared on-chain coordinator for ERC-4337 operations.
- The smart account validates the operation. Its own code determines whether the supplied authorization is acceptable.
- An optional paymaster can cover gas. Paymasters allow another party to sponsor the transaction under programmable conditions.
- The EntryPoint executes the requested action. The resulting state changes are settled on Ethereum like other smart contract execution.
This architecture explains both the power and the operational burden of ERC-4337. A smart account is not merely an EOA with an extra switch; it participates in a specialized transaction pipeline.
How Do the Two Live Approaches Fit Together?
EIP-7702 and ERC-4337 are not mutually exclusive. In fact, the final EIP-7702 design explicitly considers forward compatibility with ERC-4337 and allows delegated EOAs to fit into smart-account-oriented infrastructure.
The simplest mental model is:
EIP-7702 upgrades what an existing EOA can do.
ERC-4337 defines infrastructure for programmable smart accounts and UserOperations.
That means a wallet does not necessarily need to choose an ideological camp and burn the other specification in a ceremonial bonfire. Developers can use EIP-7702 to give an existing address programmable execution while reusing parts of the account-abstraction ecosystem built around ERC-4337.
The ERC-4337 specification now explicitly includes support for EIP-7702 authorization data. That convergence is a stronger signal than treating the standards as competing replacements.
When Should Developers Use EIP-7702?
EIP-7702 is particularly relevant when an application wants to add programmable wallet behavior while preserving an existing EOA address. It avoids forcing the user to migrate assets and identity into a separate smart account merely to gain better UX.
Consider it when:
- existing EOA compatibility matters;
- users should retain their current addresses;
- transaction batching is useful;
- sponsored transactions are part of the experience;
- limited permissions or alternative authentication are needed;
- the wallet can safely manage delegation targets;
- compatibility with broader smart-account infrastructure matters.
The major responsibility is delegation security. The EIP warns that applications should not simply ask users to authorize arbitrary code, because delegated implementations receive unrestricted access to the account context.
Wallets therefore need to treat delegation implementations as security-critical components. Auditing the code behind an authorization is not optional decoration for the footer of a launch announcement.
What Are the Security Trade-Offs?
Account abstraction can improve security, but programmability is not automatically synonymous with safety. It replaces some rigid limitations with configurable logic, and configurable logic can be configured disastrously.
For EIP-7702, the largest concern is delegation authority. The specification warns that there is no generally safe way for arbitrary applications to ask users to approve arbitrary delegation code because that code can receive extensive access to the account.
Other considerations include:
- malicious delegation implementations;
- phishing users into authorizing dangerous code;
- nonce and replay handling;
- storage collisions or initialization mistakes;
- unexpected behavior when replacing delegation code;
- cross-chain authorization mistakes.
The protocol mitigates some of these problems through chain IDs, nonces, signature verification, and the ability to clear or replace delegation. Those protections do not make an untrusted delegate safe.
ERC-4337 shifts some risks elsewhere. Smart account validation, EntryPoint compatibility, bundler behavior, paymaster rules, factories, and upgradeable wallet code all become parts of the security model.
What Is the Practical Direction for Ethereum Accounts?
Ethereum is moving toward a world where the distinction between a traditional EOA and a programmable smart account becomes less rigid. EIP-7702 gives existing accounts a bridge toward executable behavior, while ERC-4337 provides an established infrastructure stack for account abstraction.
That direction matters because Ethereum has an enormous installed base of EOAs. Requiring every user to create a completely new smart account, transfer assets, rebuild approvals, and establish a new identity creates migration friction that wallet developers would rather avoid.
EIP-7702 reduces that friction by letting an existing account participate in more advanced wallet designs. ERC-4337 can then supply infrastructure and account-abstraction patterns around those programmable accounts.
The likely future is therefore not a clean winner-takes-all contest. It is a stack in which protocol improvements and application-layer account abstraction increasingly work together.
What Are the Main Trade-Offs?
The three approaches can be reduced to a few architectural trade-offs.
EIP-3074 offered a relatively direct way to let EOAs delegate execution through invokers. Its advantage was compatibility with existing accounts, but its authorization model raised broader design concerns and it was superseded by the EIP-7702 direction.
EIP-7702 keeps existing EOAs relevant while allowing them to gain programmable behavior. That improves migration and compatibility, but developers must handle delegation and authorization safely.
ERC-4337 offers the richest established smart-account infrastructure without requiring a consensus change. The trade-off is additional architecture: bundlers, EntryPoint interactions, smart account contracts, and potentially paymasters all become part of the execution path.
There is no magical version that delivers unlimited flexibility, zero infrastructure, perfect backward compatibility, and no additional security surface. Ethereum account design, tragically, remains subject to engineering rather than wishes.
What Should Developers Check Before Implementing Account Abstraction?
Before choosing an architecture, teams should answer several concrete questions. Starting from features and working backward is safer than picking a standard because its number appears most frequently on Crypto Twitter.
- Does the user need to keep an existing EOA address? If yes, EIP-7702 becomes especially relevant.
- Does the wallet need full smart-account programmability? Complex validation, modules, recovery, and spending policies may favor ERC-4337 infrastructure.
- Who pays gas? If sponsorship is central to the product, determine whether a paymaster or another fee mechanism will handle it.
- How are permissions revoked? Delegated authority needs an understandable lifecycle, not merely an approval flow.
- What happens if delegated code is compromised? Developers should understand the maximum damage an implementation or module can cause.
- Which infrastructure components are required? Bundlers, paymasters, RPC connections, indexers, and monitoring systems solve different problems.
- How will transactions be simulated? More complex wallet actions make pre-execution checks increasingly valuable.
- How will users understand what they authorize? Better account technology is not especially useful if the wallet turns every permission into an indecipherable confirmation screen.
These questions also make architecture reviews more concrete. Instead of debating eip 4337 or EIP-7702 abstractly, teams can compare each design against the actual requirements of the wallet or application.
What Is the Practical Direction for Ethereum Accounts?
Ethereum is moving toward a world where the distinction between a traditional EOA and a programmable smart account becomes less rigid. EIP-7702 gives existing accounts a bridge toward executable behavior, while ERC-4337 provides an established infrastructure stack for account abstraction.
That direction matters because Ethereum has an enormous installed base of EOAs. Requiring every user to create a completely new smart account, transfer assets, rebuild approvals, and establish a new identity creates migration friction that wallet developers would rather avoid.
EIP-7702 reduces that friction by letting an existing account participate in more advanced wallet designs. ERC-4337 can then supply infrastructure and account-abstraction patterns around those programmable accounts.
The likely future is therefore not a clean winner-takes-all contest. It is a stack in which protocol improvements and application-layer account abstraction increasingly work together.
FAQ
Does EIP-7702 Turn an EOA Into a Smart Contract Permanently?
Not in the same sense as deploying a new smart contract account at a new address. EIP-7702 lets an EOA designate code through an authorization mechanism while retaining the existing address.
That distinction is precisely why the proposal matters for migration. The user can gain programmable behavior without first moving everything to a separately deployed account.
Can EIP-7702 Be Used Without ERC-4337?
Yes. EIP-7702 is a protocol-level mechanism and does not require ERC-4337 simply to function.
ERC-4337 becomes relevant when developers want to combine delegated EOAs with its broader account-abstraction infrastructure, including UserOperations, bundlers, EntryPoint, and paymasters.
Does Account Abstraction Remove Private Keys?
Not automatically. Account abstraction makes it possible to define more flexible validation rules, but a wallet may still use a private key as one of those authorization mechanisms.
The difference is that authorization no longer has to be permanently limited to Ethereum’s traditional EOA signature model. Wallet developers can build recovery, multisignature rules, passkey-based systems, session permissions, or other policies depending on the account design.
Can EIP-7702 Delegation Be Changed?
Yes. The delegation model is designed so that an account is not permanently married to one implementation forever.
That flexibility is useful for upgrades and revocation, but it also means wallets need to manage authorization changes carefully. Users should be able to understand which implementation currently controls programmable behavior and how that authority can be replaced or removed.
Does EIP-7702 Make Every Ethereum Wallet Automatically Smarter?
No. The protocol capability does not magically redesign wallet software.
Wallet providers still need to implement the relevant transaction flows, authorization interfaces, delegated code, security controls, and user experience. Protocol support creates the possibility; wallet implementations determine what users actually receive.
