NFT Working Group - Next Steps - ICRC-8, ICRC-56, ICRC-59, ICRC-60

Tokenization
1

As we reach the end of a very long path to ICRC-7, it is time to start looking at the next set of work for the NFT Working group.

The WG originally decided to take on a ‘Simple’ NFT that provided the minimum amount of functionality that the community would expect for an NFT on the Internet Computer. Thus ICRC-7 was born(and will hopefully be approved in the next few weeks) and we split it into an ICRC-37 to handle some extra functionality that was not necessarily required, but expected(approve and transferFrom). We reserved and designated ICRC-8 for a full-fledged IC-enabled super NFT.

Over the course of working on ICRC-1,2,3,4, 7, and 37 we’ve learned a lot of things like ‘smaller is better’ and that getting broad agreement in two-week increments is difficult. Nevertheless, it is time to look forward! As part of the exercise, I’ve broken down what was originally ICRC-8 into 4 different ICRCs.

ICRC-8 - Ledger Markets - At Origyn, we put the marketplace inside the NFT to help enable us to provide creators and the community with more dependable guarantees about the behavior of an NFT. Since this makes sense for NFTs, why not for Fungible Ledgers as well? This ICRC defines a marketplace standard for the IC that can either be run on a Fungible or NFT Ledger directly(where fees can be less and atomicity faster) or on any marketplace canister. It defines the data structures and workflows necessary to achieve atomic trades with any number of ICRC 1,2,4,7,37 type tokens and any number of participants. It isn’t ‘simple’ and may be able to be broken into a number of ICRCs itself, but we need to start somewhere. ICRC/ICRCs/ICRC-8 at icrc8 · skilesare/ICRC · GitHub

ICRC-56 - Infinitely Scalable Multi-Canister File System - On the IC we have the ability to put our NFT files on-chain in a way that is computable. Why is this important? Imagine an NFT that secretly holds a very high-resolution image and will only let Canister-based Generative AIs that can’t steal the bits run transforms over it. There are many other reasons to have files in a place that smart contracts can compute over them. In addition, having your metadata, files, and logic all on one system is a nice assurance for users. As I was thinking about how to structure this for NFTs(we took a swing at it with the origyn_nft) it occurred to me that lots of applications on the IC need a standard file system. While this ICRC can be used for storing on-chain NFT media, it is a generic ICRC that follows the Asset Canister pattern, adds some sugar, and attempts to create a drop-in module for canisters that want to contain smart contract logic AND host files. ICRC/ICRCs/ICRC-56/readme.md at icrc56 · skilesare/ICRC · GitHub

ICRC-59 - Static NFT Metadata Interface Standard - Two camps arose as we discussed NFT metadata in the community. There are those that want their NFT to be hardcoded, hashed, and never change. And there are those that want an NFT that can store permissioned and constantly updating metadata. We split the baby with ICRC-59 and ICRC-60. ICRC-59 defines a static approach. It provides the minting and burning interface as well as methods to stage NFT metadata. If you are building a simple PFP NFT, you likely won’t have to go much farther than ICRC-59. ICRC/ICRCs/ICRC-59 at icrc59and60 · skilesare/ICRC · GitHub

ICRC-60 - Dynamic NFT Metadata Interface Standard - ICRC-60 builds on top of ICRC-59 but defines how and by what methods data can change. It also upgrades from the limited ‘Value’ type used in 7 and 59 form metadata and upgrades metadata to use ICRC-16 which allows for the Class data type. This data type allows a creator to mark some of their data as immutable and some of it as mutable. Further, the standard defines how creators can incorporate a rich community of data apps into their NFT and permission them such that you can trust that only those data providers updated the metadata(important for games and service-based NFTs). ICRC/ICRCs/ICRC-60 at icrc59and60 · skilesare/ICRC · GitHub

Please come join us during the NFT working groups and give your input as we begin to look at these and other important standards. Calendar: Internet Computer Events

Your feedback is invaluable and I’m really happy to have these out of my head an on ‘paper’ so we can begin discussing them.

So where do we start?

  • ICRC-8 - Ledger Markets
  • ICRC-56 - Multi-canister File System
  • ICRC-59 - Static Metadata
  • ICRC-60 - Dynamic Metadata
0 voters
10 Likes
2

I’d love to at least sit in, not sure how much i can contribute. Not been a part of a working group

1 Like
3

That is the best way to get started! Likely you’ve got more relevant experience than you think.

2 Likes
4

First of all, I want to congratulate you for the energy in always wanting to improve and advance; it’s a great help for the ecosystem, both for ICP and for other projects like Origyn. On the other hand, all the standards are really good. It’s difficult to decide which one is better since each one has a unique functionality.

But since this is about voting and giving an opinion, I think we should consider which one can be more useful or serve as the basis for new projects. In other words, a functionality may be very good, but I would first focus on which one can be useful for launching new projects.

I vote for the CICR-60 standard because I believe many projects can benefit from it. As you mentioned, games, service-based NFTs, and even basic things like the digitization of documentation, for example: driver’s licenses, car registrations, medical histories, etc. This reinforces the idea of starting with simple things that really have immediate utility in people’s daily lives.

Perhaps it may seem like a very idealistic idea, but we are closer than we think… Very excited about the times ahead!

Best of luck with the development, whichever comes first!

1 Like
5

I like 60 too, but it requires 56 and 59 as prereqs, so it may not be a true decision…but votes for 60 imply the others and elevate the importance! Thanks for the feed back.

1 Like
6

My project now requires 60. Btw, would they all be building on ICRC-7?

7

Yes. They all use 7 as a base.

8

I think, the strategic choice is ICRC-60 - Dynamic Metadata. This selection aligns closely with our goals for several reasons:

  1. Adaptability in Metadata: ICRC-60’s dynamic metadata capabilities are essential for bIPQuantum, as they allow us to update IP asset information over time. This adaptability is crucial for handling evolving IP rights and licensing terms, which can change based on the asset’s usage or creator agreements.
  2. Enhanced Use Cases: The flexibility offered by dynamic metadata supports complex use cases necessary for comprehensive IP management, such as varying licensing models for GameFi, MetaUse, or SaaS applications.
  3. Integration Potential: ICRC-60 aligns well with our development of the bIP721X protocol within bIPQuantum, which focuses on broader IP management beyond typical NFT functionalities. This integration enhances our platform’s capabilities in managing and transacting IP dynamically and securely.

Adopting ICRC-60 will not only leverage the complete ecosystem but also our technical needs but also enhance our own development bIPQuantum’s contribution to the Internet Computer ecosystem, establishing a new standard for how intellectual property is managed digitally. This approach underscores our commitment to innovation and collaboration in the evolving digital asset landscape.

1 Like
9

Was there a .did file for 60? Going through the md but still a bit confused.

10

Will CEX accept the token standard you developed? If cex doesn’t accept it, what do you do to develop it? So far, I have not seen any icrc1 tokens on any well-known cex.

11

As far as NFTs go, we have some work to do with CEXs. The good news is we are working on it! We are fairly close to some funding that will specifically provide for CEX outreach and allow us to easily stream/cast NFTs over to compatible formats while holding a carrot for the implementation of gasless marketplaces. It is a little bit of a chicken and egg problem but we are tackling it head on.

As far as ICRC-8 and Fungible/NFTs goes, a CEX has nothing to say about it because it puts the marketplace in the ledger itself. You don’t need a CEX. You just need a dapp…that perhaps…the ledger can host itself. No CEX. No DEX. LNM. Ledger Native Market.

2 Likes
12

No official .did file…we haven’t even had any formal meetings about 60 yet. You will find most of the functionality for 60 in some form in the origyn_nft and we’ll be migrating that to the eventual final form of this standard, so you could start there knowing that it will get to 60 eventually. If you’re interested in pushing this forward I’m happy to start organizing the Working Groups to do so. Theoretically, we have an NFT working group, but in reality, I think the participants are pretty burnt out after getting 7 and 37 across the line. We need new eyes and eager participants.

Jump in!

2 Likes
13

Cool, i’ll look around. Upgrading to 7, and definitely interested in pushing 60 forward. :slight_smile:

1 Like