Project Type: Multiple - Multiple applicants can get selected to work on the tasks and get paid.
Time Commitment: Weeks
Experience Level: Intermediate
Size: USD 1’000 in ICP (at time of distribution)
Description
One of the advantages to deploy a service on a blockchain platform is to be able to receive payments without the usage of a 3rd party service provider which can be a huge cost factor. In this bounty, you’ll implement a sample application that showcases the implementation of the ICRC-1 payment flow to buy some digital good.
The base ICRC-1 standard supports the client-orchestrated transfer/notify flow, i.e. the client (payer) transfers the token to the service-designated subaccount and notifies the service (payee) about the transfer.
High-level flow diagram
Notes
The client would utilize agent-js to perform (transfer and notify) calls.
The invoice and its relation to a subaccount will probably need to be standardized at some point, allowing for different compatible payer and payee implementations. We hope that this implementation will inform a potential standardization.
The eventual goal is to make it as easy as possible for developers to integrate a payment flow into their applications. Hence, we see the development of sample applications as a first step to implementing ready-to-use client and canister libraries which could be funded by a follow-up bounty or grant.
The ICRC-1 token standard is in its early days and many details and extensions have not been fully fleshed out. It would be great if you’d provide your implementer’s feedback to the Ledger & Tokenization Working Group.
How to apply?
Add a comment to the issue or respond to the forum thread. Please provide some background on your experience and give an outline of your project plan.
It’s not clear if this bounty is for motoko or rust, but if rust works, feel free to take a look at this: GitHub - GLicDEV/invoices_as_nft
It was my 1 day attempt at an invoice canister. The functionality is minimal, but all the parts are there to follow the proposed flow, for transferring ICP. It should be easy to switch to ICRC-1. As the code is released under MIT, feel free to use whatever you need if someone wants to go this route.
Both Motoko and Rust are acceptable on the canister side. Ideally, we’d have both implementations as is common for the DFINITY maintained sample dapps.
Submitting my project for this (plan on adding one more script showing how zx makes it easier to do bash scripting interpolation–since the current dfx identity might not be the one most easily authenticated through the local replica II web interface, some additional screenshots).
We had discussed previously for a focus on using web workers to do background processing; also using React, Tailwind with a QR code scanner. Additionally, a QR code is generated of the ICRC1 address corresponding to the subaccount of the authenticated user and displayed on the home page (authenticated landing page)–although it’s just the raw string of the address (not payment encoded). That being said, the QR code scanner does interpret if it is a payment encoding (according to the { decodeIcrcAccount, decodePayment } from "@dfinity/ledger") and decodes it if it is, auto-populating the amount and address input fields.
Note I dropped the caching due to conflicts in the testing (no indexdb in webworkers in testing environment), so it loads slower than I’d like–I’ll end up fixing that since I resolved the testing conflict issue, and it certainly makes a difference.
The mainnet version is actually connected to the ckbtc minter, so if someone credited their account address with some cksats they could actually use the mainnet version to pay ckbtc. This is an important point since I built it on the assumption the ICRC1 token canister metadata details would not be known beforehand–if they are, it greatly can simplify things–so the frontend actually starts by getting the ICRC1 token canister metadata key value list, which is used to display both normal and base unit amounts. This is maybe not something that a real production would do, but since ICRC1 can have varying decimal values is important to keep in mind.
Just wanted to add, later this week I’ll be adding, along side the payments, invoices/payables, such that entering an amount will generate a payment encoding and corresponding QR code which will be available at a non-authenticated link on the canister. In this way, a seller (or anyone really) can make a payment request (invoice/payable) that’ll have a web accessible endpoint a payer can use to fullfill the payment by scanning a QR code. I’ll update this forum posting when complete.
