ICRC4 - Batch Transfers - Nearing Finalization - Please Review

Roadmap
1

The tokenization and ledger working group is getting close to finalizing ICRC-4 - Batch Transfers.

The current spec can be seen below:

Please provide your feedback here or at ICRC-4: Batch Transfers · Issue #4 · dfinity/ICRC · GitHub

We’d love to have more participation in the working group, so feel free to join us. Consult the working group calendar: Internet Computer Events

7 Likes
2

Added some extensions for this idea to the Developer Feedback board since this extends to ICRC-2 and Cycles Ledger withdraw().

https://dx.internetcomputer.org/topic/225

2 Likes
3

I’m very excited for this feature to get standardized, if the cycles ledger could implement this along with pre-signed transactions, we might be able to implement a cycle compensation model.

Would these batch transfers work with a possible future pre-signed transaction standard?

4 Likes
4

We haven’t started tackling pre-signed transactions and on our last call @mariop said there is a bit more research to do there. I’m hopeful that this would be the case.

I’m curious about your use case here though. Are you imagining a canister having to distribute out many payments to many source code owners at once? Or something else?

1 Like
5

Cycle Compensation I believe is best done at least technically at the protocol level.

But if we are to do it at the application level, I’m imagining it would work like this:

All canisters wanting to engage in cycle compensation would expose a query or update method (not sure if we’ll need to store state). This method would be automatically installed in the case of Azle of Kybra for example.

The overarching theme here is ~0 friction. DO NOT MAKE THE PAYING DEV DO ANYTHING. As soon as you do the idea is done; a bit of hyperbole but that’s my guiding principle here.

So by default the open source library installed can include this method. The method when called would look at its cycle usage over a certain period of time, and would also look at its dependencies. In the case of Azle for example, the package-lock.json or dfx.json or some other kind of config file included in the canister on deploy could have a field in each library called “funding” or “cycle_compensation” or something like that. It would be an address or principal.

So this method would loop through the config file, gather all of the addresses, apply a heuristic and return the addresses with the number of cycles to issue out. It would pre-sign all of the transactions.

This would allow some kind of centralized server infrastructure (doing this in a canister just seems infeasible at scale) to query all canisters for this method, and batch all pre-signed transactions to submit to the ledger canister.

This is the most promising way that I can think to implement cycle compensation thus far at the application level.

6

So in short, yes I imagine each canister distributing many cycle payments to its dependencies at once.

7

@skilesare Any updates on ICRC-4 Batch transfers?

8

We have general consensus on the standard. The Pan Industrial ICRC Suite has it implemented already and it is alive and working with tokens that use it such as $ICDV(https://dashboard.internetcomputer.org/canister/agtsn-xyaaa-aaaag-ak3kq-cai).

I’m not sure what the priority is for DFINITY to do security reviews and get it integrated with ICP/SNS tokens, but they have a much higher bar to clear for existing tokens than for those deploying new code and I have not heard of work starting on that yet, so I would not expect it in immenately.

2 Likes
9

hm i have some comments
perhaps we can remove the _batch suffix from the update methods? since icrc7 update methods dont have this suffix

10

also one more; we might wanna change maximum_ to just max_ on the query methods and the metadata keys to make it consistent with icrc7

11

Both are great suggestions.

12

Hi any update on this ICRC4 release day?

13

Also curious if there has been any progress with this.

14

As far as I know there has not been any progress on incorporating ICRC-4 into the SNS or ck or ICP tokens as a patch for ICRC-2 is currently being worked on. If you would like to deploy an ICRC-4 token you an use a motoko token which already has it implemented and ready to go. See https://youtu.be/qdAMo_kLVkg

15

Is there a timeline for this? Im interested to know when sns and other icrc tokens get this feature.