The Road to Account Abstraction on Ethereum

Executive Summary

Managing public/private key pairs is a persisting hurdle to user adoption for cryptocurrencies. Ethereum was never intended to launch with externally owned accounts (EOAs), that is accounts controlled by public/private key pairs. Vitalik Buterin, the co-founder of Ethereum, envisioned user accounts on Ethereum that could be controlled by smart contract code. Programmable smart contract accounts would allow users to apply more flexible conditions to securely transfer crypto assets to and from their wallets. Account abstraction is the official terminology for describing smart contract-controlled user accounts. Interest in account abstraction has soared in 2023 and continues to grow in 2024. This report dives into what account abstraction is and the solutions being proposed to enable the technology on Ethereum.

Introduction

Two years ago, Ethereum developers Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso, and Tjaden Hess co-authored an Ethereum Request for Comment (ERC) outlining a new process for user transaction execution. Called ERC 4337, the proposal offers a new approach to enabling greater levels of programmability to user transactions without having to change the core protocol of Ethereum.

Users on Ethereum can only initiate transactions from a user-controlled account, also called an “externally owned account” (EOA). Transactions from EOAs are authorized by a digital signature from the account user’s private key. The private key is the most important piece of information that gives a user access and control to the funds held in an EOA. On Ethereum, the specific type of digital signature scheme that is used to secure EOAs is known as the Elliptic Curve Digital Signature Algorithm (ECDSA). It is the same scheme used on Bitcoin.

Because private keys can be cumbersome to securely record and remember, Ethereum users and cryptocurrency holders rely on wallet software to manage their private keys or centralized custodians to manage their crypto assets directly on their behalf. For years, Ethereum founders like Vitalik Buterin and protocol developers like Yoav Weiss have been researching ways to improve the user experience of transacting on-chain through programmable EOAs, that is EOAs that can execute and authorize transactions through any type of logic, not strictly the logic of public/private key digital signatures. Another term for programmable EOAs is account abstraction (AA).

AA can enable a wide array of new methods and authorization schemes for executing transactions on-chain from simply enabling multiple signatures, that is the combination of more than one digital signature, to transactions that can be paid for in any type of ERC-20 token, not strictly the ETH in a user’s account. This report gives an overview of ERC 4337, its adoption, and related Ethereum Improvement Proposals (EIPs) that developers have proposed to further extend the capabilities of ERC 4337. This report also offers insights as to why AA will likely not be adopted in a meaningful capacity on Ethereum in the short-term as Ethereum developers focus on more pressing priorities such as maxEB and peerDAS, as well as in the medium-term as user activity migrates to Layer-2 rollups and alternative Layer-1 protocols that already support AA independent of Ethereum.

ERC 4337

In March 2023, during North America’s largest annual Ethereum-focused conference, ETHDenver, Yoav Weiss – a security fellow at the Ethereum Foundation – announced the launch of a new smart contract on Ethereum called EntryPoint. EntryPoint is designed to verify and execute transactions from “account contracts” (ACs). ACs are a type of Ethereum account through which users can code new logic for authorizing transactions. The logic must be structured with specific fields and types defined by the ERC 4337 standard. User transactions formatted with complex execution logic are called “UserOperations.” Once formatted, UserOperations can then be sent to a dedicated mempool for these types of transactions.

The following is a high-level illustration of the transaction execution flow for UserOperations as defined by ERC 4337.

Once a UserOperation is submitted to the canonical ERC 4337 mempool or an alternative mempool that also accepts UserOperations, it is picked up by a “Bundler.” Bundlers fulfill a similar role as block builders. They package multiple UserOperations together and submit the bundle for verification and execution on Ethereum. In exchange for simulating transactions and packaging them for execution on-chain, bundlers are compensated through fees attached by the user submitting the UserOperation.

UserOperations may specify a “Paymaster.” Paymasters are actors that sponsor the UserOperations of other users to allow for several new features on Ethereum, including:

• Users paying for transactions in cryptocurrencies other than ETH,

• Decentralized applications subsidizing fees for their users during the early phases of launch,

• The creation of on-chain credit services for transacting on Ethereum.

Once picked up by a Bundler, a UserOperation will then be submitted to the EntryPoint smart contract. The role of EntryPoint is to verify UserOperations and pay out relevant parties for the execution of UserOperations. Once the actions of a UserOperations are completed on-chain, the EntryPoint smart contract ensures that the relevant fees are debited from the Paymaster’s address (if specified and valid) and credited to the Bundler’s address.

Caveats

From the initial submission of a UserOperation to its execution on-chain, there are a few important caveats to note:

1. Though the EntryPoint smart contract on Ethereum is live, the unified ERC 4337 mempool has not yet been launched. Early iterations of this peer-to-peer specification for bundlers can be found on GitHub.

2. The creation of a new AC can be specified directly in a UserOperation such that the UserOperation not only specifies complex requirements for handling user transactions but also the AC that will sign messages on the user’s behalf.

3. It is important for block builders accepting UserOperations from a bundler to ensure that earlier transactions executed within a block do not clash with any UserOperations and cause them to fail. Block builders must place the bundle as the first transaction within a block or use other strategies to properly verify the contents of UserOperations.

4. There is a potential for Paymasters to invalidate several UserOperations at once causing unnecessary stress to the EntryPoint contract responsible for validating UserOperations. To prevent this denial of service (DoS) attack vector, paymasters are required to either put up stake, the exact amount is defined by the bundler software implementation, or

   limit their storage capabilities such that the UserOperations they can support is restricted to only those they can access within their own storage bounds.

5. The components of ERC 4337 are not based on new technology. Individual wallet services such as Argent have implemented a version of the above transaction execution workflow to support complex transaction execution logic for user transactions since 2018. However,

   the innovation of ERC 4337 is its standardization of gas accounting and payment, as well as the creation of a separate mempool that is DoS-resistant and permissionless. ERC 4337 has been adopted as the standard for account abstraction on several protocols beyond Ethereum including Starknet, Optimism, Arbitrum, Avalanche, BNB Smart Chain, and Polygon.

Benefits

ACs have the potential to revolutionize transaction execution on Ethereum and other participating general-purposes blockchains and L2s. Once created, ACs can interact with smart contracts, that is dapps, to execute transactions through sending a signed message that validates the ACs rights to move user assets. ERC 1271 is the accompanying standard to ERC 4337 for dapps to utilize when interacting with ACs. Instead of requesting that authorization to initiate a transaction comes from a user’s private key, a dapp that supports AA will rely on ERC 1271 to validate signed messages from ACs. This unlocks a host of new use cases for user transactions including:

1. Tailored control over a user’s assets: An AC may have a signed message that dapps can validate that allows them to move certain assets, or assets up to a certain limit that ensures even in the event of a potential exploit of a user’s AC, their entire account balance is never in jeopardy or at risk of being stolen.

2. Ability to halt asset flows in the event of a hack: Conversely, an AC may have the embedded logic of halting movement of funds if certain withdrawals limits are exceeded.

3. Improved user experience for recurring or frequent transactions: For certain on-chain games and DeFi applications, users are required to submit multiple transactions. ACs may be programmed to automatically allow transactions with certain dapps so that users can avoid having to authorize interactions with the same smart contract repeatedly using their private key.

4. Support social recovery of private keys: An AC can also be designed to rely on a user’s private key and other social recovery devices to move funds. In the event that a user loses their private key, the AC may be programmed to regenerate a new key using 2 out of 3 or 3 out of 5 other social recovery devices.

According to analysis by Ethereum wallet service Argent and other sources, roughly 60% to 70% of dapps on Ethereum are ERC 1271 compatible.

Outlook

The launch of the EntryPoint contract was a major milestone for the development of AA on Ethereum mainnet. However, the standards for using EntryPoint are still actively under development and subject to change. Rather than a protocol-level code change, ERC 4337 is an evolving standard for using an alternative workflow for submitting user transactions. The adoption of ERC 4337 is in a causality dilemma because wide adoption of the standard by end-users would create the opportunity for high revenues for bundlers and thereby, cause an influx of new bundlers. However, there is also no financial incentive for the rise of bundlers unless there already exists many users sending UserOperations.

Additionally, one of the other barriers to adoption is the fact that ERC 4337 necessitates alternative mempools from the Ethereum mempool, which will make tooling and analysis around UserOperations activity more complex and convoluted. Companies like JiffyLabs and Blocknative are working on dedicated tools and explorers to track UserOperations from initiation to execution.

UserOperations are also on average more costly for users. The primary reason most UserOperations are more expensive than regular Ethereum transactions from an EOA is because smart contract operations on-chain in general are more expensive than vanilla transactions involving strictly ETH. If it is a user’s first UserOperation, they must create a new AC, which costs gas, and depending on the configuration of the AC, the account may be initiating interactions with several tokens or dapps, which would cost the user anyways to initiate directly from an EOA but doing it through the ERC 4337 frameworks creates additional overhead costs absorbed by the bundler, paymaster, and sometimes user.

According to data from Dune, the total number of ACs created on Ethereum as of March 26, 2024 is 4,830. The number of successful UserOps executed on-chain since March 2023 is 36,332 and the amount of bundler revenue generated from these UserOps over the same period roughly 30.5 ETH. On other protocols where transaction fees are comparatively lower than Ethereum, UserOperations activity is comparatively higher, especially on Polygon. See the figure below:

The following are three key areas of development needed for broader adoption of the ERC 4337 standard:

1. Monitoring tools: Once the ERC 4337 mempool is launched on Ethereum, ERC 4337 mempool explorers and other robust tools for tracking UserOperation activity will be important for supporting wider adoption of AA.

2. Standards for UserOperations: Adding additional code complexity to the execution of user transactions can result in greater opportunity for bugs and exploits. Standards for certain types of commonly used user operations will further the adoption of specific AA use cases.

3. Inclusion lists and censorship-resistance mechanisms: Like the risks of centralization that exists for third-party block builders on Ethereum due to the specialized nature of these actors’ role, there is the risk of maximal extractable value (MEV) centralizing the role of bundlers. As the adoption of AA grows, it will be important for the ERC 4337 standard to specify ways to combat the centralizing effects of MEV through inclusion lists or other censorship-resistance mechanisms.

One of the main strengths and weaknesses of ERC 4337 is the fact that it does not change the protocol of Ethereum. This is a strength because the development of ERC 4337 as the standard for AA among EVM-compatible chains does not depend or rely on the effort and consensus of Ethereum core developers. Ethereum core developers are an amorphous group of researchers and programmers that work on the protocol of Ethereum are infamously slow-moving and juggling several competing priorities and code agendas. The fact that ERC 4337 can be developed independently from this group means that updates to its code can be shipped faster.

The Road to Native AA on Ethereum

However, the fact that ERC 4337 is an independent protocol from Ethereum is also a weakness as it limits the adoption of this standard. Without a protocol level change, the adoption of ACs is heavily dependent on dapp developers updating their smart contracts to request signed messages as valid forms of user authentication rather than a signature from the private key of an EOA. ACs are the default type of user account on protocols like Starkware where AA is natively supported. This has a number of benefits including the fact that all dapps are compatible with AA and support native batching of user transactions from ACs.

To better support the adoption of AA on Ethereum directly, there are a handful of EIPs that have been proposed in recent months that would make minor changes to the protocol of Ethereum.

• EIP 3074: Proposed by Ethereum core developers lightclient, Ansgar Dietrichs, Micah Zoltu, and Sam Wilson, this EIP creates two new EVM instructions for delegating control of an EOA to a smart contract. Though this has been a longstanding EIP proposed in 2020, it remains a controversial one that is presently being debated by Ethereum core developers for inclusion in the Prague/Electra upgrade.

• EIP 7664: Proposed by pseudonymous OP Labs developer “Protolambda”, this EIP was presented on a recent All Core Developers (ACD), All Core Developers Execution Call (ACDE) #184, on March 28, 2024, as a better alternative to EIP 3074 that offers additional functionalities.

• EIP 5806: Proposed by Hadrien Croubois, a blockchain engineer at OpenZeppelin, this EIP creates a new transaction type that would allow EOAs to execute arbitrary code using a delegate call-like mechanism. Delegate call is a smart contract opcode on Ethereum that allows a contract to execute code from another contract. Applying this functionality to EOAs would improve the programmability of EOAs by allowing EOAs to have more control over what operations of a contract to execute. Through EIP 5806, an EOA could make a call to another contract that then triggers multiple transactions through one initial transaction. Like EIP 3074, this EIP is presently being debated by Ethereum core developers for inclusion in the Prague/Electra upgrade.

• EIP 7377: Proposed by Geth developer and EIP editor Matt Garnett, who also goes by the pseudonym “lightclient”, this EIP creates a new transaction type to help migrate assets in an EOA to an AC using a one-time transaction. If a user has multiple assets in an EOA, it is difficult to migrate these assets to a new address individually. Therefore, the creation of a transaction type that can securely migrate all assets in an EOA to an AC in one simple action would greatly improve the user experience and expedite adoption of AC wallets. Like EIP 3074 and 5806, this EIP is presently being debated by Ethereum core developers for inclusion in the Prague/Electra upgrade. However, of the three EIPs, EIP 7377 is considered the least controversial among core developers.

• EIP 6900: Proposed in partnership between developers at Alchemy and the Ethereum Foundation, this EIP proposes new standards for smart contract and AC plugins. Plugins contain the execution logic for UserOps, as well as validation schemes that define the circumstances under which an AC will approve actions taken on its behalf. These plugins also can contain hooks which allow for pre- and post-execution controls. Adopting such standards for plugins into ACs will help support highly modularized and upgradeable transaction execution logic, as well as enhance wallet and dapp interoperability.

• EIP 7553: Proposed by Nethermind client developer Tomasz. K. Stańczak and Ethereum Foundation Researcher Ansgar Dietrichs, this EIP creates a new transaction type that separates the roles of transaction sender and payer. The EIP is a narrower version of a prior proposal, EIP 2711, that aims to enable sponsored transactions, that is transactions where the fee is paid for by a third party.

EIP 5806 and 6900 were presented on All Core Developers Execution (ACDE) Call #167 in early August 2023. Though beneficial for the adoption of AA on Ethereum, developers on the call pushed back on implementing AA-related protocol changes before having a roadmap in place to eventually adopt AA fully into the Ethereum protocol. “These are interesting solutions that open up interesting design space but I think we should take a step back and think if we’ll be served better by deliberate design toward account abstraction,” said Danno Ferrin, Swirlds Labs engineer and Besu client maintainer.

Developers were hesitant about committing to AA-related EIPs in the next planned Ethereum hard fork given competing priorities for other important initiatives like Verkle trees, enshrined proposer builder separation, single slot finality, and full danksharding. However, the topic of AA was brought up again on ACDE #178 where developers expressed more enthusiasm at the idea of implementing simple EIPs related to AA such as EIP 7553 in the Prague/Electra upgrade. More recently, the first three EIPs listed above were discussed in detail on ACDE #182. Developers debated the comparative advantages and disadvantages between the three proposals. Finally, on the most recent ACD call, ACDE #184, OP Labs developer Protolambda presented a new version of EIP 3074 for consideration in Prague/Electra.

Based on ongoing discussions around AA for Ethereum, the technology is a desired goal for all Ethereum developers but one of many that will need several months if not years of discussion to create consensus on a roadmap for, alongside other competing priorities for the protocol. Therefore, it is likely that ERC 4337 will be more widely adopted as a standard that does not touch the protocol of Ethereum in the short-term. Over the medium to long-term, as the Layer-2 (L2) rollup ecosystem of Ethereum matures, ERC 4337 and other AA-related EIPs proposed for Ethereum are more likely to be quickly adopted on these protocols that are comparatively more flexible than Ethereum. As the scalability of Ethereum depends on rollups and Ethereum evolves into functioning as a data availability layer for rollups, it is expected that more end-users will transact on L2s rather than Ethereum directly.

Conclusion

ERC 4337 is an important and evolving standard designed to introduce AA to Ethereum without changing the network’s core protocol. More importantly, it is a standard for AA that can be adopted by EVM-compatible protocols outside of Ethereum and L2s. The innovation of ERC 4337 is the way it offers a single strategy for gas accounting and transaction payment to bundlers and paymasters that wallets and dapps can coalesce around. Additionally, ERC 4337 offers a standard inspired by third-party block building to support permissionless bundling of UserOperations through an alternative mempool that anyone can in theory submit transactions to and earn revenue from if they operate a bundler. The adoption of ERC 4336, while slow on Ethereum, has been embraced by other protocols; especially L2s such as Polygon, Arbitrum, Optimism, StarkNet, and recently, Base. There are protocol-level changes on Ethereum that AA developers have proposed to expedite the adoption of ERC 4337 on Ethereum but given competing priorities, it is unclear whether these EIPs will be implemented in the next immediate Ethereum upgrade, Prague/Electra. The adoption of ERC 4337 and AA-related EIPs mentioned in this report will likely be most embraced on L2s and new EVM-compatible chains that are quicker to activate protocol changes. AA on Ethereum remains an area of active research and development that will likely undergo a few more iterations before developers settle on a more hardened roadmap forward for supporting the technology.