Hi all, we are following up on the questions we received during the review process.
- Milestones - Please find below the milestones we submitted and the descriptions. They should give you a better idea of what we are building, why, and how. We’ve added A LOT of concrete details about the project in the reference docs.
- Question about canister architecture - In the lists of resource links below, you’ll find one about architecture diagram and sequence diagrams of calls between services (“High level overview with architecture and sequence diagrams”). The key components of our product are 1) frontend 2) links service 3) relying party wallet 4) transaction manager. The technical complexity for us mostly lies in the transaction manager. This is because we aren’t hard coding each transaction use cases each time we roll out a new link / transaction type. We are implementing a transaction orchestrator, so that we can configure any batch transaction in the backend, and the orchestrator will sequences and executes these as defined. And canister architecture-wise, we are putting all the 4 components above in the same canisterm for now. Given that we aren’t a social app (at least in the MVP stage), we don’t anticipate scalability issues with using one canister.
- Question about supported tokens - We’ll support ICRC-1 and 2 for now. We do plan to support ICRC-7 or EXT NFTs in the future, because we believe utility NFTs are very important for peer to peer transactions. But we need to prioritize what our capacity currently allows, so we aim to implement NFTs after the MVP.
- Comment that the product could enable for a more thriving, social-like DeFi experience. - Thank you for the feedback. We’ll keep that in mind. We also believe some sort of a social element would make the product more sticky.
- Question about which teams and users that they have validated the idea - We mainly interviewed general crowd in blockchain conferences, people in ICP hub, and ICPCC. To be fair, nobody said “we absolutely need that product. it will solve all of my problems” =). But what we noticed is there is no shortage of blockchain transactional interactions (people are using NFTs for entry passes or proof of attendance, invoicing each other via crypto, rewarding certificates with NFTs, giveaway of tokens, etc), while a lot of relevant transaction coordination is done painfully through chats offline, X, whatsapp, or telegram. With the MVP, we aim to hone in on the product market fit.
Milestones for the grant
The scope of the full MVP is to enable a user to build, no-code, a transaction page (URL link) for gifting tips to others. The technical goal for the MVP is to implement a transaction orchestrating mechanism that allows us to define and execute various types of batch transactions via configuration. This mechanism will help us quickly implement and test market demand for different link types, after the MVP.
By the half-way point (1.5 months from now), we aim to implement most of the aforementioned mechanism, except for the wallet-related parts. We should be able to demo a user creating a tip link, and transferring the fee to treasury and asset to link vault. This batch transaction would be configured and executed with the orchestrator. We may need to mock the ICRC-112 execution on the wallet side, but other parts of the transaction flow should work as we designed.
Below are more details on the deliverables for the half-way point:
- Frontend UI - Users should be able to log in via Internet Identity, pick a link type (initially only give-tip is available), choose which asset and amount to tip, and execute a batch transaction to transfer service fee to the treasury and the tip asset to the link vault. The UI will be optimized for mobile web, to encourage use on a phone.
- Link state machine - We will implement a state machine that aligns the frontend UI, link backend activities, and transaction states. The state machine will check which step in the link is in its lifecycle (user picks link type, user chooses link asset, user create the link, active, inactive). And for each link type, we will configure what conditions need to be met to transition to a next state. For example, with a give-tip link, when the user chooses what asset to tip and how much, they need to pass a validation that confirms enough balance is in their wallet to allow the link (and the corresponding UI page) to go to the create link step.
- User intents - Intents are chain-agnostic transaction descriptors that define 1) what assets should be transferred from wallet to link (or vice versa), 2) in what sequence, and 3) if there are dependencies between the transfers. Each user action (i.e. create link, pay invoice, tip claim, swap, airdrop claim, etc) in Cashier is effectively defined with a set of intents. The intents, saved as JSON, are enriched with asset and amount info that user enters in the link creation UI flow.
- Chain adapter (IC) - We call the chain adapter to translate the chain-agnostic intents into relevant IC protocol requests: ICRC-1 transfer, ICRC-2 approval, or ICRC-2 transfer. These IC requests are also saved in JSON for now, until the transaction manager executes them. Other requests such as ICRC-7 or EXT NFT creation or transfers will be out of scope for the MVP.
- Transaction manager is what orchestrates transaction sequencing and dependencies, and triggers relevant request calls via user wallet or the link canister. For example, there are heuristic rules that transaction manager follows to group multiple transfers from the wallet to link into ICRC-112, so that user needs to approve once. Another example would be a swap, where the transaction manager checks for transaction dependencies. The assets escrowed in the link canister is transferred to a user only after the transaction manager has confirmed that the user sent the swap assets to the link first via ICRC-112.
- Wallet UI and backend- Wallet will be the scope of the final milestone. Please see below for more details. For the purpose of demo, we may mock the asset top up.
- Wallet ICRC-112 handler - Wallet will be the scope of the final milestone. Please see below for more details. For the purpose of demo, we may mock the ICRC-112 execution.
By the final milestone (3 months from now), we should also have implemented the remaining UI for give-tip link and the remaining wallet functionalities. Hence, we should be able to demo the end-to-end process of topping up the Cashier wallet, creating a give-tip link, and claiming the tip.
For our current team size, it may be a stretch to commit to demo’ing all other link types (i.e. airdrops, token baskets, invoice payments, swaps) within 3 months at the final milestone. But we could aim to demo the backend, without the UI. We could configure the relevant batch transactions and link state machine rules in the backend, and partially demo how the transaction orchestration in the backend can handle batch transactions needed for new link types.
Key deliverables for the final milestone are:
- Frontend UI - Users should be able to claim from the give-tip link. Link creator should be able to end the link and withdraw / reclaim assets.
- Link state machine - Configure link state rules for other link types: airdrops, token baskets, invoice payments, swaps.
- User intents - Configure set of intents for other link types: airdrops, token baskets, invoice payments, swaps.
- Chain adapter (IC) - No changes
- Transaction manager - No changes
- Wallet UI and backend- We will implement a UI for users to toggle between the UI to create links and to manage their assets on a Cashier wallet. The wallet will be a relying party wallet that signs transactions via their internet identity. They will be able to see ICRC-1 and ICRC-2 tokens and balance, send tokens, receive tokens.
- Wallet ICRC-112 handler - Though Cashier wallet is a relying party wallet, we will implement and execute ICRC-112 according to the standard, so that our end-to-end transaction flow in Cashier works with account delegation wallets that later implement ICRC-112. We have currently integrated with NFID Identity kit. We will later enable any wallets that implement ICRC-112.
Please find below resources with more details relevant to both mid & final milestones:
High level overview with architecture and sequence diagrams:
UI screenshots of the give-tip link and wallet
Overview of how links work:
Overview of how transactions work:
More details on tx - mapping of links to intents:
More details on tx - mapping of intents to IC transactions:
Generic overview of Cashier project: