Paying Blockchain Gas Fees with Card

Blockchain technology has gained significant adoption in recent years, and while it has the potential to shape the future of money movement, blockchain transactions bring a heightened level of complexity that isn’t seen in traditional payment methods. Blockchain transactions utilize a decentralized network, where multiple participants verify and record each transaction. They involve self-custodial wallets, private keys, gas fees – all elements that do not apply to conventional payment methods. To transact using a blockchain like Ethereum, consumers must maintain a balance of the blockchain's native token (e.g., ETH) to pay fees for using the network, known as "gas." What if sending blockchain transactions using self-custodial wallets was as straightforward for the user as using your card to pay for a cup of coffee? With a self-custodial wallet, the same level of ease has yet to be achieved when it comes to user experience on a blockchain. For instance, while Ethereum supports push payments, it doesn't natively support pull payments, like auto payments. To address this, last year we explored and demonstrated how to set up a pull payment for self-custodial wallets using Account Abstraction in our paper "Auto Payments for Self-Custodial Wallets." ¹

Visa is familiar with facilitating transactions involving different currencies. For instance, a user can travel to another country without worrying about obtaining foreign currency ahead of time, as the same Visa card allows you to make purchases both at home and abroad. However, this level of simplicity and convenience doesn’t exist in the world of crypto. Consumers transacting in Ethereum find themselves constantly managing their ETH balance to cover gas fees, which is a burdensome process that distracts them from their primary blockchain activities. When comparing the complex nature of blockchain transactions with the simplicity of fiat-based payment transactions supported by the Visa network, it becomes evident that improvement is needed. The question that remains is: How can we help bridge this gap and bring the convenience and simplicity to blockchain transactions? 

Recognizing this challenge, we explored an option of how to allow users to pay their onchain gas fees directly in fiat money through card payments, thereby simplifying blockchain transactions. Under this scenario, users may no longer need to hold native tokens specific to a blockchain solely for the purpose of paying gas fees. Such a potential solution would leverage Ethereum's ERC-4337 standard and a paymaster contract, enabling users to use a Visa card to directly pay for gas fees. For a comprehensive understanding of ERC-4337, the current standard for Account Abstraction implementation on Ethereum and other EVM chains, we recommend referring to our previous publication "Rethink Digital Transactions with Account Abstraction." ² We believe such an innovative and flexible approach can help simplify the entry point for new crypto users and enhance the experience for current users. In this article, we will delve into the existing challenges with blockchain transactions, highlight the need for a more flexible approach, and walk through our experiment.

One of the major obstacles in the world of crypto is the complex process of paying for transactions or operations on blockchains. Each operation, whether it's a simple token transfer or a more intricate interaction with a smart contract, incurs a cost known as a "gas" fee. This represents the computational effort required to execute the operation. In the case of Ethereum, this gas fee must be paid in the blockchain’s native token, ETH. To gain a deeper understanding of gas fees and Ethereum's economic and staking model, refer to our earlier publication "Ethereum's Economics and Staking Model."³

Despite the availability of stablecoins like USDC for conducting transactions, users are still required to maintain a separate balance of ETH to cover the gas fees on Ethereum. This often leads users to adopt complex and sometimes expensive methods. Some rely on on-ramp services to convert fiat currencies into native tokens like ETH, while others purchase ETH on a centralized crypto exchange and then transfer it to their wallet. However, both of these strategies require additional steps and lack the simplicity and immediacy that users are accustomed to in traditional financial transactions. Furthermore, these methods expose users to the volatility of crypto exchange rates because they need to consistently purchase ETH even when a different cryptocurrency or stablecoin is being used for the payment transaction.

For example, let’s consider Alex, a user who wants to participate in a decentralized finance (DeFi) project that requires her to mint new tokens. To do this, she decides to use an on-ramp service to convert her fiat currency into ETH. Alex carefully plans and purchases a specific amount of ETH based on the current gas fees and the expected cost of the minting process. However, gas fees on the Ethereum network can fluctuate rapidly. If the fees decrease significantly by the time Alex performs the mint, she will have overpaid for the gas fees and may end up with leftover ETH that she didn't intend to buy. Conversely, if the gas fees unexpectedly rise after Alex acquires ETH, she may not have enough funds to cover the increased fees, resulting in underpayment. This unpredictability and the need to estimate and manage gas fees add complexity and inconvenience for users like Alex. Figure 2 illustrates the process of on-ramping when a user buys crypto through an on-ramp provider.

Furthermore, for users like Alex, acquiring native coins such as ETH often involves moving assets from centralized exchanges. This requires depositing fiat currency into the exchange, purchasing the necessary tokens, and then transferring them to a personal wallet to have enough ETH for gas fees. However, this approach also carries the risk of overpayment or underpayment due to fluctuating ETH values and gas fees. Additionally, it can be overwhelming and challenging for individuals who are less technologically savvy and want to engage in blockchain transactions. This process acts as a barrier to entry for those unfamiliar with crypto exchanges and the complexities of buying and bridging tokens. It can be compared to the cumbersome and unfriendly method of exchanging cash for different currencies when traveling to different countries. Figure 3 illustrates the bridging process when a user buys crypto through a crypto exchange and transfers it to their wallet.

Building on our previous work described in "Rethink Digital Transactions with Account Abstraction,"² our Crypto Protocol, Visa Innovation Center, and Visa Research teams have conducted an internal hackathon, where we took the opportunity to explore paymasters under ERC-4337.^* The result of this collaborative effort is a proposed solution flow that demonstrates how to enable users to pay their onchain gas fees in fiat money through a card on file. This proposed solution utilizes Ethereum's ERC-4337 standard and a paymaster contract, allowing Visa cardholders to directly cover their gas fees. We believe that this innovative and adaptable approach can help streamline the onboarding process for new crypto users and improve the experience for current users.

In this proposed solution, we once again put the paymaster at the heart of the process. A paymaster is a specialized type of smart contract account that can sponsor gas fees for user Contract Accounts (think of these as user-centric smart contracts). Our proposed solution liberates users from the need to hold native blockchain tokens or constantly engage in bridging tokens merely to cover gas fees. From a user’s perspective, this solution is appealing in its simplicity and ease of adoption, as shown in Figure 4. For instance, let's turn back to Alex, who owns a self-custodial wallet. With our proposed solution, Alex can use her Visa card to pay for gas fees and participate in a DeFi project that requires her to mint new tokens. By doing so, Visa helps take care of the complex processes behind the scenes, enabling Alex to effortlessly select her Visa card to cover gas fees. This proposed solution brings simplicity and a better experience to users like Alex who are looking for a more streamlined and accessible way to engage with blockchain transactions.

A paymaster’s role is to abstract away the complexities of the gas fee mechanism while offering alternative ways for fee funding. Our experimental implementation does this by accepting the user’s gas fee payment offchain from a Visa card and covering the equivalent amount onchain, on behalf of the user. The gas fee experience on the user's end is as simple as a regular card payment. Users can choose to use such a paymaster when sending User Operations. User Operations are like regular blockchain interactions, in that they specify the action the user wants to take on the blockchain. But unlike transactions, User Operations don’t need to be signed by an Externally Owned Account and can be verified and executed directly by a Smart Contract Account. 

The setup we implemented to enable the offchain gas payment capability is centered around a Verifying Paymaster. A Verifying Paymaster is a smart contract that delegates all necessary checks and sourcing of information to an offchain component. The onchain paymaster smart contract can then use the data and approval provided by the offchain component to authorize and pay for the gas fee. The way to reliably transfer this information from the offchain service to the paymaster contract is through public-key cryptography: Offchain web service uses a secret key to produce a digital signature to send along with the information. The paymaster smart contract can in turn use the corresponding public key to verify the signature and therefore the authenticity of the information. For our experiment, we used the Verifying Paymaster sample smart contract⁴ provided by ERC-4337 core team.

As shown in Figure 5, in our implementation, when the user intends to initiate an operation over the blockchain, the wallet first generates a User Operation request with information on the action they are trying to conduct (i.e., calldata) and the maximum processing cost of the action (i.e., parameters related to gas fees). More specifically, parameters specifying a gas limit determine the maximum amount of computation that should be budgeted for the operation, and the gas fee determines the cost for each unit of computation.  

Instead of sending the User Operation request to the blockchain right away, the wallet first sends the User Operation, along with Visa card credentials, to the paymaster web service (step 2 of Figure 5). The web service will use the gas fee information to calculate the appropriate cost to charge the user in fiat currency, and based on the card credentials provided, the Card-issuer may elect to authorize the card payment. For the web service’s payment acceptance solution, we used Visa’s own Cybersource.⁵ Cybersource provides developers with the necessary SDKs and APIs to enable merchants to accept digital payments.

In our experiment, after the payment is processed via Cybersource, the web service produces a digital signature over the relevant data in the User Operation, including the calldata and gas fee information (step 3). It also determines a time range of when this signature is valid. Specifying a time window is important because the value of ETH and other native tokens are dynamic on Ethereum and other EVM chains. Without precautions, a user could exploit the lack of synchrony between the two parts of the paymaster, paying offchain in fiat money when the ETH cost is lower, only to use the signature later when it is higher and have the paymaster contract bear the cost difference. The web service sends the digital signature back to the wallet. Beyond this point, any changes that the wallet makes to the relevant parameters of the User Operation would cause a mismatch with the digital signature, and the Verifying Paymaster Smart Contract would detect the discrepancy.

The wallet receives the digital signature and the time window from the web service and appends this information, along with the onchain address for the paymaster contract, as the paymaster parameter of the User Operation. Now, when all parts of the User Operation are complete, the wallet will be enabled to sign and send it to the blockchain (step 4). On the blockchain, as part of the User Operation processing flow defined by the ERC-4337 standard, the paymaster contract will receive the User Operation data, which should include the digital signature from the paymaster web service. If there is anything wrong with the data provided (an incorrect signature, invalid time window, etc.), the paymaster contract is designed to raise an error and will not cover the gas costs. If the signature is verified to be correct, this means the web service received the card payment to enable the processing cost of this User Operation. The paymaster contract will raise no errors and will handle the cost, and the User Operation will execute (step 5).

When building our experiment, we used Stackup’s userop.js library⁶ to construct, sign and send User Operations with our wallet. To post these User Operations to the blockchain, and for supplementary functions like estimating gas fees, we used Stackup’s Bundler⁷ as our provider. For testing purposes, we deployed our Verifying Paymaster⁸ over Ethereum Goerli testnet and were able to successfully send User Operations⁹ with offchain gas fee payments.

The intricacies and complexities of blockchain-based transactions have been a significant stumbling block for many users, creating a challenging learning curve and increasing user friction. However, our experiment aims to offer a promising approach to substantially addressing these challenges. By leveraging the innovative concept of a paymaster, in conjunction with Account Abstraction and the ERC-4337 standard, we explored the potential for a process that could redefine blockchain-based transactions. 

Account Abstraction allows developers to design new flows that help reduce friction for all kinds of value interchange. Our experiment demonstrates that developers can implement this solution with existing payments infrastructure. Merchants or decentralized applications (dApps) could run their own paymaster solution as a means to help improve customer experience by accepting gas fee payments using Visa cards. Alternatively, existing wallet and paymaster service providers could offer a card-based gas fee payment choice for general use alongside their other paymaster offerings. The realization of such a potential solution helps set the stage for a more accessible and user-friendly approach to digital transactions. 

For companies working on this forefront, our product, research and engineering teams are 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. Head over to Visa Crypto Thought Leadership for more consumer insights, best practices and innovative approaches to the blockchain through our research.

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 the features described in this presentation. 

Footnotes

1. Auto Payments for Self-Custodial Wallets by Visa.  Accessed 1 Aug 2023. 
2. Rethink digital transactions with Account Abstraction by Visa.  Accessed 1 Aug 2023. 
3. Ethereum's economics and staking model by Visa.  Accessed 1 Aug 2023. 
4. Sample code provided by the ERC-4337 core team for Verifying Paymaster
5. Cybersource: A Visa Solution. 
6. Documentation page for Stackup’s userop.js library. 
7. Documentation page for Stackup’s Bundler service. 
8. Visa Verifying Paymaster deployed contract. 
9. Etherscan Block Explorer | Sample UserOperation for Sponsor Paymaster Test

^* Special thanks to Yi Hsiao, Salvador Ricardo, Yuset Rosello Moya, Anjana Sarkar, Divyata Singh, and Cristina Villarroel from Visa Innovation Center, and to Andrew Beams, Mohsen Minaei, and Mahdi Zamani from Visa Research for their help throughout the hackathon