What is Account Abstraction?
Exploring new techniques for blockchain payment processing.
Written by Mustafa Bedawala, Mert Ozbay, and Catherine Gu. Acknowledgement to Cuy Sheffield, Andrew Beams, Mahdi Zamani, Mohsen Minaei, Aaron Salot, and John Rising, co-founder of Stackup, for their review.
Despite ongoing advancements, blockchains currently struggle to offer the same level of flexibility and user experience found in the mainstream digital payments ecosystem. Emerging technologies, however, can enhance the payments experience when transacting in digital currencies. In "Auto Payments for Self-Custodial Wallets," we delved into the application of cutting-edge technology to automate payments by leveraging the concept of Account Abstraction (AA) on public blockchains.¹ Our exploration of AA and improved crypto payment experiences continues to look at how the current AA paradigm on Ethereum offers creative solutions to dealing with transaction fees: Can users pay Ethereum transaction fees with stablecoins, other ERC-20 tokens or not pay them at all? Finding innovative solutions to enable frictionless crypto onboarding and transaction experiences will be crucial before digital currencies earn mainstream adoption.
This technical overview of ERC-4337, the current standard for AA implementation on Ethereum, is aimed at gaining a better understanding of ERC-4337. We discuss Visa's experimental deployment of two sets of Paymaster contracts to demonstrate how gas fees on the blockchain can be redesigned for enhanced user convenience.
Account Abstraction and ERC-4337
To better understand Account Abstraction’s value proposition, let's briefly review the two types of accounts that currently exist on Ethereum: Externally Owned Accounts (EOAs) and Contract Accounts (CAs), commonly referred to as user accounts and smart contracts, respectively. EOAs, which are controlled by private keys, allow users to send transactions. However, they lack the programmability of a smart contract, making them more rigid. In contrast, CAs possess executable code but are unable to initiate transactions independently. Transactions must always come from a user's account and contain the user's signature, whether it’s a simple token transfer or a complex operation executed through many smart contracts.
The concept of Account Abstraction (AA) seeks to capitalize on CA programmability for the benefit of end users. When writing a smart contract, it has been common practice to define an owner, who has control over the contract's behavior. A self-custodial wallet built as a smart contract can offer more functionalities to a user than an EOA-based wallet. This is enabled through the introduction of a new Ethereum standard known as ERC-4337, proposed by members of the Ethereum community, including Ethereum founder Vitalik Buterin.² ERC-4337 makes it possible for an owner to directly own smart contract accounts without the need for an EOA signature. Although an owner might not use an EOA signature in the traditional sense, their ownership of a smart contract still requires a secure authentication process to ensure they properly control and manage the smart contract account. In turn, this smart contract account can handle tasks like multi-factor authentication, recurring payments and custom rules and policies defined by the end user.
ERC-4337, the latest advancement in AA, was initially proposed as an Ethereum Improvement Proposal (EIP)-4337 in 2021. It underwent the Ethereum Request for Comment (ERC) process, which establishes standards for applications on the Ethereum network. The difference between an EIP and an ERC lies in their scope and adoption requirements. ERCs define how smart contracts should function and interact with each other at the application level. They do not require adoption by all participants like core EIPs (Ethereum Improvement Proposals), which are deployed at the protocol level and necessitate broader consensus within the community. As of March 2023, core components of ERC-4337 have been deployed on the Ethereum mainnet. Unlike previous Account Abstraction EIPs, ERC-4337 enables Account Abstraction on the Ethereum network without the need for consensus-layer modifications of the blockchain protocol.² This development allows blockchain network participants to explore and experiment with new user experiences immediately, without waiting for a major network upgrade. Notably, one of ERC-4337's advantages is its compatibility with any blockchain utilizing the Ethereum Virtual Machine, offering a standard for AA that extends beyond Ethereum itself.
Walking through an ERC-4337 transaction
Figure 1: Typical Ethereum transaction flow
ERC-4337 introduces an alternative transaction flow that diverges from the traditional EOA approach by adding new steps before transactions reach a proxy EOA address. Users send their intent as UserOperations, which are then disseminated through a dedicated UserOperations mempool. This distinct mempool is monitored by Bundlers, which act as proxy EOAs, bundling the UserOperations and sending them to block builders in the form of typical EOA transactions that the network can process. Alternatively, if the bundler is a block builder, it can include the bundle directly in the block it's building.
We walk through an end-to-end flow for an ERC-4337 transaction step by step, from UserOperation generation to execution. Before diving in, it is essential to define the concept of a Paymaster, which plays a crucial role in this process and is central to our own exploration. A Paymaster is an optional smart contract account capable of sponsoring transaction fees for Contract Accounts (user-centric smart contracts). Paymasters assess whether to accept a UserOperation during the verification stage and implement any required fee logic during the execution phase. By doing so, they can sponsor transaction fees for users and enable users to pay for gas in ERC-20 tokens, like dollar stablecoins.
Figure 2: ERC-4337 transaction flow
- Users generate UserOperations through ERC-4337-compliant smart contract wallets. UserOperations encapsulate the user’s intent to interact with the blockchain and the user signs them for authentication. Once generated, the UserOperation is submitted to the dedicated UserOperation Mempool, a specialized storage for UserOperations separate from the standard Ethereum transaction mempool.
- Bundlers, a specialized class of actors, monitor the UserOperation Mempool, run simulations and assemble an array of UserOperations into a single transaction bundle. Bundlers are responsible for collecting UserOperations and submitting them to the EntryPoint contract, optimizing gas usage and maximizing profit by leveraging fee-prioritization logic.
- The EntryPoint contract receives the bundled batch of UserOperations. It acts as a central coordinator for managing UserOperations within the ERC-4337 transaction flow.
- The EntryPoint contract interacts with a Paymaster contract if specified by the UserOperation. As mentioned earlier, Paymasters can sponsor transaction fees for Contract Accounts. The EntryPoint verifies whether the Paymaster has a sufficient deposit or if the Contract Account holds enough funds to cover gas fees. During execution, if a Paymaster is involved, it can implement custom fee logic, which we will demonstrate in the next section.
- The EntryPoint contract then calls the Contract Account and, if necessary, the Paymaster, to validate the signatures in the UserOperation. Contract Accounts are the user accounts that seamlessly interact with the EntryPoint contract to facilitate transaction execution. Upon successful verification, the EntryPoint transmits the relevant data from each UserOperation to the Contract Account, initiating the execution process.
Account Abstraction and real-world applications
Paying with ERC-20 tokens using ERC-4337 Paymaster
Figure 3: Paymaster facilitating the use of ERC-20 tokens for transaction fees
Sponsoring transaction fees for users with ERC-4337 Paymaster
Figure 4: Paymaster sponsoring transaction fees for users
P2P transactions in today's Web 2.0 are free of charge for consumers in many countries, which raises the immediate question: Why should consumers pay for P2P transactions on the blockchain? Account Abstraction offers a solution by allowing users to bypass these costs if a third party, such as a fintech wallet provider, is willing to cover them. In this case, the wallet provider or dApps can act as Paymasters, covering gas fees for users and significantly reducing friction. The ERC-4337 Paymaster concept can be a potential way to incentivize user adoption by making it free for users to transact through their wallet platform.
Beyond these, smart contract accounts can simplify wallet management and provide alternative approaches to signature verification, which enable multi-factor authentication for improved security and fund recovery for self-custodial wallets. Moreover, they streamline dApps usage by allowing temporary permissions for specific tasks with customizable limits, such as authorizing dApps to process recurring pull payments from user accounts up to a certain amount. These examples are just an illustration of how smart contracts can help non-crypto native users interact with blockchain technology more easily while keeping their accounts secure.
Our experiments with ERC-4337 Paymaster implementation
Our team at Visa has deployed experimental Visa Paymaster contracts on Ethereum's Goerli Testnet to validate the use cases we discussed earlier.
Paying with ERC-20 tokens using ERC-4337 Paymaster
Figure 5: Paymaster facilitating the use of ERC-20 tokens for transaction fees (code snippet)
With our first Visa Paymaster contract, we are exploring whether a user can pay transaction fees with alternative tokens, such as a dollar stablecoin or, in the future, even a Central Bank Digital Currency. In this scenario, the Paymaster pays the transaction fee in ETH by receiving an equal value amount of a generic ERC-20 token paid by the user. For the implementation, we used the starter code ⁶ provided by the Ethereum Foundation and the ERC-4337 core team. This sample contract contains the governing logic for both the Paymaster and its custom ERC-20 token. To this contract, we introduced an allowlist and a function to update the token-to-ETH conversion rate. This allowed us to better simulate real-life conditions where the exchange rate between ETH and a token is dynamic. Our test setup involved deploying a smart contract wallet and sending user operations. Currently, ERC-4337-compatible wallet options are limited, and we decided to use Trampoline Wallet built by the Ethereum Foundation and ERC-4337 core team.⁷ To send our user operations to the Goerli Testnet, we used Blocknative’s public Bundler.⁸ For a successful UserOperation, the Visa Paymaster contract first needs to check that the user has sufficient funds in ERC-20 to pay for the gas fee. Once confirmed, the user pays transaction fees with this generic ERC-20 token. You can find our deployed contract here,⁹ and a processed UserOperation here.¹⁰
Sponsoring transaction fees for users with ERC-4337 Paymaster
Figure 6: Paymaster sponsoring transaction fees for users (code snippet)
Our other Visa Paymaster contract completely sponsors transaction fees in accordance with the second use case we mentioned. Again, our implementation is based on starter code¹¹ provided by the Ethereum Foundation and ERC-4337 core team. The starter code sponsors every transaction without any compensation. We added an allowlist to let only authorized users interact with the Visa Paymaster contract. You can find our deployed contract here.¹² Our test implementation was able to successfully sponsor user operation transaction fees of allowlisted users. You can check out a successful UserOperation here.¹³
Paymaster use cases go far beyond what we've highlighted in this article. There can be many innovative user experiences by abstracting away the basic blockchain processing logic. We see several possible ways of building upon our above experiments for the current ongoing development of ERC-4337. For instance, instead of requiring a custom new ERC-20 token that is built into the Paymaster smart contract, it would be ideal to easily integrate a Paymaster with an existing ERC-20 token, such as USDC. Such an approach would require using an external source to determine token price and checking if the Paymaster contract has approvals to charge the user for the specified token. One method is to deploy an off-chain oracle service that can provide necessary information like token price, along with a signature that the Paymaster contract can verify.
Alternatively, the entire flow can be handled on-chain with the help of an oracle contract for necessary data. While this approach is better at guaranteeing that the Paymaster is compensated appropriately, it is also more challenging to implement. Some ERC-4337 restrictions make it difficult for the Paymaster to query an on-chain oracle during Paymaster validation, and Bundlers will normally reject UserOperations that require this. To enable this flow, it is necessary to establish alternative mempools with a list of trusted Paymasters, which the Bundlers can choose to join in. These trusted Paymasters could call the oracle contract, and the UserOperations that utilize these Paymasters would get picked up from the alternate mempools.
Looking forward
Using digital wallets to interact with blockchains can be a challenging experience, and many believe that ensuring ease of use is a critical step to drive greater adoption. ERC-4337 lays down interesting future possibilities for improving on-chain user payments experience through a self-custodial smart contract wallet, which can in turn transform the way users engage with digital currencies and digital assets.
When it comes to ERC-4337, the Ethereum community is at the beginning of this new journey. There are many initiatives to provide the infrastructure over which AA-powered flows can be built, some of which we used in our tests and mentioned in this piece, but there is considerable room for growth. As with any open field, there are competing approaches and tradeoffs, such as the option of decentralization offered by public Bundlers against the customizability of a private Bundler; the trustless security of an entirely on-chain Paymaster against the cost-effectiveness of deploying some components off-chain; and the numerous alternative signature schemes a wallet may utilize, among many others. These different design choices can give rise to an enriched set of options that better service the users in their future digital payments experience.
Payment Innovations for Everyone, Everywhere
As a global leader in payment solutions, Visa consistently strives to explore innovations that cater to real-world needs. We continue to investigate the potential of smart contracts and the future that programmable money and programmable payments may enable. In this article, we delved into how AA on Ethereum, carried through by ERC-4337, can support interesting new use cases on top of the blockchain. We provided an end-to-end walkthrough of an ERC-4337 transaction and explained its differences from standard Ethereum transactions to highlight the underlying mechanics.
Our experiments with ERC-4337 focused on two different use cases by deploying Paymaster contracts to learn and evaluate their potential utility in addressing real-world problems and critically enhancing customer experiences with on-chain interactions. For companies working on this forefront, our product, research and engineering teams will be happy to discuss ideas in programmable payments.
Reach out to Visa Crypto at GDLVisaCryptoResearch@visa.com to learn more about our research interests and activities in the crypto ecosystem.
This document is intended for illustrative purposes only. It contains depictions of a product in development and should be understood as a representation of the potential features of the fully deployed product. The final version of this product may not contain all of the features described in this presentation.
In our writing, we adhere to a clear distinction between conceptual terms such as entry point, paymaster, and user operation, and their corresponding on-chain entities EntryPoint, UserOperation, and Paymaster. This approach follows the conventions set forth in the original ERC-4337 proposal.
Notes
- “Auto Payments for Self-Custodial Wallets.” | Visa. Accessed May 10, 2023.
- “ERC-4337: Account Abstraction Using Alt Mempool.” | Ethereum Improvement Proposals. Accessed May 10, 2023.
- "Ethereum Unique Addresses,” estimated by Visa Crypto using public database with Dune Analytics | https://dune.com/queries/2280349. Accessed May 10, 2023.
- "On-Chain activity,” estimated by Visa Crypto using public database with Dune Analytics | https://dune.com/queries/2333459/3820070. Accessed May 10, 2023.
- Visa Annual Report 2022
- Starter code provided by the Ethereum Foundation and the ERC-4337 core team for Token Paymaster
- Trampoline Wallet GitHub Repository
- ERC-4337 Bundler on Goerli by Blocknative
- Visa Token Paymaster deployed contract
- Blocknative ERC-4337 UserOps Explorer | Sample UserOperation for Token Paymaster Test
- Starter code provided by the Ethereum Foundation and the ERC-4337 core team for Sponsor Paymaster
- Visa Sponsor Paymaster deployed contract
- Blocknative ERC-4337 UserOps Explorer | Sample UserOperation for Sponsor Paymaster Test
Further reading suggestions
- “Unified ERC-4337 Mempool.” Unified ERC-4337 Mempool | Ethereum Notes. Accessed May 10, 2023.
- The Road to Account Abstraction. “ The Road to Account Abstraction | Ethereum Notes. Accessed May 10, 2023.
- " ERC 4337: Account Abstraction without Ethereum Protocol Changes.” ERC 4337: Account Abstraction without Ethereum Protocol Changes | Infinitism Medium Blog. Accessed May 10, 2023.