DebitLLama - Subscription payments with Account Abstractions

[barfolomew]

Obviously, not yet. This project was built during this hackathon, starting from september.
The only capital invested was my time.

I welcome any independent auditors to search for bugs.

[barfolomew]

Currently working on webhooks for slack integration…

and as part of a refactor, most business logic is slowly moving into the database.
Lots of buidl.

[MasterShadow007]

A better solution for subscription payments. Good work.

[Sakhi]

I found your project interesting, and I hope you keep building. I look forward to the integration of ExploreX. I’ve also voted for your project. Best of luck!

[barfolomew]

Thank you!

We are mainly working on a Zapier integration that will connect DebitLlama to a ton of different apps and there is a free to use REST API already!

The restaurant industry generally doesn’t have subscription model and the service you mentioned has no open access.

However we want to provide service for :

1. Content creators like Artists, Writers, Educators and Independent Publishers.

   Example: A personal substack like blog with paywalled blog posts, using debitllama for crypto payments.

2. x as a Service companies including:
   Infrastructure,Hosting,Database,Serverless,AI,Analytics,APIs,Blockchain Nodes

   We use crypto to pay for blockchain fees and I think developers should be able to pay for the whole tech stack with it too. Including fixed priced and usage based billing.

3. Alternative crypto option anywhere where Fiat is used.
   DebitLlama can add another revenue source for companies who want to start accepting crypto for their existing projects. It has zero upfront costs and anyone who joins our slack will receive free gas and a full tech support.

[Ash5]

This will be a much needed service as we 3 subscription increases… Very promising!

[zimbodugu]

It’s great to see innovation in the DeFi space

[constantinpricope201]

A lot of work has been done for this project and I can see that clearly!
I tested a bit of the app’s nice interface and smooth interaction.

I love any solution with ZKP as ZKP might play a crucial role in crypto in the future!

I cast a vote for you guys.

Really worth it!

Congrats,
onchaindev

[barfolomew]

Some updates of what I’m buidling right now

There is a stage deployment this is where all the new features are going and it’s separate from the main application. The main app will get huge update later.

Testing the zapier integration:

Create a new spread sheet when a subscription is created. There will be more complex automations down the road, but it’s a start.

Support for custom webhooks

Documentation is available.

Support for more ways to access the account
So we have more options, other than the password.

Using metamask:

Relies on eth_getEncryptionPublicKey and eth_decrypt

Passkey support:
It will first support Iphones and Windows Hello and Yubi key.
Because the Autheticator must support FIdo2 and largeBlob extensions.

These last features are not in stage yet, but will be soon after I finish the implementation.

Some ideas that I’m thinking to implement after:
W3C Verifiable credentials. For verifying active subscriptions offline, so a valid subscription can be verified using JWTs.

There is also a lot of work going on to optimize and speed up the back end and to refactor the relayer.

[barfolomew]

I just wanted to post that the above mentioned features are now implemented in the stage environment.

Here are some diagrams on how they work

The first version of Debitllama used password for a complete wallet abstraction experience, so payments work in all browers without a crypto wallet.

Because some folks might prefer using a wallet, I implemented the same thing using metamask and also passkeys.

The account abstraction relies on an encrypted secret for zkp and the difference in these methods is how the secret is encrypted and accessed!

Creating an account with metamask

When creating an account, the process relies on the eth_getPublicEncryptionKey RPC call, users are prompted to allow the application to access the public key in metamask.
Then Alice generates a secret and encrypts it, and stores it in a smart contract along the value deposit.

Checkout flow with metamask

The checkout flow with metamask relies on eth_decrypt RPC call which is not available in every wallet, so only metamask is supported. After an optional passkey 2FA, the users are prompted in metamask to decrypt a secret to start making payments.

Passkey accounts

Creating accounts and approving subscription payments is now available with passkeys. This removes the need to memorize a password or have a crypto wallet at all. The caveat is device support, IOS17 with Safari 17 is required or a Yubi key. The authenticator must support Fido 2.1 with Resident Keys and the largeBlob extension.

To use a passkey for wallet abstraction, first the passkey must be registered.
If the passkey doesn’t support largeBlob extension, the registration will fail.

The server must send a request to write to the largeBlob but the contents of the blob is only created on the client.
An ethereum key is stored directly in the authenticator device, it’s used for encryption-decryption only and can’t receive payments.

The user is prompted to interact with his authenticator hardware device twice during registration! Once to register it and once more to store the data.

Checkout flow with a passkey

The checkout flow follows the usual pattern, log in, passkey 2FA, then the server sends a request to read the largeBlob, which is done only on the client.

The client reads the encryption keys from the authenticator device and decrypts the secret, computes a zkSnark and sends the snark to the backend.

For reference, here is the checkout flow with the password

Alice generates a secret, computes the commitment and encrypts the secret with the password (AES), after this Alice further encrypts the secret with the debitLlama Public key and saves the encrypted secret in the smart contract

When approving subscription payments, after loging in and 2FA, the debitllama service will decrypt one layer of encryption, then the user is prompted to enter the password to decrypt it again.

The reasoning behind this approach is to use E2EE that is secure enough to be stored on-chain but works with a memorizable password. Only the owner can decrypt the secret, but the service provides additional security by adding more encryption layers.

This is the most portable out of the 3, but each have their benefits and downsides.

The subscription is finally fulfilled by relaying a transaction with the zkSnark proof, as often as neeed.

So the new account accessing features are available for demoing in stage

[Anoupen]

Thanks for the clear explanation it’s gonna encourage people to use it

[barfolomew]

Here is the latest update:

1. We have been on mainnet since october so the November 30 milestone has been met!

2. The previous updates I wrote about are available in production.
   You can now use account abstraction with Metamask and a Passkey authentication device as an alternative to the password.

3. Fully supporting custom webhooks. The documentation is available

4. Fully supporting Zapier API, so now anyone can create zapier integrations. Detailed docs are coming soon.

5. I provide full developer support for anyone adopting DebitLlama subscription payments.

Lot of people have been signing up. Please contact me if you find any bugs or experience any issues.

[barfolomew]

Looking for a Developer Advocate

Job type: Part Time, Remote, Asynchronous

Description:
I’m looking for an advocate to create content for developer education and community building.
This includes: blog posts, tutorials, proof of concept programs/integrations.

Required experience:
1 year of Typescript
Good written communication skills.
Know how to use Git

Work is distributed using a bounty program and you can solve bounties in any order you wish.
Payment is in USD, Escrow is available if requested.

please write to : info.zkptech @pm.me