Auto Payments for Self-Custodial Wallets

Written by Andrew Beams, Catherine Gu, Srini Raghuraman, Mohsen Minaei, and Ranjit Kumaresan. Acknowledgement to Mahdi Zamani.

The problem

Alex's calendar. See image description for details.
The image shows Alex’s calendar from the day she gets paid, March 1st, the day she has a recurring bill due, March 5th, and goes back to work, March 10th. This demonstrates a scenario where auto payments can be helpful.
Ethereum push payments. See image description for details.
The image shows a specific ERC-20 token smart contract that connects Alex’s account with the merchant’s account. However, this also shows that there is no direct line of communication between the merchant and Alex.
Delegable account setup. See image description for details.
This infographic calls for creating a new type of account contract using account abstraction to include a pre-approved list of transactions. The merchant website requests to be approved within the auto payment list, and Alex adds the merchant onto the Delegable Account Smart Contract. The image above shows the pre-set conditions required for the auto-payment smart contract to execute the transaction.
Pull payment request. See image description for details.
This image shows the pull payment request being initiated from the merchant on a monthly basis. This pull payment request goes to the "Auto Payment" smart contract, which then interacts with the "Delegable Account" smart contract to ensure the preconditions are met. The auto-payment smart contract ensures the charge is no more than once a month, the specified amount, and that it is being requested from an authorized merchant. The delegable smart contract ensures the request is already on the pre-approved list of transactions and comes from an authorized merchant wallet address. Once both smart contracts verify these conditions, the token transfer request is sent to the ERC-20 token smart contract, and the payment is executed.
Timeline of Initial Abstraction. See image description for details.
The timeline shows that in 2016, we saw the initial idea for abstraction arise. Then in 2017, Account Abstraction (AA) was proposed as EIP-86 to implement “Abstraction of transaction origin and signature". Next, the timeline shows the origins of “EIP-2938: Account Abstraction” in 2020, and “EIP-4337: Account Abstraction via Entry Point Contract specification” in 2021.

Our Method – Account Abstraction on StarkNet

Visa’s coding method for Account Abstraction on StarkNet.

Conclusion