Ethereum EIP-4337: The Evolution from Account Abstraction to Smart Contract Wallets

Account abstraction is redefining transaction logic on Ethereum. In the past, individual users could only operate through externally owned accounts (EOAs) controlled by private keys and seed phrases, a model that posed security risks and poor user experience. The emergence of EIP-4337 has changed all that. Through innovative technical architecture, it allows user operations to break free from traditional mempool constraints, ushering in a new era of account management.

Why Does Ethereum Need Account Abstraction? Pain Points and Opportunities

Before understanding EIP-4337, we must recognize the fundamental issues with Ethereum’s existing account system. Currently, Ethereum has two account types: externally owned accounts (EOAs) controlled by private keys, and contract accounts (CAs) governed by smart contracts. The binary structure limits user flexibility and has become a major barrier to mainstream adoption of crypto.

The core goal of account abstraction is to break down this barrier. It separates transaction origin and signature mechanisms, enabling EOAs to have more characteristics of CAs, allowing users to enjoy the convenience of smart contract wallets without complex operations. This is especially important for non-crypto-native developers—they no longer need to understand private keys, gas fee calculations, or memorize cumbersome seed phrases. Account abstraction promises to lower entry barriers while offering enhanced security options and payment flexibility.

How Is Ethereum Progressing Toward Account Abstraction?

The development of account abstraction has not been immediate. As early as 2020, the Ethereum community first proposed this concept with EIP-2938. Later, EIP-3074 introduced two new opcodes—AUTH and AUTHCALL—that enable EOAs to delegate operations to smart contracts. These attempts laid the groundwork for subsequent solutions.

However, these early proposals were paused due to the need for large-scale changes to Ethereum’s consensus layer. The dilemma of EIP-3074 is typical—any solution involving core protocol modifications risks hard forks, which are costly for a decentralized network. As a result, the community began exploring solutions that do not require protocol modifications, leading to the creation of EIP-4337.

The 7 Key Concepts of EIP-4337

EIP-4337 breaks through previous limitations by introducing a new mechanism for account abstraction. To understand this solution, you need to grasp these seven key roles and elements:

UserOperation is the basic object sent when an individual initiates a transaction. It contains all necessary information—sender address, target contract, signatures, etc.—but is not yet signed by the user.

EntryPoint Contract is responsible for executing and verifying user operations. When an operation reaches it, it checks the transaction’s validity and ensures the corresponding wallet has sufficient funds.

Bundler is the system’s hub. These nodes collect multiple UserOperations from the mempool, bundle them into a single transaction, and submit it to the EntryPoint contract. Bundlers act like miners but with more complex logic.

Wallet Contract replaces the traditional EOA. It is a smart contract account owned by the user, executing specific transaction logic and controlling assets.

Wallet Factory is a smart contract that automatically deploys new smart wallets based on user needs, eliminating the need for users to manually create wallet addresses.

Aggregator is a trusted auxiliary contract that aggregates multiple signatures into one, saving on-chain storage space. Bundlers manage whitelist access for aggregators.

Paymaster is the most innovative concept in account abstraction. It breaks the requirement that gas must be paid in ETH, allowing users to pay gas fees with any token or even have third parties sponsor transactions.

How Do Transactions Work Under EIP-4337? Full Process Breakdown

Once you understand the components, let’s see how a transaction flows from initiation to completion.

Step 1: User Sends a UserOperation. The user submits a UserOperation via a smart wallet, including gas parameters like maxFeePerGas and maxPriorityFee. The signature field is determined by the wallet implementation, not enforced by the protocol, providing developers with great flexibility.

Step 2: Operation Enters the Mempool. These UserOperations are sent to a dedicated mempool, waiting for bundlers to process. Unlike traditional transaction pools, this pool follows EIP-4337’s specific logic.

Step 3: Bundler Packs and Verifies. Bundlers collect multiple UserOperations, verify each signature via the validateUserOp function on the EntryPoint contract. Only verified operations are bundled into a single transaction. During this stage, bundlers may collaborate with block builders (e.g., MEV-boost nodes) to ensure the transaction is included in a block.

Step 4: Transaction Is Executed and Confirmed. The EntryPoint contract calls the executeUserOp function on the smart wallet, completing asset transfers or contract interactions. The block containing this transaction is then added to the blockchain.

The beauty of this process is that users don’t need to understand any of these technical details. From their perspective, they just send a transaction, and everything else is handled automatically by the smart wallet and backend services.

EIP-3074 vs EIP-4337: Why Is the Latter Superior?

If EIP-3074 was a promising solution, why was it ultimately set aside in favor of EIP-4337?

EIP-3074’s design is indeed elegant in some respects. It allows any EOA to act as a smart contract wallet without deploying a contract. By introducing the caller contract, it enables gas payments with tokens other than ETH, greatly improving user experience. But the problem lies in—implementing this requires introducing new opcodes (AUTH and AUTHCALL), which involve changes to the consensus layer. For a network with billions of dollars in assets, any consensus change carries significant risk.

EIP-4337 cleverly sidesteps this issue by implementing account abstraction at the application layer, without modifying the Ethereum protocol itself. This greatly reduces risk and speeds up deployment. Although EIP-4337 still relies on ECDSA signatures, making it somewhat conservative compared to EIP-3074’s support for arbitrary signatures, its overall feasibility and security are far superior.

Additionally, EIP-3074 has a critical weakness—its limited flexibility at the signature layer. Upgrading signature schemes (e.g., moving from ECDSA to more efficient schemes) would require complex operations. EIP-4337, on the other hand, leaves ample room for such upgrades.

The Future of Account Abstraction

Although EIP-3074 has been temporarily set aside, the Ethereum community has not abandoned its vision. New proposals like EIP-5003 introduce AUTHUSURP opcode, allowing address code deployment and combining with EIP-3607 to revoke original EOA signing key permissions. This means existing EOAs could eventually upgrade to more powerful account types, transitioning from ECDSA to advanced signature schemes.

As EIP-4337 is gradually implemented, Ethereum is building an ecosystem more friendly to mainstream users. Account abstraction is not just a technical innovation but a systemic rethink for large-scale Web3 applications. When users no longer need to understand private key complexities, when gas fees can be paid with any token, and when smart wallets become the default, the practicality of crypto will reach a new level.

EIP-4337 is a key step in this revolution. It proves that innovation at the application layer, without altering the core protocol, can bring profound change. As more wallets and platforms adopt the EIP-4337 standard, the vision of account abstraction will shift from a technical blueprint to everyday reality, creating frictionless experiences for the next generation of crypto users.