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

NS01 · September 21, 2023, 8:09pm

I hope the old endpoint still works and captures movements of tokens… it will be a real pain to modify all the ICRC index canisters I’ve just setup for 221Bravo.

Got about 30 canisters churning through transaction data. Looking to add OGY sometime soon

mariop · September 22, 2023, 11:32am

Yes, it will find approve https://github.com/dfinity/ic/blob/56800b234dc986c14e8730ba9c26f29811c3db79/packages/icrc-ledger-types/src/icrc3/transactions.rs#L65.

NS01 · September 22, 2023, 7:06pm

Ah ok - am I right in thinking that approve transactions dont change the balance of an account and only earmark funds that can be transferred on another users’ behalf? Is the changing of balances still done with a transfer transaction?

Or am I way off?

mariop · September 22, 2023, 8:00pm

Tokens are transferred by icrc1_transfer or a icrc2_transfer_from but icrc2_approve charges a fee for recording the approval and therefore it changes the balance of the “approver”.

For instance, let’s say that Alice approves Bob. If the approval is successful then the balance of Alice has been decreased of the fee. That’s the only balance that changes.

dieter.sommer · October 2, 2023, 3:24pm

Dear Working Group!

Due to absence of almost everyone from DFINITY side tomorrow, I suggest to cancel the WG meeting of October 3.

sea-snake · October 2, 2023, 3:25pm

Thanks for letting us know

dieter.sommer · October 17, 2023, 1:44pm

Dear Working Group!

The next WG meeting is taking place today, October 17, 2023.

As discussed in the recent meeting, the topics are the following:

Payment request formats
HTTP request namespacing (if time)

Hope to see you there!

dieter.sommer · October 30, 2023, 2:00pm

Please find the recording and minutes of the WG Meeting of October 17, 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 · October 30, 2023, 2:02pm

Dear Working Group!

The next WG meeting is taking place tomorrow, October 31, 2023.

As discussed in the recent meeting, the topics are the following:

ICRC-22 — URI Format for Payment Requests
- Revisit the open items based on the new draft.
HTTP Request Namespacing
ICRC-4: Batch Transfers

We will cover then depending on availability of people and time.

Hope to see you there!

NS01 · October 30, 2023, 2:11pm

Is ICRC-3 complete now? Is that it set

mariop · October 30, 2023, 2:57pm

Hey @NS01, I’m still working on it. I had to put it aside for a few weeks to deal with other features but I should be able to produce a full spec for next WG together with a tool to verify the compliance of blocks to the ICRC-3 schema. A preview of the tool is already available here and is part of icrc-ledger-types 0.1.3.

skilesare · October 31, 2023, 2:07pm

I’ve made a formal recommendation on the ICRC-23 - HTTP request namespacing and would love feed back. We can also discuss more on the call:

dieter.sommer · November 1, 2023, 3:40pm

Please find the recording and minutes of the WG Meeting of October 31, 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 · November 10, 2023, 2:10pm

Dear Working Group and community!

In the upcoming meeting on Nov 14, 2023, we suggest to discuss ICRC-3 as progress has been made towards resolving remaining issues and completion of the standard.

ICRC-3 draft

dieter.sommer · November 28, 2023, 10:27am

Please find the recording and minutes of the WG Meeting of November 14, 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 · November 28, 2023, 2:41pm

In today’s meeting of Nov 28, 2023, we suggest to continue the discussion on ICRC-3.

ICRC-3 draft

mariop · November 29, 2023, 12:16pm

Hi, the second draft of the ICRC-3 standard is available (see this). People part of the working group can now vote to make the proposal official Vote on the second draft of ICRC-3 · Issue #169 · dfinity/ICRC-1 · GitHub.

dieter.sommer · November 29, 2023, 2:05pm

propose a minor extension to ICRC-3 that specifies how future ICRC standards that build on top of ICRC-3 should name their op in order to avoid naming clashes.

See ICRC-3 by MarioDfinity · Pull Request #128 · dfinity/ICRC-1 · GitHub.

tl;dr
We need to namespace the op that goes into blocks. My proposal is to keep is as succinct as possible: For the transfer_from operation defined in ICRC-xy, the op must begin with the prefix xz, e.g., 30xfer_from or only 30xfer (still readable, but shorter).

Proposal for naming:

Prefix is the ICRC number without the string ICRC- to keep it shorter.
The actual op name must then start with a letter character.
The following characters can be alphanumeric and “_” and “-”

I.e.:

op = icrc_number op_name
icrc_number = nonzero_digit *digit
nonzero digit = "1" "2" "3" "4" "5" "6" "7" "8" "9"
digit = "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
op_name = a-z *(alphanumeric \ "_" \ "-")

What do people think about this? We need this for the NFT standards that are coming up and we should define something.

At the bare minimum, we could fix the ICRC number as prefix, followed by anything not starting with a number to keep it as unconstrained as possible.

dieter.sommer · November 29, 2023, 2:14pm

Here would be a proposal of a first draft of the ICRC-3-compliant block schema for ICRC-7 using the above namespacing proposal. That would be the first “customer” of ICRC-3 besides the “built-in” ICRC-1 and ICRC-2.

github.com

dfinity/ICRC/blob/icrc7-wg-draft/ICRCs/ICRC-7/ICRC-7.md#icrc-7-block-schema

|ICRC|Title|Author|Discussions|Status|Type|Category|Created|
|:----:|:----:|:----:|:----:|:----:|:----:|:----:|:----:|
|7|Minimal Non-Fungible Token (NFT) Standard|Ben Zhai (@benjizhai), Austin Fatheree (@skilesare), Dieter Sommer (@dietersommer), Thomas (@sea-snake), Moritz Fuller (@letmejustputthishere), Matthew Harmon|https://github.com/dfinity/ICRC/issues/7|Draft|Standards Track||2023-01-31|



# ICRC-7: Minimal Non-Fungible Token (NFT) Standard

ICRC-7 is the minimal standard for the implementation of Non-Fungible Tokens (NFTs) on the [Internet Computer](https://internetcomputer.org).

A token ledger implementation following this standard hosts an *NFT collection* (*collection*), which is a set of NFTs.

ICRC-7 does not handle approval-related operations such as `approve` and `transfer_from` itself. Those operations are specified by ICRC-30 which extends ICRC-7 with approval semantics.

## Data Representation

This section specifies the core principles of data representation used in this standard.

### Accounts

This file has been truncated. show original

Comments welcome also from this WG as this is an inter-WG affair.

dieter.sommer · November 29, 2023, 3:36pm

Here’s another application of ICRC-3 in ICRC-30 (draft):

github.com

dfinity/ICRC/blob/ICRC-30-Approval_support_for_ICRC-7_NFTs/ICRCs/ICRC-30/ICRC-30.md#icrc-30-block-schema

|ICRC|Title|Author|Discussions|Status|Type|Category|Created|
|:----:|:----:|:----:|:----:|:----:|:----:|:----:|:----:|
|30|Approval Functionality for the Non-Fungible Token (NFT) Standard|Ben Zhai (@benjizhai), Austin Fatheree (@skilesare), Dieter Sommer (@dietersommer), Thomas (@sea-snake), Moritz Fuller (@letmejustputthishere), Matthew Harmon|https://github.com/dfinity/ICRC/issues/30|Draft|Standards Track||2023-11-22|



# ICRC-30: Approval Support for the Minimal Non-Fungible Token (NFT) Standard

This document specifies approval support for the ICRC-7 minimal NFT standard for the Internet Computer. It defines all methods required for managing approval semantics for an NFT token ledger, i.e., creating approvals, revoking approvals, querying approval information, and making transfers based on approvals. The scope of ICRC-30 has been part of ICRC-7 originally, however, the responsible Working Group has decided to split it out into a separate standard for the following reasons:
  * ICRC-7 and ICRC-30 are much easier to navigate and shorter on their own due to their respective foci;
  * Ledgers that do not want to implement approval and transfer from semantics do not need to provide dummy implementations of the corresponding methods.

This standard extends the ICRC-7 NFT standard and is intended to be implemented in token ledgers that implement ICRC-7.

## Concepts

Approvals allow a principal, the *spender*, to transfer tokens owned by another account that has approved the spender, where the transfer is performed on behalf of the owner. Approvals can be created on a per-token basis using `icrc30_approve_tokens` or for the whole collection, i.e., all tokens of the collection, using `icrc30_approve_collection`. An approval that has been created, has not expired (i.e., the `expires_at` field is a date in the future), has not been revoked, and has not been replaced with a new approval is *active*, i.e., can allow the approved party to initiate a transfer.

When an active approval exists for a token or for an account for the whole collection, the spender specified in the approval can transfer tokens in the scope of an approval using the `tranfer_from` method. A successful transfer also revokes the corresponding approval if it is a token-level approval. Collection-level approvals are never revoked by transfers.

This file has been truncated. show original

Topic		Replies	Views
ICRC-1 Token Standard final draft Developers	40	3726	February 28, 2023
Ledger & Tokenization Working Group Update Developers	47	3667	December 12, 2022
ICRC-1 Token Standard Ledger Developers	128	6997	September 22, 2022
Voting results for the ICRC-1 Fungible Token Standard and next steps Developers	12	1049	July 21, 2022
Call for Participation: NFT Token Standard Working Group [Status Updated] Developers	248	9012	December 2, 2024

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

Related topics