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

6 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.