Word on the Streets

Visa & Crypto

JohnnyProduce.eth -

While this series has done its best to introduce readers to some of the basic concepts and intriguing projects we have found over the course of the year, it is also worth highlighting major brands that have taken the Web3 space very seriously. There are countless examples of big brands doing just that like we saw with Budweiser begin to do last year. While we didn't necessarily highlight all of those Brand moves, we did want to take a moment to shine a light on Visa, one of the worlds largest financial service brands, who is investing heavily in the future of programmable money and payments. Far beyond purchasing an ENS name or launching an NFT, Visa is substantially contributing to protocol development and thought leadership in general about how the space evolves. Below is an idea published in a technical paper last week that is pushing the limits of what is currently possible and what might be done to overcome current limitations for the Ethereum network. This particular idea one that would enable crypto users to set up auto-payments without having to sacrifice self-custody of their wallets and private keys.  While we edited the paper down slightly we think they did a good job making this accessible, even if it does get a bit technical here and there, so what follows is taken directly from the paper.

The problem

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?

Calendar Schedule for Alex

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.

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.

Existing Self-Custodial Wallet Solutions

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.

Delegable Account Setup

Delegable account setup image description

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.

Delegable Account Payment Process

Delegable account payment image description

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

Timeline of initial abstraction

Timeline of initial abstraction image description

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.

Our Method – Account Abstraction on StarkNet

Account Abstraction Method

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.

Conclusion

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.