DebitLLama - Subscription payments with Account Abstractions

TRON Hackathon Hackathon Season 5
1

All milestones have been met! We are on mainnet.
But development continues on more features and optimizations.

Project Name: DebitLLama

Project Track: DeFi

Team Name: ZKP Solutions (Research and Development)

Team Member(s): [Barfollomew (aka StrawberryChocolateFudge on Github)]

HackerEarth Project Link: hopeter_c520 - HackaTRON Season 5 - Debitllama-subscription-payments | HackerEarth Hackathons

Deck:
debitLlama_pitchDeck_v3.pdf (1.6 MB)

Video Demo: https://youtu.be/zg5mNxqA_s8

Project Goal: Provide subscription payments with fixed or dynamic priced billing. A subscription payment gateway.

Project Value: It unlocks new payment channel for businesses using crypto and provide a safe way to pay for subscriptions for users. The payment process works in any browser, it’s not required to have a wallet after the accounts have been set up. The checkout process is very fast. Subsciption payments are set it and forget it

Project Website: debitllama.com

Project Test Instructions: The first version is available at debitllama.com
You can sign up or use these credentials to login: login@hackathon.tron password is testtesttest
Feel free to look around and use the sidebar to navigate.

To make payments you can create a virtual account that holds deposits or connect a wallet (EOA) and the payments will be pulled from the account directly.

To debit accounts you need to create a debit item that defines the parameters of the subscription and will generate a checkout page. You can add the wallet that will receive the payments, the subscription name, how much is the price per payment, how many times that will be pulled and how often. You can select dynamic or fixed pricing.

A fixed priced subscription is automatically processed while a dynamic one needs to be requested because the actual price can vary! It’s useful when billing per usage.

The Item page contains an embedded button that links to the checkout.
On the checkout page, customers can create new accounts or use existing ones and approve pull payment (subscriptions) by supplying a password. After they have created an account or connected a wallet they don’t need to use crypto wallet to make payments from it anymore.
It’s not only account but full wallet abstraction.

To sum it up, users need to use crypto wallet when:

  1. Creating a new account
  2. Updating balance (via approvals or deposit)
  3. Closing the accounts

Merchants need to use the crypto wallet when:

  1. Topping up the relayer with GAS
    But there is a possibility to cover the gas entirely from other fees

The subscription payments are pulled from the accounts automatically by a relayer.

Project Details:

The smart contracts and circuits published here : GitHub - StrawberryChocolateFudge/DebitAccounts: Crypto note based Debit accounts

Server:

Relayer:

DebitLlama allows Merchants to create custom checkout pages where users can pay for subscriptions using account abstraction.

Once the accounts are created all wallet interaction is abstracted using a relayer.

To directly debit accounts, the users create payment intents (zkp) which parameterize the details of the subscription payment. The intents are invariants and transactions created with them can be submitted by any relayer.

DebitLlama provides a centralized service to store data, render the checkout pages and store the payment intents, provides a relayer service, a Front End and a Rest Api.

An example use-case is a SaaS company offering subscription for a service like a VPN, they prompt the user to subscribe and then they can debit the customers wallet for a fixed period.

Subscriptions can be cancelled any time and provide a spending limit when we pay per usage.

Project Info:

DebitLLama-explanation
DebitLLama-explanation1920Ă—2517 157 KB

DebitLLama is a centralized SaaS business that provides payments for other SaaS businesses who can add a new checkout button to their website.

This image was the original sketch of how the service should work with the cryptography and it was implemented like this.

Smart Contract links:
Check one of my posts here

Project Milestones:
Smart contracts and circom circuits
Backend and frontend of the application (built with Deno Fresh)
Database using Supabase
Relayer service (built with Deno)
MVP ready for Demo and hackathon submission
Documentation
Website landing page.
Mainnet deployment :Between October 15-22

Rest API
webhooks

Zapier integration - Developed, docs coming soon

How it works and Inspirations.

Direct Debit with Account abstractions

The tech is inspired by “Vitalik EthCC Speech Summary: Account Abstraction Makes Crypto Wallets as Simple as Email” and Tornado Cash Note Accounts.

“Vitalik described account abstraction as allowing Ethereum accounts to be controlled by smart contract code instead of private keys”

I went ahead and implemented it with zero knowledge abstractions.

Creating an account:

  1. Alice computes a secret off-chain, which will be used to control the account and encrypts the secret with a password
  2. A second encryption takes place with a public masterkey belonging to the service provider who will verify the identity of alice.
  3. Alice creates the account by triggering a smart contract function and saves the encrypted secret.

Approving payments:

  1. To spend, the Alice must be first identified by the service provider that will do the first layer of decryption to recover the secret and will serve it on a secure page.

  2. Alice then uses the account password to access the plaintext secret. Final decryption takes place in the browser.

  3. Alice computes a zkSnark, from now on referred to as payment intent, using the secret.
    The payment intent allows directly debiting the account. The parameters of the payment intent enforce strict spending patterns. Due to the unalterable nature of the payment intent, transactions with it can be trustlessly relayed.

Payment intents can be revoked and accounts can be closed using the wallet that created them, any time.

A payment intent contains:

  1. The address of the payee
  2. The maximum debitable amount from the account
  3. The amount of times the payment intent can be used
  4. The interval it can be used, in days.
    and other variables used for the cryptography.

To recap, using this payment method, the accounts created can be directly debited multiple times, while approving these payments require only a password from the end user.

After this alice sends the Payment Intent to the service provider that will submit the transactions to process the payments.

38 Likes
2

You are welcome to S5.

If I gt it right, this is for SaaS companies. So they will be the merchants using your platform to create checkout pages for their users

2 Likes
3

Yes. SaaS, PaaS, IaaS or any other service that accepts subscription payments.

It is a payment gateway for crypto subscriptions that fits into a specific niche.

Free APIs will be available on rapidapi and integrated into zapier.

3 Likes
4

alright, please how far with ZkTickets - An event ticketing protocol using ZKP

after s4 hackatron, havent seen any update. i know it is live. want to know about the usage? do we have event planners utilising your service, how far now? and what’s the future of that project

4 Likes
5

Welcome to Tron Hackathon session Session 5
All the best, keep building

3 Likes
6

It’s fully available online and I have released an updated version.

If you are interested in more details about it, you can ask in the appropriate forum post,
but the first upcoming real use-case is ticketing for a small psytrance party organized by people I know personally and it’s only in December. I will be selling tickets and scanning them to make everything simple and the event does not have any online presence but a small gathering of 150 people.

I expect the process of user acquisition to take years for all projects. You have to get in there and meet people and find users one by one and sometimes do everything for them, especially when it comes to crypto projects that aim at utility over investments. We plan to organize a party every 6 months and hopefully I can improve the software a lot more to make it more user friendly.

I am building DebitLlama to branch into SaaS businesses with my company by providing a payment gateway for other SaaS businesses. I am happy to share more information about it.

It is currently under development and has no available front end, with the goal to have it working just before the deadline. I can provide a demo then.
Thank you for the questions!

4 Likes
7

Welcome to Season 5, I’m pretty sure your username sounds familiar and you were a previous season Hackathon contestant.
It’s interesting reading through your offering, I understand that DebitLlama is a platform that enables merchants to create custom checkout pages for subscription payments using virtual accounts.
And also, as a spin-off from a previous project (Bunny Notes), DebitLlama employs zero-knowledge proofs (ZKPs) to abstract the use of crypto notes for payments, offering a new approach for using ZKPs in payments.
As interesting as it gets, I only have two questions;

How does the integration with Zapier enhance the functionality of DebitLlama for SaaS businesses?

Could you explain how merchants gain insight into virtual account balances and how they can pause services based on those balances?

6 Likes
8

Welcome to Grand Hackathon Season 5
Do you have subscription partners?

Do you have any specific crypto token for payment?

Can your platform be trusted?

3 Likes
9
  1. How does the integration with Zapier enhance the functionality of DebitLlama for SaaS businesses?

Discoverability. It would allow existing businesses to accept crypto subscriptions using their existing Zapier automatons, using tools they already use.

1.Could you explain how merchants gain insight into virtual account balances and how they can pause services based on those balances?

Blockchain. Accounts are smart contract based. What they do with the information is based on their implementation, but there will be a REST API to fetch the account information for payment intents.

3 Likes
10

Do you have subscription partners?

No,

Do you have any specific crypto token for payment?

No, there will be a list, first one is BTT.

Can your platform be trusted?

Smart contracts are open source, don’t trust, verify.

3 Likes
11

Alright thanks for your response, wishing you all the best

3 Likes
12

Thanks for clarifying, would be watching closely as Hackathon progresses.

1 Like
13

Here is a list of concepts that are implemented to create this project:

Meta Transactions

“Meta Transactions are transactions who’s data is created and signed off-chain by one person and executed by another person who pays the gas fees.”

This is the optimal definition for now.
Meta-transactions inherently cater to the use of the next concept:

Intent Centric Architecture

Intents are predicates/conditions a user submits to a solver. The solver then designs a transaction that will pass these conditions to complete the intent.

Intents express a desired end state, they express the goal, while direct transactions express the ways to get there.

Intents are declarative and leave the final completion to the solver, which allow for async and recurring completion, till the desired state is achieved.

Intents must be verifiable, immutable and revoke-able and this brings us to the next point

Zero-Knowledge Proofs

The complete and sound nature of these proofs allow for the verification of integrity, validity and identity. They are optimal to use for Intent centric architecture as they are declarative, computed off-chain and have verifiable parameters and origin.

They allow for deriving data into higher level information representation, which brings us to the next point.

Zero-Knowledge Abstractions

"An Address Abstraction (AA) scheme is an abstraction over the inherent identifier system of the blockchain. It separates identity handling from the specific characteristics of the
blockchain protocol"

A loosely coupled layer built on top of an existing system helps avoid the constraints of the inherent environment, but it comes with it’s own set of limitations.

Identity

Blockchain transactions need to be signed by a secret private key to be considered valid.

Zero-Knowledge Abstractions also rely on a secret to create valid proofs.

The Law of Leaky Abstractions states that “all non-trivial abstractions, to some degree, are leaky.”

The difference however lies in derivation and storage, and we can benefit from indirection and reference an external identification system, which underlines how zero-knowledge identity systems work.

Encryption

The flow of information determines the security of the data manipulated by computing systems.

The rule of two is a data security principle, that specifies at least two independent layers of cryptography to protect the data.

One layer can employ symmetric encryption, which is the interaction point for the account user.

The other can involve breaking up the cipher text into N shards and encrypt the shards separately with public key of N participants, which would provide enough security for decentralized storage.

Combining these concepts, spending from an externally owned account can be effectively reduced to just entering a password, which will decrypt a recovered secret, compute a proof that verifies identity and encodes an intent which is then completed by a solver via meta-transaction.

3 Likes
14

The integration of these concepts seems to revolve around improving user experience, security, and privacy in blockchain transactions. I’ve a few questions following your update;

How does Debit Llama address potential limitations associated with zero-knowledge abstractions and encryption?

How does the utilization of intent-centric architecture impact transaction efficiency and user adoption compared to traditional transaction methods on the blockchain?

1 Like
15

Well you would need to be more concrete, but some things are currently addressed via centralization.

Abstractions allow rearranging complexity and encoding information, but some things like having secrets (private keys in wallets) can’t be removed. That’s how the abstraction leaks.

I am actively working to support more decentralization and did some progress but it’s not ready to publish.

One of the limitation I run into has to do with secrets, I decided to store them encrypted, but could have used other solutions like yubi keys or a retina scanner, pretty much anything, as long as I can safely store or recreate the same random number.

But my goal was to have a login and passwords and nothing else.

Zero-knowledge abstractions are great imho because they allow me to hide things nobody needs to know, contain high level information and also encodes data securely.

Intent centric means the users deal with they want and not how to do it.
For example, “I want to pay for a subsciption that costs 100USDT once a month, for 2 years.”
That’s my intent, to make recurring payments.

You always start with something you want to do, but when you send transactions you need to directly do it. That’s the difference between the two. Wanting to do something and the act of doing it.

It’s really just a way to talk about transactions that will happen in the future and it’s not a new thing.

Most account abstractions use intents, like EIP-4337 uses an alternative mempool for intents, which are called “UserOperations” that Bundlers or MEV searchers can later solve and then create transaction bundles .

To answer the question, it should help with adoption if you need to do or care about less things.

Efficiency depends on perspective, in my case you can just set it and forget it but it’s not gonna do things fast,

So to pay 100USDT once a month for 2 years, all you need to do is make sure you have the balance in your account. To approve payment you go to the checkout and enter a password to subscribe. The rest is automatic.

If you wanna see intents implemented for other things like Swaps, check out Cow Swap, that one is pretty cool, but intents have been always here, as long as people wanna do things, it’s just a way to think about things.

1 Like
16

This was well explained, very detailed and easily understood, thanks for replying, have a great weekend buddy.

1 Like
17

Greetings @barfolomew ! Your project seems to have all details. Thank you! *beep boop

4 Likes
18

I wanted to do a little peek into the current crypto subscription market, mention some important projects and show where DebitLlama fits in.

Custodial sevices:

Crypto .com - They have a subscription service that works in their app. You must deposit and they manage your whole balance for you. The amount is directly debited from your account and the whole balance is entirely held by them, much like a bank. They give a familiar bank like experience, inside their ecosystem.

Web2 based services:

NowoPayments, Coingate,Subscriptr and other services provide payment gateways that integrate with many e-commerce services and allows you to charge regular or recurring payments.

The payments are based on invoices that are sent via email and must be paid manually each time. The payments are non-custodial and flow directly between accounts! They generally provide the notification infrastructure and a familiar checkout flow and many integrations. But unlike credit card payments, each payment must be manually sent.*

Web3, Smart Contract Based:

Sablier is a token streaming platform for DAOs and businesses. It utilizes ERC-1620: Money Streaming to provide it’s service. It requires a deposit for the whole subscription period from the sender and the recipient can withdraw the money over time. To me this seems genuinely innovative and their protocol processed billions of dollars already.

Revuto is a mobile wallet for Cardano that has built in support for managing subsciption payments. It seems to work like virtual debit cards that need to be topped up.
But they seem to be mostly focused on selling their tokens and ordinals on their website and there is not that much information about how it works exactly.

So this is the general outlook. You have a streaming service, a bunch of invoice based payment notification services, virtual debit card based DApps or completely custodian services.

DebitLlama is a hybrid of web2 and web3

DebitLlama offers Intent based subscription payments. That means it uses cryptography to create secure off-chain transactions that can be used to process payments in the future with account abstraction.

It eliminates the need for the user to manually confirm payments each time, which is what most web2 based services rely on. This is a compromise most services allow just to avoid asset custody related regulatory pressures.

It’s non-custodial and never holds user funds. The payouts are instant and the subscriptions are easy to cancel. Both virtual debit accounts and externally owned wallets can be used to make payments.

It has wallet abstraction that mimics custodial UX, without handling over the control of your balance. It achieves this using cryptography.

I took much inspiration from web2 based services, with similar REST Api with integrations now under development.

2 Likes
19

Wish you a successful completion of your last milestone for your promising project.
Just curious about the project name, was it inspired from somewhere

1 Like
20

Thank you.
I think Llamas are awesome and yes there are other projects that use them as mascots.