Call for Participation: NFT Token Standard Working Group [Status Updated]

NFT Token Standard Working Group

We at DFINITY are dedicated to providing better developer experiences and driving adoption. Along with members of our great community, we created the first Fungible Token Standard ICRC-1. The standard is seeing increasing adoption and is paving the path for easier integrations. We’re looking to further our efforts by creating a working group for an NFT standard, and we’d like to call out to all members of our community to participate and to contribute.

Summary

  • Call for participation open to everyone
  • Starting with weekly meetings:
    Tue 29nd Nov, @ 17:00 CET (calendar)
    The meetings will be bi-weekly after the initial phase.
  • GitHub will be used as main discussion board. Link will follow shortly.

Goal

The goal of this working group is to create a baseline NFT standard to facilitate development and integration. Extensions can be foreseen for the future.

Organisation

This working group is derived from the Ledger & Tokenization Working Group, but we decided to form a new working group because this standard potentially appeals to a different audience. We will follow the format of the Ledger & Tokenization Working Group.

7 Likes

Thats very interesting! What can we do to participate?

We would like to contribute to make physical assets tokenizable according to the romano-germanic civil law that is currently being ammended in some countries.

Hi, you can participate by participating in the WG meetings.

Regarding Transaction History

The working group is currently assessing metadata to be associated with transaction history. Here I advocate we should strive for feature parity with CAP, as the incumbent with overwhelming capture.

That Psychedelic steps back at the same time this group attempts to standardize transaction history presents an opportunity to ship an implementation with very broad near-term impact. As a caveat, of course CAP isn’t perfect, and we should be comfortable when differing from it.

General Lessons From CAP

  • Motoko and Rust libraries make it trivial to add tx history to your canister.
  • Hugely flexible data model is future-proof and extensible, but means unreliable data.

Transaction History Events

CAP employs an incredibly flexible data model, allowing developers to store basically anything they want:

public type Event = {
    time : Nat64;
    operation : Text;
    details : [(Text, DetailValue)];
    caller : Principal;
};
public type DetailValue = {
    #I64 : Int64;
    #U64 : Nat64;
    #Vec : [DetailValue];
    #Slice : [Nat8];
    #Text : Text;
    #True;
    #False;
    #Float : Float;
    #Principal : Principal;
};

Developers made typos and forgot to add certain values, so the data was very inconsistent as a result.

The flexible model also provides extensibility, which may be a critical property. Consider the exercise of trying to determine a finite set of operations: ICRC has mint, transfer, and burn, but what about sale and list? Can we reliably predict future use cases, such as rent, delist, fractionalize, and so on? Should the standard leave room to support innovative tx history use cases?

Some Real CAP Event Types

I would recommend adding the “sale” event type to ICRC, considering the importance of marketplaces to the NFT ecosystem (sorry if this is already included, couldn’t find the reference.) Here’s an example CAP event:

// Sale (BTC Flower)
{
  "time": 1670588669701,
  "operation": "sale",
  "details": [
    [
      "to",
      {"Text": "58a0fcbd3ae8d5589f9b7e3208b979867b44d04b8d4d1bfe2ede9f641973243f"}
    ],
    [
      "from",
      {"Principal": "jqazm-bdzbj-hnq3o-yexug-vqu3v-jonju-7ngcp-4yzbw-jyux4-lqejy-mae"}
    ],
    [
      "price_decimals",
      {"U64": 8}
    ],
    [
      "price_currency",
      {"Text": "ICP"}
    ],
    [
      "price",
      {"U64": 18000000000}
    ],
    [
      "tokend_id",
      {"Text": "jz2z7-3akor-uwiaa-aaaaa-beaag-maqca-aaaq7-a"}
    ]
  ],
  "caller": "s4d6r-c23m5-5gapy-myo3t-7pgtm-pdf6g-3nepw-hfcnc-2ohyg-p6qqq-rae"
}

A “mint” event can also have a purchase price associated with it, as we see with this example:

// Sale (BTC Flower)
{
  "time": 1670588669701,
  "operation": "sale",
  "details": [
    [
      "to",
      {"Text": "58a0fcbd3ae8d5589f9b7e3208b979867b44d04b8d4d1bfe2ede9f641973243f"}
    ],
    [
      "from",
      {"Principal": "jqazm-bdzbj-hnq3o-yexug-vqu3v-jonju-7ngcp-4yzbw-jyux4-lqejy-mae"}
    ],
    [
      "price_decimals",
      {"U64": 8}
    ],
    [
      "price_currency",
      {"Text": "ICP"}
    ],
    [
      "price",
      {"U64": 18000000000}
    ],
    [
      "tokend_id",
      {"Text": "jz2z7-3akor-uwiaa-aaaaa-beaag-maqca-aaaq7-a"}
    ]
  ],
  "caller": "s4d6r-c23m5-5gapy-myo3t-7pgtm-pdf6g-3nepw-hfcnc-2ohyg-p6qqq-rae"
}

Some projects opted to add the “memo” field:

// Transfer (Cronics)
{
  "time": 1670345256752,
  "operation": "transfer",
  "details": [
    [
      "token",
      { "Text": "oz5mx-cykor-uwiaa-aaaaa-b4aaq-maqca-aacq3-a" }
    ],
    [
      "to",
      { "Principal": "icdsn-5xpay-zrct4-of2q2-hyhrs-ftoyx-se5w7-xhzri-psrh4-ksiyr-bqe" }
    ],
    [
      "from",
      { "Principal": "tetgr-gbsy6-6hauq-s64fd-4qbcs-tkzqq-gmn26-3u5am-6bmn5-g2wi4-xqe" }
    ],
    [
      "memo",
      { "Slice": { "0": 0, "1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0, "7": 0, "8": 0, "9": 0,"10": 0,"11": 0,"12": 0,"13": 0,"14": 0,"15": 0,"16": 0,"17": 0,"18": 0,"19": 0,"20": 0,"21": 0,"22": 0,"23": 0,"24": 0,"25": 0,"26": 0,"27": 0,"28": 0,"29": 0,"30": 0,"31": 0 } }
    ],
    [
      "balance",
      { "U64": 1 }
    ]
  ],
  "caller": "tetgr-gbsy6-6hauq-s64fd-4qbcs-tkzqq-gmn26-3u5am-6bmn5-g2wi4-xqe"
}

Looking forward to the next discussion! I hope this provides some useful reference.

3 Likes

As the NFT Working Group is coming close to having a consensus on the minimal standard, I would invite all members of the community to review and post comments here on the forum, as well as under the github issue.

The draft text of the standard is here: ICRC/ICRC-7.md at repo-init · dfinity/ICRC · GitHub

Latest slide on pending issues: NFT WG meeting 20230214 - Google Slides

The next WG meeting is on Feb 28, please participate if you’re interested.

3 Likes

Hi IC NFT People! I’d like to re-iterate some points we brought up during the recent working group meeting. There are a few things we’d like to explore for the ICRC-7 standard:

  1. A GraphQL interface for canister metadata: We propose creating a GraphQL interface for canister metadata to provide a flexible and efficient way for developers to query information about a canister’s state. This is important since NFT metadata can be quite large in size.

  2. JSON HTTP interface for the canister: We suggest implementing a JSON HTTP interface for canisters to enable developers to interact with canisters over the web without needing agentjs. This would allow developers to use a wide range of programming languages and tools to build applications for NFTs on the IC. References here and here.

  3. Transaction history similar to ICRC-3 and compatible with CAP if possible.

  4. Permit transfer similar to ICRC-2.

If you have specific comments or insights regarding those points please don’t hesitate to contribute.

5 Likes

Hi there, I want to know when we can deploy nft canisters based on icrc-7 standard on IC? :grinning:

Soon™ :grinning:
Realistically next steps are: a reference implementation, potentially make some modifications to the draft standard in the process, and vote on the standard.

2 Likes