Auto Payments for Self-Custodial Wallets

As blockchain adoption increases, there will be a greater need for products with a superior user experience and core functionality that support real use cases. In a few simple steps, we can set up automatic recurring payments today directly on our mobile banking applications. In fact, online bill pay is growing rapidly, and customers - especially younger ones - have come to expect the ability to set up recurring payments and take advantage of other conveniences associated with using their Visa cards. About 3 in 10 surveyed consumers have changed the way they pay their bills in the past two years and finding a more convenient way to pay was the most frequently cited reason¹. However, this is not a trivial task on a blockchain like Ethereum, the largest blockchain network by on-chain payment volumes². For certain types of digital wallets, such as a self-custodial wallet where the user has sole control over the wallet and private keys, automated programmable payments that can pull payments automatically from a user’s account at recurring intervals requires engineering work.

In this technical paper, we utilize a novel concept and one of the leading Ethereum developer proposals known as Account Abstraction to explore how smart contracts can be implemented to enable automated programmable payments. We propose a new solution towards a real-world application of auto payments to demonstrate how to write a smart contract for a self-custodial wallet that can pull funds automatically, instead of requiring the user's active participation each time to instruct and push payments on a blockchain.

Consider a hypothetical scenario: today is the 25th of February. Alex is going away on vacation to the Alps, and she will be returning on March 10th. She must pay her mortgage, TV subscription and utility bills by the 5th of every month. She does not have enough money to pay before she goes on vacation, but she will have enough money when she gets her paycheck on the 1st of March. How is Alex going to enjoy her vacation without missing her payments?

You might be thinking – auto payments! And you are right. Indeed, if Alex had a bank account, this is a straightforward process. All Alex needs to do is set up recurring payments on her Visa card to automatically pay for her recurring bills. However, this is not as straightforward to execute on a blockchain. To see why this is the case, let us consider the Ethereum network. We will begin by setting up some terminology that will help us better understand the issue at hand.

As part of Visa’s internal Crypto Hackathon challenge earlier this year, we took on the opportunity to explore the above scenario using a novel technique. The example described is a common everyday use case that can be solved by existing means today such as cheque or Automated Clearing House (ACH). We also provide a fast and efficient option today for billers – through Visa acceptance, merchants can opt to accept Visa by setting up automatic payments for recurring bills or by taking card information for individual payments over the phone or online. However, as we are looking to utilize blockchain technology for payments, this takes a new turn when it comes to building out the solution through smart contract.

Accounts on Ethereum

There are two types of accounts on the Ethereum network today: Externally Owned Accounts (EOA), more commonly referred to as user accounts, and Contract Accounts (CA), referred to as smart contracts. A user account, controlled by a private key, can send transactions. A smart contract has associated code that can be executed, however, a smart contract cannot initiate transactions on its own. Transactions must always originate from a user account and be signed by the user. Transactions can be a simple token transfer between user accounts on Ethereum blockchain or more complicated ones that trigger a series of operations to be executed through smart contracts to perform many different actions.

Auto Payments on Ethereum

Let us revisit Alex’s situation. Suppose Alex owns a user account which is where her paychecks are deposited and from where she would like to pay her mortgage, TV subscription and utility bills. Today, to pay her bills, Alex has to initiate a transaction that transfers tokens from her EOA to a user account belonging to the recipient, that is, to whomever she is paying her bills. In more detail, Alex’s EOA has an associated secret or private key known only to Alex. This private key is used by Alex in the generation of an Elliptic Curve Digital Signature Algorithm (ECDSA) signature that is crucial for the creation of a valid transaction. And this already brings us to the problem at hand. If Alex is away on holiday, who will generate this signature to create the transaction that will make her payment?

One solution is for Alex to use what is known as a custodial wallet. With a custodial wallet, another party controls Alex’s private key. In other words, Alex trusts a third party to secure her funds and return them if she wanted to trade or send them somewhere else. The upside here is that Alex can set up an auto payment connected to her custodial wallet. Since the custodian, who is the party that manages her wallet, has access to her private key, they will be able to generate the signature needed to create the transactions for her scheduled auto payments. And this can happen while Alex is away on holiday. The downside is that while a custodial wallet lessens Alex’s personal responsibility, it requires Alex’s trust in the custodian who holds her funds.

With a self-custodial wallet, one where the user has total control over her wallet, Alex has sole control of her private key. While there is no need to trust a third party when using a self-custodial wallet, this also means that Alex will not be able to set up an auto payment as she must be the one using her key to generate the signature needed for the payment transaction.

Another way to understand this is through the terminology of pull and push payments. A pull payment is a payment transaction that is triggered by the payee, while a push payment on the other hand is a payment transaction that is triggered by the payer. Ethereum supports push payments but doesn’t natively support pull payments – auto payments are an example of pull payments.

So, what does Alex do if she wants to use a self-custodial wallet and yet schedule auto payments?

Account Abstraction

Account abstraction (AA) is a proposal that attempts to combine user accounts and smart contracts into just one Ethereum account type by making user accounts function like smart contracts. As we will see ahead, AA allows us to design a neat solution for auto payments. But more generally, the motivating rationale behind AA is quite simple but fundamental: Ethereum transactions today have several rigid requirements hardcoded into the Ethereum protocol. For instance, transactions on the Ethereum blockchain today are valid only if they have a valid ECDSA signature, a valid nonce and sufficient account balance to cover the cost of computation.

AA proposes having more flexibility in the process for validating a transaction on the blockchain:

• It enables multi-owner accounts via multisig signature verification.
• It enables the use of post-quantum signatures for the verification of transactions.
• It also allows for a so-called public account from which anyone could make a transaction, by removing signature verification entirely.

Essentially, AA allows for programmable validity to verify and validate any blockchain transaction. This means that instead of hard coding validity conditions into the Ethereum protocol that will apply to all transactions in a generalized way, validity conditions can instead be programmed in a customizable way into a smart contract on a per-account basis. With AA, a user deploys an account contract with any of the features described above, among others.

And, most importantly for us in the use case described, AA enables auto payments as we can set up validity rules that no longer include signature verification. We will elaborate on this next.

Delegable Accounts – Account Abstraction Enables Auto Payments

Our solution for auto payments is to leverage AA and create a new type of account contract – a delegable account. Our main idea is to extend programmable validity rules for transactions to include a pre-approved allow list. In essence, AA allows us to delegate the ability to instruct the user’s account to initiate a push payment to a pre-approved auto payment smart contract.

First, a merchant deploys an auto payment smart contract. When a user with a delegable account visits the merchant’s website, they will see a request to approve auto payments – similar to Visa acceptance for billers today. Here, the user can see the actions that the auto payment contract will do in the user’s name. For example, it can only charge the user once per month, or it cannot charge more than a maximum amount. Crucially, because this is a smart contract, a user can be confident that the auto payment contract cannot execute in a way other than how it is written.

If the user agrees to approve auto payments, the wallet will add the auto payment contract’s address to the list of allowed contracts on the user’s delegable account.

Next, the merchant triggers a payment by calling the charge function of the auto payment contract. The auto payment contract causes the user’s account to initiate a push payment, which will be valid as it has been added to the user’s allow list. From the token’s point of view, this is indistinguishable from a standard push payment.

Other different real-world applications can be imagined beyond just recurring payments – some of which may not be easily accessible through today’s payment rails. Our solution of delegable accounts can be extended to support all kinds of pull payments in general, and moreover third-party account recovery services where multiple parties must consent to initiate an account recovery, third party asset managers with restrictions on the specific Ethereum Request for Comments (ERC) tokens which they can manage, and how they can trade these tokens, and more.

Account Abstraction on Ethereum

AA was initially proposed as EIP-86 in 2017 to implement “Abstraction of transaction origin and signature” but the origins of the motivating idea go back even further to early 2016, where it was suggested that: “Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.”³ The initial proposals were challenging to implement because of the many protocol changes required and the security guarantees to be met. The most recent EIP-4337 claims a way to do AA without Ethereum protocol changes. The truth is there is still debate on how AA should be implemented on Ethereum.

Because Ethereum does not yet support AA, we implemented our delegable accounts solution on StarkNet, a secondary layer blockchain, commonly referred to as a “Layer Two blockchain”, built on top of Ethereum blockchain to increase transaction throughput alongside other features to improve the underlying blockchain settlement layer capability. StarkNet is developed by the crypto startup company StarkWare. StarkNet’s account model is what we have thus far described as AA. In short, while concrete accounts check whether a transaction comes with a correctly signed signature for a given address, StarkNet’s abstract accounts simply check that the transaction comes from a given address.

With concrete accounts, if someone sends a token to your account, they interact with the token contract to change the recorded owner from their address to your address. The token contract performs a check that the identity (key) used to sign the transaction to make this transfer is recorded as the current owner of the token. With abstract accounts, if someone sends a token to your account, they interact with the token contract to change the recorded owner from their address to your address. The token contract performs a check that the identity (contract) used to make this transfer is recorded as the current owner of the token. With abstract accounts, it is the who (address) that matters, not the how (signature).

With StarkNet’s account model, we were able to implement our delegable accounts solution thus enabling auto payments for self-custodial wallets.

As one of the world's largest payments network, Visa is at the forefront of designing innovative payment products and solutions with real-world applications in mind, and we are actively exploring novel approaches of smart contracts to help make money and payments programmable.

We see auto-payments as a core functionality that existing blockchain infrastructure lacks. In this article, we shared a novel solution that leverages the concept of account abstraction to provide self-custodial wallets with automatic recurring payments capability. Using the approach we have introduced, other real-world applications beyond recurring payments could be brought to the blockchain. At Visa, our goal is to help create better user experiences leveraging existing as well as new payment rails. To that end, we believe that programmable money and programmable payments represent an exciting opportunity.

For companies working on this forefront, our product, research, and engineering teams will be happy to discuss ideas in programmable payments. Reach out to us to learn more about our involvement in the crypto ecosystem and the products we are currently building to expand Visa’s capabilities within blockchain payments. Reach out to Visa Crypto at GDLVisaCryptoResearch@visa.com to learn more about our involvement in the crypto ecosystem and the products we are currently building to help expand our capabilities within blockchain payments.

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.

Footnotes:

• ¹Source: Aite Group Report: How Americans Pay Their Bills: Sizing and Forecasting Bill Pay Channels and Methods, 2010–2013
• ²$4.1 trillion transfer volume of the top ten stablecoins was recorded on Ethereum over a twelve-month period between November 2021 and November 2022, as estimated by Visa Crypto using public database with Dune Analytics Query
• ³Source: Proposed initial abstraction changes for Metropolis #86, https://github.com/ethereum/eips/issues/86