Visa: Rethinking Crypto Transactions From Account Abstraction

Finding innovative solutions to enable a frictionless crypto trading experience is critical until digital currencies gain mainstream adoption.

Written by: Mustafa Bedawala, Mert Ozbay and Catherine Gu

Compilation: GWEI Research

Despite continuous progress, blockchain is currently struggling to provide the same level of flexibility and user experience as mainstream digital payment ecosystems. However, emerging technologies can enhance the payment experience when transacting with digital currencies. In Automated Payments for Self-Hosted Wallets, we delve into the application of cutting-edge technology to automated payments by leveraging the concept of Account Abstraction (AA) on public blockchains. ¹Our exploration of AA and an improved crypto payment experience continues with a look at how the current AA paradigm on Ethereum offers creative solutions to handling transaction fees: Users can use stablecoins, other ERC-20 tokens to pay for Ethereum transaction fees , or don't pay at all? Finding innovative solutions to enable a frictionless crypto onboarding and trading experience is critical until digital currencies gain mainstream adoption.

A technical overview of ERC-4337, the current standard for AA implementations on Ethereum, aims to better understand 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 to improve user convenience.

Account abstraction and ERC-4337

To better understand the value proposition of account abstraction, 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 . EOA, controlled by a private key, allows users to send transactions. However, they lack the programmability of smart contracts, making them even more inflexible. In contrast, CAs possess executable code but cannot independently initiate transactions. Transactions must always originate from the user's account and contain the user's signature, whether it is a simple transfer of tokens or a complex operation performed through many smart contracts.

The concept of Account Abstraction (AA) aims to leverage the programmability of CAs to the benefit of end users. When writing a smart contract, it is common practice to define an owner to control the behavior of the contract. Self-hosted wallets built as smart contracts can provide users with more functionality than EOA-based wallets. This is achieved through the introduction of a new ethereum standard called ERC-4337, proposed by members of the ethereum community, including ethereum founder Vitalik Buterin. ² ERC-4337 enables the owner to directly own the smart contract account without EOA signature. While the owner may not sign the EOA in the traditional sense, their ownership of the smart contract still requires a secure authentication process to ensure they are properly controlling and managing the smart contract account. In turn, this smart contract account can handle tasks such as multi-factor authentication, recurring payments, and custom rules and policies defined by end users.

ERC-4337 is the latest development of AA, originally proposed in 2021 as Ethereum Improvement Proposal (EIP)-4337. It went through the Ethereum Request for Comments (ERC) process, which establishes standards for applications on the Ethereum network. The difference between EIPs and ERCs is their scope and adoption requirements. ERC defines how smart contracts should run 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 require broader consensus within the community. The transition from EIP-4337 to ERC-4337 marks that the proposal has met the standards required for Ethereum applications and is now officially part of the Ethereum ecosystem. As of March 2023, the core components of ERC-4337 have been deployed on the Ethereum mainnet. Unlike previous account abstraction EIPs, ERC-4337 requires no modifications to the consensus layer of the blockchain protocol to enable account abstraction on the Ethereum network. ² This development allows blockchain network participants to immediately explore and experiment with new user experiences without waiting for major network upgrades. It is worth noting that one of the advantages of ERC-4337 is that it is compatible with any blockchain using the Ethereum virtual machine, providing AA with a standard beyond Ethereum itself.

Traverse ERC-4337 transactions

In a typical EOA transaction, users interact with their self-hosted 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 through the nodes to a peer-to-peer (P2P) mempool. Validators or specialized entities (called builders) select suitable and profitable transactions from a public mempool to execute and incorporate them into the blockchain.

Figure 1: Typical Ethereum transaction process

ERC-4337 introduces an alternative transaction process to the traditional EOA method by adding a new step before the transaction reaches the proxy EOA address. Users send their intents as UserOperations, which are then propagated through a dedicated UserOperations mempool. This unique mempool is monitored by the bundler, which acts as a proxy EOA, sending UserOperations to the public mempool in the form of typical EOA transactions that the network can handle. These transactions then follow the same flow as regular transactions, either joining the public mempool or going directly to the builders.

We step-by-step introduce the end-to-end process of an ERC-4337 transaction, from UserOperation generation to execution. Before diving in, it is imperative to define the concept of a teller, which plays a vital role in this process and is at the heart of our own exploration. Paymaster is an optional smart contract account that can sponsor transaction fees for contract accounts (user-centric smart contracts). Paymasters evaluates whether the UserOperation is accepted during the validation phase and implements any required fee logic during the execution phase. By doing this, they can sponsor transaction fees for users and enable users to pay for gas using ERC-20 tokens such as USD stablecoins.

Figure 2: ERC-4337 transaction process

1. The user generates UserOperations through the smart contract wallet that complies with the ERC-4337 standard. UserOperations encapsulate the user's intent to interact with the blockchain, which the user signs for authentication. Once generated, UserOperations are committed to the dedicated UserOperation Mempool, a storage dedicated to UserOperations separate from the standard Ethereum transaction mempool.

2. Bundlers are a specialized class of actors that monitor the UserOperation Mempool, run simulations and assemble a series 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 utilizing fee-first logic.

3. The EntryPoint contract receives a bundle of UserOperations. It acts as a central coordinator for managing UserOperations in the ERC-4337 transaction flow.

4. If UserOperation is specified, the EntryPoint contract will interact with the Paymaster contract. As mentioned earlier, Paymasters can sponsor contract account transaction fees. EntryPoint verifies that the payer has sufficient deposits, or that the contract account has sufficient funds to pay for gas. During execution, if Paymaster is involved, it can implement custom fee logic, which we demonstrate in the next section.

5. The EntryPoint contract then calls the contract account and, if necessary, the teller to verify the signature in the UserOperation. Contract accounts are user accounts that seamlessly interact with the EntryPoint contract to facilitate transaction execution. After the verification is successful, EntryPoint transfers the relevant data of each UserOperation to Contract Account and starts the execution process.

Account abstraction and practical application

As blockchain technology continues to explore real-world applications, self-custodial wallets are becoming a popular option for users to hold and transact with their digital currencies. Since the inception of Ethereum, approximately 180 million unique addresses have transacted, including accounts of all types and multiple accounts belonging to the same individual or group of individuals. ³However, each month, we only see millions of on-chain interactions initiated by real people, with daily on-chain activity on the Ethereum mainnet at about 1 million transactions per day. ⁴ By comparison, Visa processed 258 billion transactions in 2022, an average of 707 million transactions per day, and there are currently 4.1 billion Visa-linked cards in circulation globally. ⁵ Could blockchains enjoy comparable levels of adoption if they supported the same breadth of payment experiences with the same ease of use? Possible steps in this direction include withdrawing gas fees for users or allowing them to pay transaction fees in ERC-20 tokens.

Use ERC-4337 Paymaster to pay with ERC-20 tokens

Figure 3: Paymaster facilitates payment of transaction fees using ERC-20 tokens

To conduct transactions on the Ethereum blockchain today, users need to obtain ETH to pay for gas fees; similarly, to conduct transactions on the Polygon blockchain, users need to obtain the native token MATIC. Is there a solution that removes the need to accumulate different ranges of native blockchain tokens just for the purpose of paying for gas? The situation is similar to the value of Visa's core network of cross-border payments, where travelers can spend in their local currency without acquiring it first. In this version of the Paymaster contract, the contract can act as an intermediary currency conversion service. The service can collect digital currency from users and then convert it into a native token based on the prevailing exchange rate to pay for gas on the user's behalf. Additionally, this can be done with instant financing, meaning users only need to fund gas costs at the time of transaction without any up-front financing requirements, to optimize their cash flow management.

Sponsor transaction fees for users using ERC-4337 Paymaster

Figure 4: Paymaster sponsors transaction fees for users

P2P transactions in Web 2.0 today are free to consumers in many countries, which raises an immediate question: why should consumers pay for P2P transactions on the blockchain? Account Abstraction provides a solution that allows users to bypass these fees if a third party (such as a fintech wallet provider) is willing to cover them. In this case, the wallet provider or dApp can act as a teller, paying gas fees for the user and reducing friction significantly. The ERC-4337 Paymaster concept can incentivize user adoption by allowing users to transact through their wallet platform for free.

Among other things, smart contract accounts can simplify wallet management and provide an alternative to signature verification, enabling multi-factor authentication for increased security and fund recovery in self-custodial wallets. Additionally, they simplify the use of dApps 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 simply illustrate 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

Use ERC-4337 Paymaster to pay with ERC-20 tokens

Figure 5: Paymaster facilitates payment of transaction fees using ERC-20 tokens (code snippet)

With our first Visa Paymaster contract, we are exploring whether users can pay transaction fees with alternative tokens, such as USD stablecoins, or even central bank digital currencies in the future. In this case, Paymaster pays ETH transaction fees by receiving the equivalent of a generic ERC-20 token paid by the user. For the implementation, we used the starting code provided by the Ethereum Foundation and the ERC-4337 core team⁶. This example contract contains the management logic for Paymaster and its custom ERC-20 token. For this contract, we introduce a whitelist and a function to update the token-to-ETH conversion rate. This allows us to better simulate real life conditions where the exchange rate between ETH and tokens is dynamic. Our test setup involved deploying a smart contract wallet and sending user actions. Currently, ERC-4337 compatible wallet options are limited, we decided to use the Trampoline wallet built by the Ethereum Foundation and the ERC-4337 core team. ⁷ To send our user actions to the Goerli Testnet, we used Blocknative's public Bundler. ⁸ For a successful UserOperation, the Visa Paymaster contract first needs to check whether the user has enough funds in ERC-20 to pay the gas fee. After confirmation, users pay transaction fees with this generic ERC-20 token. You can find our deployed contract, ⁹ and the UserOperation handled here.

Sponsor transaction fees for users using ERC-4337 Paymaster

Figure 6: Paymaster sponsors transaction fees for users (code snippet)

According to the second use case we mentioned, our other Visa Paymaster contract fully sponsors transaction fees. Again, our implementation is based on the starting code¹¹ provided by the Ethereum Foundation and the ERC-4337 core team. Origination Code sponsors each transaction pro bono. We added a whitelist to only allow authorized users to interact with the Visa Paymaster contract. You can find our deployed contract here. ¹² Our test implementation was able to successfully sponsor user action transaction fees for whitelisted users. You can see a successful UserOperation here. ¹³

The Paymaster use case goes far beyond what we've highlighted in this article. By abstracting away the basic blockchain processing logic, many innovative user experiences are possible. For the ERC-4337 development currently underway, we see several possible approaches that could build upon our experiments described above. For example, rather than requiring a custom new ERC-20 token built into the Paymaster smart contract, it would be easier to integrate Paymaster with an existing ERC-20 token such as USDC. This approach requires using an external source to determine the token price and checking that the Paymaster contract has approved charging the user for the specified token. One approach is to deploy an off-chain oracle service that can provide necessary information such as token prices, and signatures that can be verified by the Paymaster contract.

Alternatively, the entire process can be handled on-chain with the help of an oracle contract for the necessary data. While this approach provides better assurance that tellers are properly compensated, it is also more challenging to implement. Some ERC-4337 restrictions make it difficult for Paymasters to query on-chain oracles during Paymaster verification, and Bundlers will often reject UserOperations that need to do so. In order to enable this process, it is necessary to establish an alternate mempool with a list of trusted Paymasters, which the Bundler can opt into. These trusted Paymasters can call oracle contracts, and UserOperations using these Paymasters will be drawn from the backup memory pool.

Looking to the future

Interacting with a blockchain using a digital wallet can be a challenging experience, and many believe ensuring ease of use is a critical step in driving wider adoption. ERC-4337 lays out interesting future possibilities for improving the on-chain user payment experience through self-custodial smart contract wallets, which in turn could change the way users spend digital currencies and digital assets.

The Ethereum community is at the beginning of this new journey when it comes to ERC-4337. There are many plans to provide the infrastructure on which AA-driven streams can be built, some of which we used in our testing and mentioned in this article, but there is still considerable room for growth. As with any open field, there are competing approaches and trade-offs, such as the decentralization options offered by public Bundlers versus the customizability of private Bundlers; the trustless security of Paymaster entirely on-chain versus deploying some components compared to cost-effectiveness; and the multitude of alternative signature schemes that wallets may use, among other things. These different design choices can result in a rich set of options to better provide users with future digital payment experiences.

Payment Innovation for Everyone, Everywhere

As a global leader in payment solutions, Visa is always on the lookout for innovations that meet real-world needs. We will continue to investigate the potential of smart contracts and the possible future of programmable money and programmable payments. In this paper, we delve into how AA on Ethereum implemented by ERC-4337 can enable interesting new use cases on the blockchain. We provide an end-to-end walkthrough of an ERC-4337 transaction and explain how it differs from standard Ethereum transactions to highlight the underlying mechanics.

Our experiments on ERC-4337 focus on two distinct use cases by deploying Paymaster contracts to learn and evaluate their potential utility in solving real-world problems and significantly enhancing customer experience through on-chain interactions. For companies working on this frontier, our product, research and engineering teams will be happy to discuss ideas for programmable payments.

Contact Visa Crypto at GDLVisaCryptoResearch@visa.com to learn more about our research interests and activities in the crypto ecosystem.

*This document is for illustrative purposes only. It contains a description of the product in development and should be understood as a representation of the potential capabilities 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 insist on a clear distinction between the conceptual terms entry point, paymaster, and user operation, and their corresponding on-chain entities EntryPoint, UserOperation, and Paymaster. This approach follows the conventions set out in the original ERC-4337 proposal. *

*Thanks to Cuy Sheffield, Andrew Beams, Mahdi Zamani, Mohsen Minaei, Aaron Salot, and Stackup co-founder John Rising for review. *