Icrc4

[skilesare]

Batch functions to complement ICRC-1.

[iclighthouse]

1. icrc4_transfer_batch needs to achieve atomicity.
   In batch transfers, either all succeed or all fail.

2. It is recommended to remove unnecessary rules and keep the standard concise and easy to use.
   Some personalized and specific requirements should not be included in the standard, otherwise it will bring two types of negative effects: (1) the implementation of token code is too complicated; (2) more logic processing needs to be written when dapp uses the standard interface.
   Some rules don't need to be written in the standard, but Token developers can customize them without affecting the standard usage scenarios.

type TransferBatchArgs = record {
    pre_validate : bool;
    transactions : [TransferArgs];
    batch_fee : opt nat;
};

I don't think pre_validate and batch_fee need to be included in the standard, follow the rules of TransferArgs and icrc1_transfer, but here is an array, so TransferBatchArgs = vec TransferArgs would be better.

icrc4_validate_batch: (ValidateBatchArgs) -> (variant { Ok : (); Err : TransferBatchError }) query;

No need for additional checks, no new restrictions introduced.

icrc4_metatdata : () -> (ICRC4Metada) query;
type ICRC4Metada = record {
    max_transactions : opt nat;
    max_balances : opt nat;
    batch_fee: opt nat;
};

There is no need to configure these limit parameters.

[skilesare]

Initial thoughts and more detailed reasoning:

icrc4_transfer_batch needs to achieve atomicity.
In batch transfers, either all succeed or all fail.

This is impossible to guarantee on the IC. Future token canisters may be multicenter and involve one or many async calls. ICRC1 makes no assumptions about token canister architecture and it would a complication to introduce this assumption.

I don't think pre_validate and batch_fee need to be included in the standard, follow the rules of TransferArgs and icrc1_transfer, but here is an array, so TransferBatchArgs = vec TransferArgs would be better.

Because atomicity is not possible to guarantee, I'd argue the prevalidate provides the next best alternative to attempting to have as many transactions pass as possible. I don't think it is optional for this kind of transaction. the batch fee is optional and can be omitted, but provides a rational pathway to the reality that submitting 1000 batch transactions does not cost 1000x a single transaction. It decreases the cost of moving money and increases the possible uptake of the token.

There is no need to configure these limit parameters.

Given the reality of how the IC works, I'd say that it is highly advisable to have these limits defined by the service. Cycle limits may apply and ledgers may want to reject a certain amount of transactions so as to not block the canister. They are optional so a ledger can choose to not provide them, but a production-level ledger expecting significant transactions my need to keep from being attacked, and defining the interface lets providers agree on how to check the ledger.