Please find the slides and recordings of the meetings here.
Meeting of 2024-07-23
Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group
As discussed, please find a draft for ICRC-22 on payment requests here.
Progressed well, but still some decisions to be made and work required.
Please find the slides and recordings of the meetings here .
Meeting of 2024-08-20 (Semi-fungible tokens)
1 Like
I have an overlap for the WG meeting today with a meeting I have to attend (also true for others from DFINITY who are involved in the WG). I leave the standing slot available in case folks want to discuss nevertheless. Thanks!
The topic for the WG meeting this afternoon is ICRC-103: Enhanced Allowance Query Mechanism with Pagination.
The standard looks good according to the (reduced) WG. The only things we saw that may need to be fixed are the following:
- The termination condition when a client knows that no more allowances would follow in a subsequent query of a sequence of queries is not specified. We think it should be the same as in ICRC-7: āWhen a response comprises fewer elements than take or the icrc7:default_take_value, respectively, iterating can be stopped as the end of the token sequence has been reached. Using this approach, all tokens can be enumerated in ascending order, provided the ledger state does not change between the method calls.ā
- If we want to make the termination condition the same as in ICRC-7, we may want to think about introducing an icrc103:default_take_value much like the one in ICRC-7. Alternatively, we specify that the default is the icrc103:max_take_value, which is the implicit assumption now in my view.
Once those things are explicit, this looks good to go.
The termination condition when a client knows that no more allowances would follow in a subsequent query of a sequence of queries is not specified. We think it should be the same as in ICRC-7: āWhen a response comprises fewer elements than take or the icrc7:default_take_value, respectively, iterating can be stopped as the end of the token sequence has been reached. Using this approach, all tokens can be enumerated in ascending order, provided the ledger state does not change between the method calls.ā
This is a consequence of the semantics and it may be worth spelling out though so Iāll add something along these lines in the draft
If we want to make the termination condition the same as in ICRC-7, we may want to think about introducing an icrc103:default_take_value much like the one in ICRC-7. Alternatively, we specify that the default is the icrc103:max_take_value, which is the implicit assumption now in my view.
Currently the default value for take is indeed max_take_value. Is there some usecase where a default_value is also needed? Iāve clarified the text to indicate that max_take_value is the default value (if take is not specified).
1 Like
Please find the slides and recordings of the meetings here.
Meeting of 2024-10-15
Topic: ICRC-22 payment URIs
A question about ICRC-1 and its extensions.
The ICRC-1 standard has no notion of blocks, block heights, etc. (intentionally). Hence, it has no notion of ātimeā. If I call icrc1_balance_of then I get the ālatestā balance but I donāt know if that balance was from before or after a certain transaction.
The ICRC-3 standard has blocks with transfers but not balances.
So there is no way to get balance and ātimeā together. Is that right? I mean except for retrieving all blocks relevant for the principal with ICRC-3 and replaying the whole history.
Actually, ICRC-1 has some notion of time because icrc1_transfer return the tx index which is ordered. If icrc1_balance_of returned the balance and the last tx index that was taken into account that would be much better.
If I remember correctly, icrc1_balance_of is a query call so you should get the time back in the query call response certificate.
For example agent-js uses this timestamp as āwatermarkā to make sure that the data of a returned query call is always newer than a previously fetched query call. This prevents bugs where you are e.g. polling and you receive older data after you previously received newer data from a different subnet node.
Keep in mind this bug does re-appear if you have multiple agent instances, since the watermark is per agent instance, thatās why I would recommend to re-use an agent instance where possible across actors.
So overall, the IC has a notion of time, response certificates always include the time at which the response was created.
This may be a good thing to consider before we finalize icrc4 as we can easily add an endpoint that queries 1-n balances and returns the height.
You mean add it to the return value of icrc4_balance_of_batch? Or create a separate query function for it?
Thatās correct but solves a somewhat different problem. I can know the subnet time of the state against which my query was executed. But that doesnāt tell me if a certain transfer was included before this time or not. Unless I know the timestamp of that transfer, but usually I only know the block height of the other transfer because that is what icrc1_transfer returns.
But most importantly, the query timestamp you mention is not available to other canisters. I am also interested in the ledger API from the perspective of other canisters making transfers and balance queries.
1 Like
Maybe a separate one? We can discussā¦ we have some icrc4 floating around, but not much. Which do you think is preferable?
If the standard isnāt frozen yet then I would add it to the existing endpoint. Make it return a tuple where second field is the block height (or last tx id).
And the same for getting batches of allowances but thatās not part of icrc4, or?
I think that is sensible. Iāll draft it when I get a chance and follow up.
Noā¦we need to write the icrc2 batch equivalent. Itās been on the list for a while, but allowing a bunch of accounts seems to be. rarer use case then blasting out multiple payments.(but as you mention in one of your other posts, maybe safer).
We decided to cancel the meeting of this afternoon as there is no topic linued up that people had time to make progress on.