DebitLLama - Subscription payments with Account Abstractions

EMerchant · October 13, 2023, 4:20pm

Thank you for providing with the Donau testnet links.

Are you still on track to deploy this project on mainnet before the Nov 30th deadline?

barfolomew · October 13, 2023, 7:29pm

Yes. Mainnet deployment will happen between 15 -22 October. Everything is ready for it now.

TritonTeam · October 14, 2023, 11:18am

One of the most promising project in defi category. Wish you success in Testnet and Mainnet deployment. If you have any problems in the coding & deployment section, we will be happy to help voluntarily. All the best

barfolomew · October 14, 2023, 3:11pm

Thank you!

The project is fully developed, I’m only waiting for the Powers of Tau ceremony to finish.

If you want to contribute, you can go to https://snarkyceremonies.com/
Enter a name (anything) , click enter ceremony and then you are prompted to enter some entropy and wait for it to finish.

The webpage generates a random contribution to the Groth16 zk-SNARK proving circuit that is powering the app, and as long as one contributor doesn’t extract the secret variables from the browser, the proving system will be secure.

This is just part of my zkp circuit compiling process. I run it till 17th of October.

I already have contributions, but the more the better. You can verify your contribution by comparing the sha256 hash of the name you entered with the logs.

Thanks!

TritonTeam · October 14, 2023, 9:20pm

Already done it

All seems fascinating, keep building. My support is with you

barfolomew · October 19, 2023, 7:35am

BTT Mainnet launch

BTTC mainnet is now available in production.

Here are the contract addresses:

ZKSnark Verifier:

Virtual Accounts:

Connected Wallets:

ZKSnark Verifier verifies off-chain created proofs used to debit the accounts.

Virtual Accounts implement an account type similar to Virtual Credit Cards, they need to be topped up to contain balance.

Connected Wallets contract allows connecting an externally owned account (EOA, a normal crypto wallet) and debiting that directly.

Subscription payments are available on BTT mainnet with
Native BTT tokens
USDD_t found at 0x17F235FD5974318E4E2a5e37919a209f7c37A6d1
USDT_e found at 0xE887512ab8BC60BcC9224e1c3b5Be68E26048B8B

Current ongoing work:

2FA using Passkeys (WebAuthN)
Added security to protect from credential stuffing attacks, phishing or weak login passwords.
Experimental feature: Smart Contract Account Password Abstraction with Passkeys
Explanation: Latest release of Passkeys in IOS17 and Safari17 and Chrome 113 started supporting a largeBlob extension for Passkeys. This unlocks the possibility to store secrets in Passkeys, secured by Apple, Android devices or Yubi keys. Simply put, you can map Passkeys to control smart contract wallets and it can fit well into DebitLlama tech stack. Currently not many devices support the largeBlob extension, but it’s a web3c standard available in nightly builds of mainstream browsers.
Email Notifications
Some implementation already available in Production. More on the way.
Zapier integration
Explanation: The integration is a simple Nodejs app that maps DebitLlama API to Zapier. It allows DebitLlama to be discovered by 3 million users and businesses and it lets DebitLlama connect to 6000 different apps without coding. You can create SaaS products , pay-walled websites, connect with accounting software, CRMs, OpenAI and many more.
REST API and Webhooks.
The public api/v1 is already available in Production. The documentation is available here. The webhooks and the remaining implementation is developed in parallel with the Zapier integration so they match.

barfolomew · October 21, 2023, 4:37pm

Some screenshots: #buildInPublic

The current tech stack:

A new Prod is live, right now on Deno Deploy, with these new features:

Authentication in action, on mobile:

The Scheduled Micro Transactions chugging along on BTTC Mainnet!

The first integration is Slack. Tech support, Leads and Notifications. Feel Free to Join!

adeel · October 23, 2023, 9:43am

@barfolomew it looks great. I have a question.

Can you explain in detail how account abstraction is going to works in DebitLLama?

barfolomew · October 23, 2023, 10:25am

For sure!

Lets define account abstraction first, here is some reading material

So you have 2 kinds of accounts on blockchain, externally owned accounts (EOA) and smart contract accounts.

So usually sending transactions require you to directly use your EOA.
But account abstraction will allow you to interact with smart contracts without directly using your EOA.

So the way DebitLlama achieves this is with a smart contract account that can be controlled using an off-chain computed zk proof.

Here is how it works in steps:

Alice connects her wallet with a smart contract. This requires her to generate a secret variable, then compute a commitment hash and save this commitment in the smart contract.
The secret variable is encrypted first with a password only known by Alice and then an asymmetric public key. It’s stored by the server E2E encrypted.
Alice needs to approve allowance to the smart contract, so it can transfer a token on her behalf later.(ERC-20 allowance) and that’s all she needs to do to use her wallet later.
Now in-order to trigger this smart contract, Alice needs to recover the secret by logging in and supplying her password and then she computes a zk proof using the secret. It works like a Commitment-Reveal Scheme where Alice proves she knows the secret behind the commitment without revealing the secret. Quite common scheme, useful for many things.
The proof also contains calldata for the function, so what the function call will do are set by Alice and can’t be altered later, else the proof is invalidated.
The proof represents a subscription in the case of DebitLlama. It’s an intent to make recurring payments. It’s called a payment intent internally by the application.
The proof verification takes place in the smart contract and the proof can be used to trigger the transfer function based on the payment intent parameters. It can be used once or many times with a set interval of x days.
Now Alice can give the proof to anyone who can provide a meta-transaction relayer and create the transaction on her behalf. The relationship between Alice and the relayer is trustless, there is no way to alter the contents of the proof after it’s created and this is a service project provides.

TLDR;
You need to enter a password and call a smart contract, then when you want to subscribe to a merchants service, you go to a checkout page where you only need to enter the password to approve subscription payments from your wallet. The payments go through the smart contract you called earlier.

All the smart contract calls in the background are abstracted away using a zk proof and a relayer.

StevenTRON · October 23, 2023, 6:40pm

Hello @barfolomew

I also think llamas are awesome Im curious how do you see BTT blockchain being able to help grow your project and user base?

Thanks!

fulldecent · October 24, 2023, 2:04am

Hello and thank you for sharing DebitLLama. I am reviewing this submission based on the website, including the developer documentation, the product introduction and the documentation in GitHub projects.

Overall it is creating a direct debit system where payment channels are opened and authorized by customers and tokens are debited by merchants as authorized. This models traditional debit transactions.

The chosen approach to implement this is zkSNARKS which are used for password-authorized payment transactions. This seems like a weird security architecture decision to me. The normal approach is to require the customer to design transactions (off-chain) using public key cryptography. But this approach uses a password secured by ZKP. It’s not exactly if the customer gives the payment password to the merchant (so the merchant can impersonate customer) or if the customer has to do ZKP before contacting the merchant. But either way, no strong motivation is provided why this is better than public key cryptography. Documentation that includes a Mermaid Sequence diagram could be helpful in illustrating this.

Aside from the security choices, this project direction does focus on a strong use cases that has consistent demand in TradFi. And so we need to recognize this before making any criticism. Keep up the good work, and I’m happy to see this contribution in merchant-initiated payment flows!

barfolomew · October 24, 2023, 4:39am

Thank you for reviewing. I will create a diagram soon! Good point.

You can kind of see here , on my first explanation image how it works.

The password is only used on the client for a symmetric encryption-decryption. It never leaves the browser.

The customer never gives the password to the merchant or the underlying service at any times.

The way it works is with a secret that is encrypted symmetrically and then with asymmetric encryption, then it’s stored by the service.

When the user navigates to the checkout, after a login and a 2Fa, the service will decrypt the secret with the private key, then pass it to the customer for the symmetric decryption.

Then the user enters the password and the decryption takes place in the browser and then computes a zkSnark and passes it to the service. The merchant never receives any data, other than the payments relayed by the service.

This was a design choice because it makes payments portable between devices without having to manage private keys between devices.

In the future, I plan to move away from directly entering passwords ,towards the largeBlob or prf extension found in the WebAuthN Web standard.

WebAuthN extensions need more browser adoption, then the secrets can be stored directly inside the authentication devices.

barfolomew · October 24, 2023, 5:30am

You can see the account creation flow and the checkout flow here

The storage of asymmetric encrypted secrets is inspired by Tornado Cash Note Accounts, I am using the same encryption with eth-sig utils.

The checkout flow relies on the Customer authenticating with the server,then the server will do the first decryption, then the customer does the second decryption in her browser.

She computes a zkp, sends it to the server and then the secret and the password are both deleted from the browsers memory.

Motivation to use passwords:

Passwords are more portable than public keys and can be memorized and their use is familiar to users.

Once an account is created on a desktop, payments can be made on a mobile device easily without having to copy files or have a crypto wallet at all.

It works in the default browsers on Android and IOS devices.

Example use:

I have a ledger wallet. I connect it to metamask and connect it to DebitLlama using my laptop and approve a 100USDC spend.
Later when I’m browsing the web on my android device and I want to buy something, I can complete the checkout and approve a payment from my ledger wallet without having to connect a wallet.
The spending limit protects my balance from over-spending.

barfolomew · October 24, 2023, 5:54am

Here are links to the code implementation for the cryptography!

Source code for the Password decryption

github.com

StrawberryChocolateFudge/debitLLama-server/blob/master/islands/approvePaymentIsland.tsx#L32


      
          export default function ApprovePaymentIsland(props: ApprovePaymentIslandProps) {
              const [password, setPassword] = useState("");
              const [errorMessage, setErrorMessage] = useState("");
              const [success, setSuccess] = useState(false);
          
              // Sometimes the button submits the request twice for some reason. If it submitted it once I lock it so it cant do again!
              const [payClickLocked, setLockPayClicked] = useState(false);
          
              async function payClicked() {
          
                  const decryptedNote = await aesDecryptData(props.symmetricEncryptedNote, password);
                  if (decryptedNote === "") {
                      setErrorMessage("Invalid password");
                      return;
                  } else {
                      setErrorMessage("");
                      if (payClickLocked) {
                          return;
                      }
                      setLockPayClicked(true);
                  }

Generates the zkp

github.com

StrawberryChocolateFudge/debitLLama-server/blob/master/islands/approvePaymentIsland.tsx#L43


      
          if (decryptedNote === "") {
              setErrorMessage("Invalid password");
              return;
          } else {
              setErrorMessage("");
              if (payClickLocked) {
                  return;
              }
              setLockPayClicked(true);
          }
          const paymentIntent = await createPaymentIntent({
              paymentIntentSecret: {
                  note: decryptedNote,
                  payee: props.itemData.payeeAddress,
                  maxDebitAmount: parseEther(props.itemData.maxPrice),
                  debitTimes: props.itemData.debitTimes,
                  debitInterval: props.itemData.debitInterval
              },
              snarkArtifacts: {
                  wasmFilePath: "/directDebit.wasm",
                  zkeyFilePath: "/directDebit_final.zkey"

Uploads the zkp

github.com

StrawberryChocolateFudge/debitLLama-server/blob/master/islands/approvePaymentIsland.tsx#L62


      
                  wasmFilePath: "/directDebit.wasm",
                  zkeyFilePath: "/directDebit_final.zkey"
              }
          }).catch(err => {
              console.error(err)
              setLockPayClicked(false);
              return;
          });
          if (paymentIntent !== null) {
          
              await uploadPaymentIntent({
                  button_id: props.itemData.buttonId,
                  proof: JSON.stringify(paymentIntent.proof),
                  publicSignals: JSON.stringify(paymentIntent.publicSignals),
                  maxDebitAmount: props.itemData.maxPrice,
                  debitTimes: props.itemData.debitTimes,
                  debitInterval: props.itemData.debitInterval,
                  paymentIntent: toNoteHex(paymentIntent.publicSignals[0]),
                  commitment: toNoteHex(paymentIntent.publicSignals[1])
          
              }).then(async (status) => {

Navigates away:

github.com

StrawberryChocolateFudge/debitLLama-server/blob/master/islands/approvePaymentIsland.tsx#L80


      
                      commitment: toNoteHex(paymentIntent.publicSignals[1])
          
                  }).then(async (status) => {
                      if (status === 200) {
                          // Success is true!
                          setSuccess(true)
                          // Log out so the back button will not reload the page
                          await logoutRequest();
                          // navigate to the redirect page
                          setTimeout(() => {
                              redirectToRedirectPage(
                                  props.itemData.redirectUrl,
                                  toNoteHex(paymentIntent.publicSignals[0]));
                          }, 3000)
                      } else {
                          setErrorMessage("Unable to save Payment Intent");
                          setLockPayClicked(false);
                      }
                  })
              }
          }

Symmetric encryption

Asymmetric encryption

ZKP cryptography

barfolomew · October 24, 2023, 6:50am

I’m adding here links to the docs:

ZKP implementation details

Smart contract implementation details

Client Side Account creation and Checkout page shows how the password is used

Theoretical attack scenarios and mitigations

barfolomew · October 24, 2023, 6:58am

I am building it on BitTorrent to participate in the Hackathon and help the chain grow.

I do plan to integrate many more chains including Base, Polygon, Avax and basically all the EVM compatible chains that have USDT or USDC.

Maybe even do cross-chain payments so a customer could pay in Polygon USDC but the merchant receives it on Tron. It’s a possibility.

barfolomew · October 24, 2023, 7:32am

Here is a way to try out the application using the Checkout page

manfred_jr · October 24, 2023, 9:47am

The constant updates are cool, love the UI in the mobile device also, kudos!

barfolomew · October 24, 2023, 12:09pm

Thank you!

Latest updates:

Bugfix:
A bug caused the USDT_t Connected Wallet balance display to load forever.
This is fixed now!

Also:
Documentation has been updated to cover pretty much everything that is available now:

barfolomew · October 25, 2023, 7:45am

Sure.

The smart contracts are very simple and use Open Zeppelin for transfer functions and math.
There is no complex smart contract logic.
All functions that transfer value are nonReentrant
The zksnark verification is generated code (snarkJS) that is well tested.
The smart contract owner/deployer has no access to the account balances
The account creator wallets can withdraw/disconnect their wallet any time.
The direct debit is pausable but funds are never locked for account creators.
The direct debit parameters are part of the zkp verification, so if they are altered by malicious relayer, the verification fails.
The direct debit transactions can be watched and all debit paused automatically, if a suspicious wallet is interacting with it, as a last line of defense.
The app is using WebCrypto for symmetric encryption. AES
It forces users to use strong hard to crack passwords on the User Interface
The passwords never leave the browser.
Using eth-sig-util for public key cryptography
When accounts are created, the secret to control them is encrypted twice instantly.
When subscription payments are created, the password is used to decrypt a cipher text. Then compute a ZKP with it, then it’s discarded.
The servers use HTTPS of course.
Before the user can subscribe on checkout, he needs to log in and do Passkey authentication
Passkeys protect from credential stuffing, phishing and weak login passwords etc. They let you add a yubi key or IPhone to do strong authentication.
The final checkout page (containing a partially decrypted cipher) is only loaded on a verified POST request and disallows caching, it’s not re-loadable without new passkey authentication.
Accounts also have spending limit. A Virtual account can only spend what is deposited, a connected wallet can only spend what is approved to it via ERC-20 approvals.

Topic		Replies	Views
Slash Web3 Payments -Automatically swap/payments- Hackathon Season 3 ecosystem	9	370	November 27, 2022
Project PLedger by Muffin- the ideal liquidity provision solution, a protocol which doubles between a lender and escrow to ensure everybody wins! Hackathon Season 3 academy	16	1039	December 13, 2022
Payee - Send Crypto directly via Usernames Hackathon Season 5 web3	37	714	October 29, 2023
Nevotom - The future of e-commerce Hackathon Season 5 web3	16	290	October 18, 2023
Simulaa - Monetize your NFTs Hackathon Season 3 nft	28	598	November 29, 2022

Related Topics