All or nothing batch transaction ICRC standard?

Developers
9

I want to clarify a few things here.

  1. As an ICP user, making an ICP transaction from an app to a ledger on ICP doesn’t hold up other ledger transactions from happening. There’s general message, ingress, and instruction limits, but ledgers on ICP are quick and can process thousands of transactions per round of consensus (~2-4 sec). The call is quick if the call is made from a principal/delegate identity on the frontend (log in with II, Plug, NFID, any ecosystem wallet).

  2. Canisters can send hundreds of calls (transactions) at a time in parallel to any other canister right now. That’s what this icrc2-batch library does. The current ~500 call limit canister A → canister B comes from canister output queue limits, which could be raised in the future.

  3. Referring to point #1, making calls with a delegated identity will always be quick. The slowdown in the case I’ve described occurs when an application wants to perform the transaction asynchronously via an inter-canister call to perform a transaction without triggering a wallet pop-up for UX purposes. For example, the ICRC-2 standard (approve/transfer_from) allows a user to approve another principal (user or app) to spend X amount of funds on their behalf. This enables things like recurring payments, or transferring funds without needing to click yes to transfer funds for every single action, and utilize the X amount of funds that have been previously approved.

    In our case, we’d like to be able to trigger these transactions through a canister for improved UX on the user’s behalf (no endless popups), as well as to assess fees on top of each payment that is made. That’s the primary reason why we’re going through the canister to perform each of these actions.

With that context in place, having an all-or-nothing batch endpoint, where all calls are made to the same ledger canister would reduce the number of edge cases and complexity that apps need to handle. Projects on ICP want to both provide value and make a profit, and this would help with both!

State changes within a canister are synchronous in nature within a round of consensus, so going from ICRC-4 (batch transactions) which is already in place, to all-or-nothing batch transactions isn’t a technical problem. It’s just something that the ICRC standards community needs to align on and prioritize.

The main point of this forum post from my side was to trigger a conversation, and learn if any work is being done on this front.

Moving forwards is both as easy (and as hard) as getting community consensus to both implement (code) and upgrade (governance) existing token ledgers (ICP, ckBTC, SNS, etc.) to support all or nothing batch transactions. I’d expect ICRC-4 to come first (batch transactions, without all-or-nothing), but this is a nice addition.

@quint above mentioned ICRC-7, which upon reading more about ICRC-7

" icrc7:atomic_batch_transfers of type bool (optional): true if and only if batch transfers of the ledger are executed atomically, i.e., either all transfers execute or none, false otherwise. Defaults to false if the attribute is not defined."

The atomic batch transfer referenced in this quote is stored this in the canister’s metadata, which makes me thing that all batch transactions on the canister are either atomic or not. I’m not sure why there isn’t the option to perform both atomic and non-atomic batch transfers on the same canister/ledger :man_shrugging: , but maybe that’s a point for discussion moving forwards.

2 Likes