While writing up the discussed changes regarding the batch API for ICRC-7, my finding is to make a slight adjustment to how the API is presented:
type TransferResult = variant {
Ok : nat; // Transaction indices for successful transfers
Err : TransferError;
};
// icrc4_transfer_batch method definition
icrc4_transfer_batch: (vec TransferArg) -> async vec opt TransferResult;
I.e., to have a TransferResult instead of a BatchTransferResult and moving the vec and opt into the method signature. This makes the correspondence of the TransferArg and TransferResult and the optionality of the latter in the vector immediately clear. I think having the vec opt in the method signature helps a lot with communicating the positional parameter idea in the API.
GM Folks. Just looking for a 2nd opinion on how to read the standards of ICRC-1. Iāve come across a couple of ICRC-1 canisters which have caused the 221Bravo Indexer to crash.
The error Iām getting is that transfers are being made from new/unknown accounts. Digging into this Iāve found that these ledgers have a pre-mint account which is populated with a sum of tokens. This is not recorded in the ledger as a mint transaction. This means that the first transactions recorded on the ledger appear as a ātransferā from the āpre-mintā account.
My understanding is that to adhere to ICRC-1 the first transaction on the ledger would ALWAYS be a mint transaction?
Iād further state that we will all be a lot better off if we get to a place where all serious IC utility canisters provide a transaction log that can be used to reconstruct current state from canister genesis. This is harder to do than at first blush considering code upgrades, but we should at least attempt to do so. We probably need a lot more conversation about how to practically do this, and maybe even a few written out ārulesā to codify it.
The standard ICRC-1 defines a function icrc1_supported_standards. I checked a couple of ledgers and for all of them this function returns only one entry:
(vec { record { url = "https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-1"; name = "ICRC-1" } })
even though they actually do have an ICRC-2 interface. I checked SNS-1, OpenChat and GLDT ledgers and it was like that for all three.
I suppose ICRC-1 intends that it is mandatory to return the correct list of supported standards.
@timo, thanks a lot for your comment, this is indeed an omission in the implementation. If ICRC-2 is implemented by an ICRC-1 ledger, it is, as you suggest, mandated that it be mentioned in the response of icrc1_supported_standards.
Any ledger supporting ICRC-2 MUST include a record with the name field equal to "ICRC-2" in that list.
@mariop, can you take care of this being fixed in the implementation, please?
SNS Ledgers do not support ICRC-2 yet and therefore icrc1_supported_standards doesnāt return ICRC-2. The Ledger uses runtime feature flags for new features which means the endpoint exist but trap if the feature is disabled. You are not supposed to use standards that are not listed by icrc1_supported_standards.
The SNS Ledgers share their code with the ckBTC Ledger. Differently from the SNS Ledgers, the ckBTC Ledger has the ICRC-2 feature flag enabled. You can see the ckBTC Ledger icrc2_supported_standards correctly returns ICRC-2 as supported standard:
Do you have any proposals for discussion items for the upcoming meeting tomorrow, March 05? I have ICRC-22 on my backlog, but canāt prepare it for tomorrow due to time reasons, but we can discuss it in one of the upcoming meetings after that.
If thereās no proposals, Iāll cancel the meeting for tomorrow.
We have a topic of broad interest for tomorrowās agenda:
ICRC-3
Specifically, the session will be centered around the following issues discussed on the forum already, see the original post and the following discussion for details.
@mariop will be presenting and driving the discussion!
Hope to see many of you there, I know many people are waiting for ICRC-3 to be finalized and resolving those issues is a key missing piece of the puzzle.
See you tomorrow!
See the Google Calendar link for schedule and dial-in details.