Unleashing Account Abstraction with EIP-4337


Written by

Read time

8 min

Hello World!

You may have seen Vitalik Buterin, founder of Ethereum, tweeting about EIP-4337 and what it means for the Ethereum network. In this week’s Web3edge newsletter, we break down and demystify EIP-4337 and account abstraction for you.

In our news highlights section we take a brief look at the FUD (fear, uncertainty, doubt) headlines that have overshadowed the industry in the past week, while also covering uplifting news of continued mainstream adoption of Web3.

Web3edge Originals

What is EIP-4337 and “account abstraction”?

Short answer:

Account abstraction creates a new account type which exists as a smart contract. By having the account exist as a smart contract, transaction validation and transaction execution are split.

EIP-4337 is a proposal authored by Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson and Tjaden Hess which lays out the specifications of the account abstraction proposal without making consensus-level changes (i.e., no hard-fork needed).

For a quick refresher on what an EIP (and an ERC) is, have a quick look at the ”From EIP to ERC” section of our Master Web3 Fundamentals: From Node to Network piece.

Long answer:

Accounts in Ethereum

In Ethereum there are currently two account types:

  • Externally-owned account (EOA)
  • Contract accounts (CA)
Accounts in Ethereum, adapted from Takenobu T.

EOAs are accounts that belong to normal users: they are owned by people external to the Ethereum network. CAs belong to smart contracts, and creating a CA is only possible from within the network by using an EOA or another CA. Account abstraction matters most to normal users that would normally own an EOA.

Transaction Process

The EOA Transaction Process in Ethereum

Transactions are authorized by an EOA by signing the transaction details with the private key of that account. The transaction details as well as the signature are sent to the Ethereum Virtual Machine (EVM) for verification that the signature is valid and that the nonce in the transaction matches the nonce in the account. Once the validation is complete, the EVM executes the transaction and deducts gas fees (transaction fees) from the EOA’s account balance.

Definition of Abstraction

In computer science, abstraction refers to the extraction of relevant pieces from a larger piece, or phrased differently, splitting something into smaller pieces. In Ethereum, account abstraction refers to the splitting of transaction validation and transaction execution from being a single monolithic process (above), to modular components that can be adjusted as per users’ individual requirements.

Simple Illustration of Abstractions

Account Abstraction in EIP-4337

In EIP-4337 the validation and transaction processes are separated into two smart contracts: the Entry Point Contract and Wallet Contract. The Entry Point Contract acts as a coordinator that communicates with the Wallet Contract. The Wallet Contract handles the validation of a user’s transaction based on custom logic implemented by the Wallet Contract. If the Wallet Contract successfully validates a transaction, the Entry Point Contract executes the transaction, which is then submitted to be included in the next block.

EIP-4337 and Abstracted Account Transactions in Ethereum

This abstraction is what gives developers and users the freedom to codify whatever they want as requirements for a transaction to be valid in custom Wallet Contracts. For example, a Wallet Contract could use multi-sig, social recovery features or even quantum resistant signature schemes, instead of being limited to only using the ECDSA encryption scheme like EOAs are.

EIP-4337 introduces abstracted accounts without making consensus-level protocol changes, as it was previously proposed in EIP-2938. This is possible, because the functionality needed for abstracted accounts can be achieved with smart contracts in the current EVM.

Additional Architectural Requirements of EIP-4337

Apart from account abstraction through smart contracts, EIP-4337 also introduces a new transaction type specifically for abstracted accounts called UserOperations, a mempool exclusively for UserOperations and a Bundler that passes UserOperations to the Entry Point smart contract, which is to exist alongside the EOA mempool and normal transactions.

Mempool and UserOperation Mempool to co-exist

After a UserOperation is created and signed, the wallet app submits that UserOperation to the UserOperation mempool. A mempool is essentially a memory module on Ethereum nodes where transactions are stored before they are validated and included in a block. UserOperations are structurally different to transactions, which means they cannot be included in the existing mempool. To include them, consensus-level changes would be necessary which would require a hard-fork of the network. To avoid this, the proposal is to add a new mempool which would only require updating Ethereum node clients.

A Bundler is an actor that listens to the transactions in the UserOperation mempool, and bundles them into batches which are submitted to the Entry Point Contract on the EVM.

This design also enables additional benefits:

  • Multiple operations that would usually require multiple transactions can be bundled together. For example, approving the spending of a token and initiating a trade of the token could be executed as a single transaction.
  • Standardization of a Smart Contract Wallet Interface. Universality and standardization improve interoperability and security. Just look at what ERC-20 (token standard) or ERC-721 (non-fungible token standard) did for tokenization.

The Paymaster

Finally, EIP-4337 also proposes paymaster functionality, which would allow a third party to cover transaction costs of a user for certain UserOperations. This could be used to subsidize the usage of a protocol by paying the gas fees for users.

In the Verification Loop, the Entry Point Contract checks that the paymaster account has sufficient funds to cover the UserOperations, before passing the UserOperation to the Wallet Contract for validation. If everything succeeds, the account balances for the user and the paymaster are calculated and updated in the execution loop, before being passed on to be included in a block.

The paymaster functionality combined with the multiple operations mechanism enables another exciting use-case:

  • Use ERC-20 tokens to pay for transaction fees. By allowing multiple operations to be submitted in a single transaction, ERC-20 tokens can be transferred to a paymaster and the paymaster can handle paying gas using Ether, all in a single transaction.


Key benefits of EIP-4337 and Abstracted Accounts

In Summary, an abstracted account essentially provides users with the power of smart contracts for their everyday accounts. Abstracted accounts make the programmability of smart contracts available to average users and developers. Average users can harness that power to better control their Ethereum accounts, while developers can improve user experience through added convenience.

If you were previously not yet excited about EIP-4337, now is the time to be excited. When implemented, we can expect the developer community to come up with exciting new ways to leverage this technology.

To experience some of EIP-4337 features, you can test the Stackup Wallet, which to my knowledge is the first wallet that has implemented EIP-4337 features. I highly recommend their Discord as well, where they actively share their knowledge around EIP-4337.

Web3 News

A Tough Week for Web3

This week was filled with FUD, including:

Nonetheless, Adoption Steadily Continues

Knowledge Hub

Additional content to grow your edge and expand your horizon.


Marco Manoppo takes a look at crypto VCs’ economics and explains why it is critical for founders to scrutinize the VC firms themselves as businesses.

When a project that is raising capital for its equity entity, determining what % of tokens to offer to existing or future equity investors becomes challenging. In below piece, Vader Research provides a framework for token allocation to team members and investors.

Design Thinking

Understanding how to design a system is a key aspect of being able to analyze and understand it. In a16z’s series on all things ‘auctions for web3’, speakers and authors look at Web3 and crypto through the lens of auction systems, which are arguably everywhere in in this industry. “[Auctions], broadly defined, are simply ways of selling and allocating scarce things – and which applies in web3 contexts to everything from NFT mints, to blockchains themselves.”

Below three pieces of a16z’s auction series give a unique perspective on Web3’s parallels to auction systems:

Opinion Pieces


Today’s newsletter was written by @0xPhillan for Web3edge.io. Follow @Web3edge_io on Twitter!

This newsletter is not financial advice, I am not a financial advisor. The information provided by Web3edge is for general informational and educational purposes only. Do your own research before investing. See Disclaimers for more information.

Was this email forwarded to you? Sign up here.


Related content