Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group

@skilesare, @sea-snake, all

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.

What do you / others think?

Looks good…I’ll try to mirror on ICRC4.

1 Like

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?

1 Like

There is no rule but everything that affects balances should be recorded as transaction.

2 Likes

The next WG meeting is today, February 6, 2024. The proposed agenda is to continue discussions on ICRC-4.

ICRC-4 draft

Google Calendar, calendar browser link

Please find the recording and minutes of the WG Meeting of January 23, 2024 linked below:
Recording
Minutes

You can find all the recordings, chats, and slides of all meetings here:
All files of all meetings

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.

3 Likes

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.

2 Likes

@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:

$ dfx canister --network ic call mxzaz-hqaaa-aaaar-qaada-cai icrc1_supported_standards
(
  vec {
    record {
      5_843_823 = "https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-1";
      1_224_700_491 = "ICRC-1";
    };
    record {
      5_843_823 = "https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-2";
      1_224_700_491 = "ICRC-2";
    };
  },
)

The SNS team is working on enabling ICRC-2 in the SNS Ledgers.

1 Like

Hi,
I posted a message about ICRC-3 delay in case anybody is wondering what’s going on.

1 Like

I made some minor comments, mostly editorial, on ICRC-4. We can go over them in the meeting later this afternoon.

1 Like

Please find the recording and minutes of the WG Meeting of February 06, 2024 linked below:
Recording
Minutes

You can find all the recordings, chats, and slides of all meetings here:
All files of all meetings

Updated icrc4 here ICRC/ICRCs/ICRC-4/ICRC-4.md at main · skilesare/ICRC · GitHub

1 Like