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

In a typical EOA transaction, users interact with their self-custodial wallets to create, sign and submit transactions to the public mempool. The transaction payload, generated and signed with the user's private key, is then propagated to the peer-to-peer (P2P) mempool via a node. Validators or specialized entities, known as builders, select suitable and profitable transactions from the public mempool to execute and incorporate into the blockchain.

Figure 1: Typical Ethereum transaction flow

Typical Ethereum transaction flow. See image description for more details.

Users create, sign, and submit transactions using self-custodial wallets, which are then sent to the public mempool. The signed transaction payload is propagated through the P2P mempool via nodes. Validators or builders select profitable transactions from the mempool for execution and incorporation into the blockchain.

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

ERC-4337 transaction flow. See image description for more details.

The image illustrates the process of how ERC-4337 adds a User Intent Layer before transactions reach a proxy EOA address and are sent through the network. Users submit their intentions as UserOperations, which then get disseminated into a dedicated UserOperations mempool. This separate mempool is monitored by Bundlers, which function as proxy EOAs. Bundlers convert UserOperations into signed transactions that can be processed by the network.

  1. 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.
  2. 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.
  3. The EntryPoint contract receives the bundled batch of UserOperations. It acts as a central coordinator for managing UserOperations within the ERC-4337 transaction flow.
  4. 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.
  5. 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 

As blockchain technology continues to explore real-world applications, self-custodial wallets are becoming a popular choice for users to hold and transact with their digital currencies. Since Ethereum’s inception, there have been around 180 million unique addresses that have transacted, including all types of accounts and multiple accounts belonging to the same individual or group of individuals.³ However, monthly, we only see a few million on-chain interactions initiated by real humans, and daily Ethereum mainnet on-chain activity is around 1 million transactions per day.⁴  In comparison, Visa processed 258 billion transactions in 2022, averaging 707 million transactions daily, and there are currently 4.1 billion Visa-linked cards in circulation worldwide.⁵ Can blockchains enjoy comparable levels of adoption if they support an equivalent breadth of payment experiences with the same level of ease? Possible steps in this direction include abstracting gas fees for users or allowing them to pay transaction fees in ERC-20 tokens. 

Paying with ERC-20 tokens using ERC-4337 Paymaster

Figure 3: Paymaster facilitating the use of ERC-20 tokens for transaction fees

Paymaster facilitating the use of ERC-20 tokens for transaction fees. See image description for details.

The image illustrates a scenario where users want to make purchases on merchant websites, intending to transfer $100 but only have ERC-20 tokens (e.g., USDC) in their wallets. In this situation, a Paymaster contract serves as an intermediary, accepting USDC as transaction fees from the user, paying ETH as transaction fees to the blockchain, and enabling the merchant to receive payment in an ERC-20 token like USDC. This significantly reduces friction for users, as they no longer need to hold native tokens exclusively for paying gas fees.

To transact on Ethereum blockchain today, a user needs to acquire ETH to pay for gas fees; similarly, to transact on Polygon blockchain, a user needs to acquire the native token MATIC. Is there a solution that eliminates the need to accumulate a different range of native blockchain tokens solely for the purpose of paying for gas? This situation is analogous to the value of Visa's core network with cross-border payments, where travelers can spend in local currency without having to acquire it first. In this version of the Paymaster contract, the contract can act as an intermediary currency conversion service. The service can collect the digital currencies from the user and then convert them into native tokens based on the current exchange rate to pay for gas fees on the user’s behalf. Moreover, this can be done with just-in-time funding, meaning the user is required to only fund the gas cost at the time of the transaction without any pre-funding requirements to optimize their cash-flow management. 

Sponsoring transaction fees for users with ERC-4337 Paymaster 

Figure 4: Paymaster sponsoring transaction fees for users

Paymaster sponsoring transaction fees. See image description for details.

The image depicts a scenario in which users want to make a $100 purchase on a merchant's website, but their wallets only contain ERC-20 tokens (e.g., USDC). A Paymaster service can step in as a "gas station" to sponsor the transaction fees for the user. This allows the merchant to receive payment in the form of an ERC-20 token like USDC, creating a seamless process for the user.

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)

Paymaster facilitating the use of ERC-20 tokens for transaction fees (code snippet). See image description for details.

Once the user operation is completed, whether successful or failed, the Paymaster charges the user with the custom token equivalent of the ETH gas cost. This process enables users to pay transaction fees using ERC-20 tokens instead of native tokens like ETH. The Paymaster acts as an intermediary, collecting ERC-20 tokens from users and paying ETH to the blockchain for transaction facilitation. Snippet provided is from ERC-4337 core team's implementation under GPL-3.0 license (https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/samples/TokenPaymaster.sol), 2023. https://www.gnu.org/licenses/gpl-3.0.en.html.

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)

Paymaster sponsoring transaction fees for users (code snippet). See image description for details.

This snippet checks if the user (i.e., smart contract account address) is authorized to use Paymaster and raises an error if it isn't. If no error is thrown, transaction flow continues, and Paymaster pays for the gas fee. Snippet provided is based on ERC-4337 core team's sample contract under GPL-3.0 license (https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/test/TestPaymasterAcceptAll.sol), 2023. Visa Copyright, 2023. https://www.gnu.org/licenses/gpl-3.0.en.html.

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 [email protected] 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

 Further reading suggestions