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

[dieter.sommer]

The fee collector seems to be a good topic for the discussion for the WG meeting on 2023-12-12. There seems to be a clear need that we go for a standard for the fee collector in order to enable clients to properly interpret the fee information and thereby properly reconstruct balances of ledgers.

[dieter.sommer]

@timo

Question about ICRC-2: what’s the purpose of the spender subaccount? It isn’t explained very well in the spec and the examples given there don’t use it. I suppose it exists so that the owner can define multiple independent allowances for the same spender, to segregate amounts to be used for different purposes and each with their own expiration. Is that the reason?

There was a decision in the WG that the ICRC token standards always use the account pair (principal, subaccount) in a consistent manner, i.e., also for the spender. This gives a conceptually cleaner design and also enables some additional functionality compared to using only the principal in some places. As you rightly point out, using an account for the spender allows for defining independent approvals / allowances. This comes with a slightly higher complexity for the API, but we thought it’s worth it. You are right that this is not really very well explained in the documents.

[gatsby_esp]

When will he have ICRC-3 avaialble on ckEth and ckBTC?
thanks

[dieter.sommer]

We will skip the WG meeting of December 26th due to Xmas holidays.

[dieter.sommer]

Please find the recording and minutes of the WG Meeting of November 28, 2023 linked below:
Recording
Minutes

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

[dieter.sommer]

Please find the recording and minutes of the WG Meeting of December 12, 2023 linked below:
Recording
Minutes

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

[timo]

In ICRC-2 are allowances supposed to be deleted by the ledger when they are expired or can the ledger delete them if the implementation wishes to do that? There is no interface that let’s the user explicitly delete an allowance.

In the spec it says

If there is no active approval, the ledger MUST return { allowance = 0; expires_at = null }

What exactly does “no active approval” mean? That there never existed one or that it is expired or that it is expired and deleted?

[skilesare]

The implementation can actively or passively clean them up. What is important is that after the expiration that the allowance returns 0 as you indicated.

We had an #Expired error but discussed that it could be confusing and require keeping excess data around so we decided to make it such that as soon as they expire, everyone should see them the same, ie 0.

[skilesare]

I’ve put up a draft for ICRC-4 that is a bit more ICRC-7y.

skilesare/ICRC/blob/main/ICRCs/ICRC-4/ICRC-4.md

@benji can you create an ICRC-4 branch for the ICRC and I’ll do a pull request?

[skilesare]

I’ve updated ICRC 4 with some instructions for updating the GENERAL ICRC schema such that a memo is recorded as normal in the first transaction processed in the memo field and subsequent items can have a memo-block at the top level to provide a pointer for log readers that want to reference the memo without repeating the data in every block. (We may need to extend this to ICRC7/30 that have batch-level memos as well).

There are alternatives here…we could put the memo block in the core trx as the memo is provided by the user, but the block number is provided by the system. Maybe some disambiguation is necessary @mariop .

[timo]

@skilesare

The implementation can actively or passively clean them up. What is important is that after the expiration that the allowance returns 0 as you indicated.

We had an #Expired error but discussed that it could be confusing and require keeping excess data around so we decided to make it such that as soon as they expire, everyone should see them the same, ie 0.

I understand this means that from the outside, for someone querying the ledger, it is indistinguishable whether an allowance never existed or whether it existed but expired.

What does that mean for the following usage pattern? Say A has created an allowance for B with amount x. Then A can query the allowance to see if B has used the allowance and how much B has used. If the returned amount is y < x then it means B has used x - y so far. But when we’re getting close to the expiration date then this strategy doesn’t work anymore because if we go over the expiration then the amount drops to 0 even if B hasn’t used it. So that means either A has to find other ways to monitor the usage of the allowances it has granted or has to not use expiration dates. Is that correct?

[skilesare]

Yes…I think you’d want to track that in some other way. Ideally, you’d have an indexing canister(or track the yourself) and could query on transactions with a spender equal to the spender and from equal to the account holder.

The approval accounting should have an initial approval record that can be started at…and additional approval records if the approval is manually changed.

[dieter.sommer]

Dear Working Group and community!

After ICRC-3 comes ICRC-4.

In the upcoming meeting on Jan 9, 2024, we suggest to continue the discussion regarding ICRC-4 ( Batch Transfers for ICRC-1 Fungible Tokens) as Austin has gone through some effort and finished another iteration on it.

ICRC-4 draft

See also Austin’s posts above on the recent ICRC-4 iteration.

Looking forward to the discussions tomorrow!

[dieter.sommer]

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

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

[skilesare]

I’ve updated the ICRC-4 spec given the discussions we’ve had during the NFT and Token WGs. Please send feedback.

skilesare/ICRC/blob/main/ICRCs/ICRC-4/ICRC-4.md

Most discussion seems to revolve around:

1. Do we include the transfer request with each response so that the implementation can dictate if it wants to process in order or not? Including it allows for more options and gives more power to implementors.
2. Do we dictate or leave open how to handle processing termination? We have removed a top level error that applies to the whole batch and allow the implementor to terminate with an error in the last entry or include entries with a null error if they are not processed due to termination.

[dieter.sommer]

Thank you for updating ICRC-4 after our related discussions regarding NFTs.

1. This is a good question. Including it means that we guarantee that all request elements are processed and that even before starting any processing, it is reasonably guaranteed that processing can be at least attempted for all request items and that there is enough space in the response for responses for all request items. This is all a bit constraining and the more I think about it, the more I like the idea of giving up the ordering. See my write up for the NFT-related transfer method (all arguments apply equally here as well). The variation of Option 2 is what reflects your option, the plain Option 2 is when removing the transfer: TransferArg from each response element and relying on ordering. It seems even nicer to me because of the potential simplifications of the implementation.
2. In my opinion the approach of relying on ordering of responses and allowing the implementation to terminate anywhere in the sequence, i.e., return only a prefix of all responses, is non constraining for the implementation, i.e., nice. The implementation can do parallel processing as it wants and if a batch-level error happens it does not proceed any further and caps the length of the returned prefix at the largest index it attempted to process in parallel. Elements for which processing has not yet been attempted can receive a null responses to save space. A special error would be semantically equivalent to the error for this case, but consume more space. Thus, doing it that way might make the implementation simpler as it makes fewer guarantees and assumptions.

In your updated API you simplified away the TransferBatchArgs, but you overlooked that it’s still in the method signature. The method parameter should change to vec TransferArg.

[dieter.sommer]

See my post on the new batch API for NFTs in my post in the NFT working group. The intention is to align the APIs of both the ICRC-4 and NFT WGs.

• Option 1 (for completeness) has full batch semantics and a top-level batch error.
• Option 2 is a full batch API with a flat error structure and relying on ordering, i.e., not repeating the request elements in the response. Also, the response need not contain all request elements.
• Variation of Option 2 is a full batch API, not relying on ordered responses, but repeating the request for each response. That is the NFT analogon of your proposal above.

[vafi]

Hi, I am very interested in joining this next webinar. How may I see it live?

[dieter.sommer]

Dear Working Group and community!

In the upcoming meeting on Jan 23, 2024, we will continue our discussion on ICRC-4 on batch transfers. The main decision to be made is the look and feel of the full-batch API, i.e., whether errors are handled as separate top-level structure or whether responses come in a flat list with per-item or per-batch errors.

ICRC-4 draft

Google Calendar, calendar browser link

[dieter.sommer]

In order to join, you find a Zoom link in the calendar entry for this meeting:
Google Calendar, calendar browser link

The meeting is called “Ledger & Tokenization Technical Working Group” and takes places every other week on Tue, 18:00 - 19:00 UTC+1 time. Today is the next one.

See my post above on the agenda for today’s meeting.