ERC-4337 vs EIP-7702 - Understanding Ethereum's Competing Standards
As Ethereum continues to evolve, the way users interact with the network is undergoing a major shift. Two proposals, ERC-4337 and EIP-7702, are at the center of this transformation, each offering a unique vision for account abstraction. While ERC-4337 has paved the way for smart accounts using an off-chain infrastructure, EIP-7702 introduces a more native and streamlined approach. In this post, we’ll break down the key differences between these proposals and explore what they mean for developers, users, and the future of Ethereum.
Ethereum’s Account Model
In Ethereum there are two types of accounts:
- Externally Owned Accounts (EOAs)
- Smart Contract Wallets (Smart Accounts)
Ethereum’s original account model uses Externally Owned Accounts, or EOAs. These accounts are controlled by a single private key and are responsible for signing transactions and paying gas fees. While this design is simple and efficient, it also introduces several important limitations.
EOAs cannot include any custom logic. They cannot enforce rules like multi-signature approval, session-based access, daily spending limits, or social recovery. All of these features must be added externally, often through complex smart contract interactions. This limits flexibility and increases the chances of user error. EOAs must also hold ETH to pay gas fees, even for simple interactions with dApps or token transfers. This can create friction during onboarding and limit accessibility for new users. These challenges become even more noticeable in mobile-first or multi-chain environments where user expectations are higher.
To solve these problems, the Ethereum community proposed account abstraction. This concept allows users to replace EOAs with smart contract-based accounts that include programmable logic. These smart accounts can define custom rules for signing, recovery, gas payments, and access control. The goal is to improve security, simplify onboarding, and enable features that feel more like modern app experiences.
Understanding EIPs and ERCs
It's important to understand the difference between:
- Ethereum Improvement Proposals (EIPs): Protocol-level proposals
- Ethereum Request for Comments (ERC): Application-level standards
EIPs are changes to the Ethereum protocol that usually require a hard fork, such as EIP-7702. They affect how the network operates at a fundamental level. In contrast, ERCs are standards built on top of Ethereum, often using smart contracts, and do not require any changes to the protocol. For example, ERC-4337 enables account abstraction through smart contracts without needing a hard fork. Developers can adopt ERCs freely without waiting for network upgrades.
What is ERC-4337?
ERC-4337 introduces a new architecture built on smart contracts and an alternative transaction flow:
- User Prepares a UserOperation
Instead of sending a traditional Ethereum transaction, the user (or their wallet) creates a UserOperation object. This includes:- The desired action (e.g. send tokens, call a contract)
- Gas and fee payment information
- A signature or validation logic
- The smart account address
- UserOperation is Sent to a Bundler
The UserOperation is broadcast to a special UserOperation mempool. This is different from the regular Ethereum mempool and is used only for ERC-4337 operations. - Bundler Collects and Bundles UserOperations
A bundler scans the UserOperation mempool, selects valid operations, groups them into a batch, and submits them as a single transaction to the EntryPoint contract on Ethereum. - EntryPoint Contract Verifies and Executes
The EntryPoint smart contract:- Validates each UserOperation using the logic defined in the user’s smart account
- Ensures that gas fees will be paid, either by the user or by a paymaster
- Executes the action defined in the UserOperation
- Gas is Paid by User or Paymaster
- If the user included ETH or another payment method, the fee is deducted
- If a paymaster is used, it covers the gas cost, often in exchange for a service fee or tokens
- Result is Written to the Blockchain
Once executed, the actions (e.g. token transfer, contract call) take effect on-chain like any other Ethereum transaction.
The user does not sign or send a regular Ethereum transaction. Instead, the wallet prepares a UserOperation and relies on a bundler to get it executed through the EntryPoint contract. This allows advanced features like gasless transactions, custom signature schemes, and smart wallet logic without changing the Ethereum protocol.
Step-by-Step Example of an ERC-4337 Transaction
https://etherscan.io/tx/0x12caa21725899d0838c7f1ee8a7783fa18cf39add5d7965c20b5b5af52ca7893
In the transaction above user initiates the action, but it isn’t immediately recorded on-chain. Instead, it’s picked up by a bundler, grouped with other UserOperations, and sent to the blockchain as a single transaction through the EntryPoint contract. You can see how it was bundled into
https://etherscan.io/tx/0x9178311b2800011565bc9249f77ad0ebabfb62a121a70f44772fa4235adc6105
Which merges all side effects of different AA transactions such as event logs and internal calls - into one unified result on the blockchain. What makes this process powerful is the use of a paymaster. In this case, the address 0x777...34C covered the gas fees on behalf of the user, allowing the transaction to succeed even though the initiator’s account 0xB507...46d held no ETH.
This unlocks a much more flexible user experience. For example, allowing users to pay transaction fees in USDC or other tokens instead of needing ETH, which removes one of the major pain points for new or non-technical users.
What is EIP-7702?
While ERC-4337 brought powerful features through smart contract wallets, it also introduced complexity by relying on off-chain infrastructure like bundlers and a separate mempool. EIP-7702 was proposed as a simpler, protocol-level solution that brings many of the same benefits directly into the Ethereum base layer, eliminating the need for additional systems and actors.
EIP-7702 allows a regular Externally Owned Account (EOA) to temporarily act like a smart contract during a single transaction. It introduces a mechanism where a user can attach smart contract bytecode to their transaction, enabling custom logic such as signature checks or spending rules. This is done using a new method called execute
, which executes the logic defined in the temporary code before processing the transaction. After execution, the EOA returns to its normal state, keeping backward compatibility.
Take this transaction as an example:
https://etherscan.io/tx/0x06ba577c4c992aae1e16eec3460f2bd4df148b4d66f9077132fd302222fd38d6
Key indicators of EIP-7702 usage include:
- Transaction Type:
0x04
- From/To Address: The same EOA (
0x0174...D9135
) appears as both sender and recipient, confirming that the account is delegating execution to itself temporarily - Authorization List: A new field introduced in EIP-7702 containing delegation data and cryptographic verification
To break down authorization list:
- Authority: The original signer who grants permission to another address; typically the account owner (an EOA) who authorizes execution by signing a message, and may differ from the
from
address that actually submits the transaction. - Delegated Address: The account authorized by the Authority to act on their behalf; it can be either a smart contract or an EOA, depending on the use case.
The core idea behind this transaction is that the EOA temporarily adopts smart contract functionality during execution. It references MetaMask’s audited delegator contract at 0x63c0...32b
, with a 0xef0100
prefix that ensures compatibility with EIP-3541. This setup allows the account to run custom logic for a single transaction, such as calling execute(bytes32 proposalId, bytes actions)
, without changing its permanent behavior or compromising security.
The temporary contract logic handles several atomic operations in one go such as:
- Swapped LBTC for WETH using a Uniswap pool
- Transferred WBTC between Uniswap V3 or V4 liquidity pools
- Routed 0.000223295 WETH to Uniswap’s fee collector address
Without EIP-7702, each action must be sent as a separate transaction, requiring multiple user signatures and direct ETH payments for gas. There’s no atomicity, so if one transaction fails, the rest may still go through, causing inconsistent outcomes. Batching is only possible with a separate smart contract wallet, which adds extra cost and complexity.
Comparison and Impact on Developers & Users
ERC-4337 enables advanced wallet features using off-chain components like bundlers, a separate mempool, and the EntryPoint contract. It works on existing Ethereum without protocol changes but is limited to new smart contract wallets. While flexible, it’s more complex to implement. EIP-7702 is a simpler, fully on-chain solution introduced with the Pectra upgrade. It supports existing EOAs, follows the standard transaction flow, and requires protocol changes. Its simplicity makes it ideal for mass adoption and smooth onboarding.
Both ERC-4337 and EIP-7702 aim to enhance the Ethereum experience through account abstraction but impact developers and users differently. ERC-4337 offers flexible smart account features like gas sponsorship and custom authentication, but requires off-chain components such as bundlers and paymasters, adding complexity. Users benefit but adoption may be slower. EIP-7702 takes a simpler, protocol-level approach, letting users keep their EOAs while enabling smart contract behavior in a single transaction. For developers, it removes the need for extra infrastructure, making integration easier and more suited for broad adoption.
tldr;
- ERC-4337 is off-chain; EIP-7702 is built into the protocol.
- ERC-4337 is complex; EIP-7702 is simpler.
- ERC-4337 needs smart wallets; EIP-7702 works with EOAs.
- ERC-4337 supports gas sponsorship; EIP-7702 uses regular gas.
Member discussion