Non Fungible Token (NFT) Standard [Community Consideration]

While currency token is a fungible one, ideas from these posts fit both fungible and non-fungible tokens. Moreover, I don’t actually see any significant difference (not anymore) between these two categories, so I will just let it lay here.

6 Likes

Hey folks,

I wanted to let folks know (specially @senior.joinu who definitely put time and effort) that Igor Lilic (@ililic ) will be the person who manages this thread from the Foundation side. This project is clearly very early compared to other much more baked ones (see Increased Canister Storage), but I wanted to let people that I am working to get every thread spinning, engaged, and with the same clarity as the more baked ones.

In the meantime… please feel free to discuss, tell the community what you agree/disagree on from prioritization to implementaton.

5 Likes

Thanks, @senior.joinu , pretty in depth about tokens. Here’s my understanding of your explanation in a couple of paragraphs and then rephrasing of your key question. Please let me know what you think.

A token is described through a set of common behaviors and characteristics for a collection of things; for it to be suitable to be owned and used; according to the it’s perceived value in time and space.

The richness of different tokens comes from the variety of behaviors and characteristics that makes each type of token unique.

why ethereum wants token standards (rephrased your original question):

In certain instances of token types, it is useful to proveably “fix” certain behavior so that it can be never changed( “thou shalt not mint more than 21M tokens of this type; the last one of which will come out in 2140”). This implies that there is some expectation, at the time of token acquisition, of some stability over what does it mean to be that token.

1 Like

I just read a work of art.

Thank you for this story. The point about canister upgradability is salient and compelling.

4 Likes

My thought : 1. The ETH ecosystem has been nurtured by the availability of real-world asset based tokens such as USDT and USDC. At IC, we can have a base stable currency (already being implemented by some as wrapped cycles) that can be based on the XDR. The advantage here is that the price discovery for this is already being done by a powerful DAO - IC! 2. Another key operator in the ETH ecosystem is the Oracle, key player being Chainlink. Should the powerful DAO IC play the Oracle role for a few key real-world stables, and not just for the XDR/cycles computation? - I think this is a question worth debating over. 3. Another question which I think is worth debating over is whether there should be a registry maintained by IC itself, providing the ability to independently verify current supply (and max supply) and other primary info of a token (akin to Etherscan).

1 Like

I’m currently drinking from a crypto firehouse (or maybe a blockchain dump truck) and trying to absorb as much as I can. I entered crypto with a casual investment interest. Since discovering IC, I’m now engaged with a developer interest. After listening to Dominic’s interview recently on the Epicenter poscast I knew this was something different (good listen…their was contention/curiosity w/ the hosts trying to imply as-is blockchain technology to IC).

I’m trying to interpret as much as I can from this thread, and the token standard thread, and ending up with some doubt regarding the current handful of NFTs on IC.

Consumers of these NFTs are assuming the (blockchain) implementation is comparable to Ethereum (others). Though given the below references, it seems we’re a dfx command (malicious update, stop, delete) away (via canister owner) from validating the authenticity of what’s currently in circulation.

I’m wondering if anyone else shares these thoughts, or maybe I haven’t fully appreciated the conversations/develops docs yet.

https://forum.dfinity.org/t/how-does-the-storage-mechanism-in-dfinity-works/2733/6

Immutability (Read-Only Code)

https://sdk.dfinity.org/docs/developers-guide/working-with-canisters.html

1 Like

You can remove all the controllers from a canister, so the API can no longer be changed. Soon we will have a setup so you can have a dao-like group serve as a controller, to allow for decentalized approval of updates.

9 Likes

These are actually great points.

I wish more details were made available about the IC price oracle.

1 Like

In order to protect artists from copyright theft and people minting works they don’t own, is there a way to either guarantee correct copyright within an NFT token on IC? Or can we have something like the tick on twitter, when we know that an NFT is defiantly from a certified artist?

A certified NFT could potentially be more valuable than a non-certified

That’s great to know, and possibly an alternative to the Black Hole previously mentioned. Will stay tuned for the DAO’ish functionality.

I think the main thought I would like to continue, is the community could benefit from having an approach for retrofitting current/new NFT implementations as standards are adopted.

Immutability (Read-Only Code)

On a related note (and more valuable to discuss outside of this thread), I have an unwarranted sense of urgency to know if existing NFT implementations are immutable, recording transactions, and making those transactions (ICP & token exchanges) available through some easily accessible medium other than traversing ic.rocks.

It seems to be a hot topic on the socials, and it would be unfortunate for people to blindly buy into a speculative trend and have an unintentional (canister) update wipe out existing data, leaving people with the inability to prove their stake of ownership in this slice of internet culture…let alone recoup any ICP.

2 Likes

I think nft on dfinity is different from Ethereum, nft on dfnity can be an independent canister that has own specific combination of functions,

it’s the first draft NFT standards written by our team, and we will launch an NFT on dfinity according to this standard soon,
welcome comment and submit PRs

3 Likes

I think the approve function must allow the user to specify a memo (which could be a Nat64) rationale behind that is with Internet Identity, the Principal that owns an NFT in Platform A, will have a different Principal in Platform B; So the Platform B will need to creates an unique UserId which would serve as Memo;

As the owner Principal of NFT id X, I approve Platform B Canister to make any transfer on my behalf with a reference to the account UserId.

The NNS can always change a canister though, correct?

Can an NFT be modified by an action in such a way that the NFT gets rewritten?
For example if owning a particular NFT gave you access to a reward, you’d only want that reward to be claimed once. A new owner of the NFT would need to know the reward is already claimed.

I’ll preface this with stating that I’m still learning about NFTs, but willing to share some thoughts. I’m on the fence on some of them though.

This is a great question, and has led to some great internal deliberation, summarized by this fictitious conversation:

A: On this reward NFT we’re working on, can the reward (w/ a unique ID) represent the same metadata while still being non-fungible?

B : Yes, because each reward has a unique id.

A: But what if the reward’s metadata represent the same number of games points? For example, reward 1 and reward 2 could both be for a reward of 25 points.

B: I see your point. So does that mean they’re fungible, since we could swap them with each other, and still receive the same number of game points?

A: Hmm…

B: Hmm…

A: How about we separate concerns, and have two NFTs; one representing access to a reward and one representing the reward. The 1st one will contain an ID for a reward NFT (and will be immutable) and the 2nd will contain the number of free game points & claim status. That way, if we swap our access NFTs, they’re still unique because they’re pointing to different reward NFT IDs.

B: Sure, I guess, but I think you’re moving the problem further downstream. The NFTs we swapped are unique/immutable, but the point values could still be the same in the reward NFTs!

A: You’re right! Maybe we don’t get caught up in trying to call them NFTs and just make sure we’re fully transparent to our users how the reward process works.

B: Good plan! I’ll make sure our source code is visible and that all transactions are captured/visible and the necessary APIs are available to see who currently owns each reward (and claim status). I know that the IC blockchain is ensuring the calls to our canisters are fully legit, but it’s up to us to make sure we’re fully transparent about what our dapp does. Just because we’re hosting a dapp on IC that allows people to swap unique things, doesn’t automatically make it an NFT.

A: Next time, let’s make the game rewards unique, that way there’s no question about their non-fungibility.

I think it all depends on the expectations of the consumers of your dapp/(N)FT. The expectations can be established by somehow proving that your code (1) will do what it says it will do, (2) permanently captures all events (as a result of function calls), and (3) has a way for anyone to view those events.

  1. This can be accomplished by sharing the source code for your NFT and have some (yet to be developed) verification process to ensure its credible.
  2. The IC blockchain provides the means to do so (as long as the container hosting the NFT’s code is somehow made immutable). However, as stated in other posts, IC does not inherently have a mechanism where all transactions are automatically captured in a way for public consumption.
  3. You would need to develop this functionality or rely on an (yet to be developed) app that can interrogate your NFT for the necessary data.

I’ve seen services on other blockchains permit (only) the URI to change after the token is minted. The URI could point to a JSON file containing metadata on a centralized server. This could lead to the same situation though. Two JSON objects could potentially contain the same data over time.

From my current understanding of NFTs, irregardless of blockchain, is that the consumer (at a minimum) expects the NFT to be unique. Someone a bit more in tune with the technology, will want reassurance the data cannot be funged with after the fact and that there’s a full transaction history from genesis until now.

In your situation, if every reward is unique, then I would say that it is okay for the claim status to change. I would want to be reassured though, that after the reward is claimed, it cannot be claimed again. If the rewards could represent that same value (ex: 10 game points), then I feel they fall more into the category of fungible tokens.

An alternative approach, is to avoid putting a token label on it, and just call it a reward.

thanks for the considered reply! Yes I guess altering an NFT makes it fungible.
Maybe something simple like a rewards data base could work.It tells you if certain awards due to that NFT have been claimed, and if you input your NFT details it tells you what rewards you can or can’t claim with it.

Possibly.

Altering an NFT makes it mutable. Being able to interchange a token with another makes it fungible.

Picture walking into an art gallery where there are 3 original paintings by an artist. Alongside that there are 20 prints of one of the paintings (ie: printed copies of the original).

The art gallery announces that the first 23 customers will get a ticket to receive either an original painting or a print. The tickets are labeled respectively, one with the word “painting 1”, “painting 2”, “painting 3”, and 20 others with the word “print”.

The 20 people with the tickets labeled “print” could swap these with each other all day long, and still only receive a print. I would consider these to be fungible.

The 3 individuals who received the tickets labeled “painting #” would end up with a different painting if they swapped. I would consider these to be non-fungible.

2 Likes

thanks for the clarification on the terms, makes perfect sense

Here are some of my thoughts

I’m going to say some things that I know will run into the brick wall of prevailing thought/memes/culture, but I’m going to say them anyway because I think they are right.

NFTs suck right now. And I say this as someone fairly deep into the NFT realm.

I’ve commented in the past that “tokens” are just data in a database. ERC20 tokens are data in a crypto secure database, but they are still just data. They are a useful abstraction because the world caught on to them made the abstraction useful. A lot of times what someone means when they say they want a token, or that they want to tokenize something, what they really mean is that they want to put data in a crypto-secure database. They don’t know that that is what they want to do…they think they want a token…but ultimately that is what they want to do.

Generally an ERC-20 or Fungible token is a crypto-secure entry in a uniform table with one variable, “the balance”, in the table roughly analogous to the magnitude of shares out of the total supply that that record represents and one variable containing ownership info. When these tables are smart contracts, some of these variables(but generally not the balance) can be functions that depend on inputs and other state in the table.

NFTs are currently undergoing the same abstraction mess. Since the world has grabbed ahold of the abstraction, everyone wants everything to be an NFT. But everything isn’t an NFT…or maybe everything is an NFT and thus the label becomes worthless.

If we look at the original ERC 721 spec we see a pretty definite definition of what an NFT is:
https://eips.ethereum.org/EIPS/eip-721

“NFT” Word Choice

“NFT” was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that “deed” is very descriptive for certain applications of this standard (notably, physical property).

Alternatives considered: distinguishable asset, title, token, asset, equity, ticket

The keyword here is “distinguishable”. This implies a degree of, or perhaps an absolute amount of uniqueness. In our uniform tables, each entry had a unique ownership field. In theory, each entry in an ERC20 table is an “NFT”. You will have a rough time transferring your account because usually the ownership is tied to a private key that you wouldn’t want to share with anyone and that they wouldn’t trust you transferring to them. So instead you swap the balance. NFT really did 2 things.

The first was to say that a thing is going to own itself. Its physical(or rather digital) properties will determine what is in the ownership column. If two things have the same properties then they are the same thing…they are indistinguishable.

The second was to add an ownership squared, ownership of ownership, or meta ownership filed to the scheme.

You could also just say that they added a uniqueness column to the table, but I think the transformation and idea of a thing owning itself…having its own sovereignty…is really instructive. It is how crypto addresses work as well. Crypto addresses are able to have sovereignty over themselves and the things the world ascribes to them because of cool math. NFTs have sovereignty over themselves and have the properties that the world ascribes to them because their properties are observable and identifiable.

Classically(as in the last what…5 years), the properties NFTs have dealt with have been media files. These have their own set of challenges when it comes to distinguishability, but let’s wait to talk about those. Let’s consider a perfect world where everyone acts in good faith and each possible image is attributable to a creator. This is great and NFTs now give us an amazing mechanism for our creators to own, sell, and trade their work. Based on the digital properties of your media file(the order of the ones and zeros plus the decoder you use to translate those into physical properties - how it appears on screen, how it sounds) you can distinguish each image from another.

Now NFTs have always had a bit of a problem when it comes to the manifestation of these digital properties into physical properties. Change the pixel color of one pixel by one integer and the thing is now vastly different by digital measurement tools but indistinguishable by the human eye. “There is nothing either good or bad, but thinking makes it so.” sha256 is ba118b93ee1ad0694e79571d4c902d0bf0ea993db6838f20263d35591fd4afe4 and “There is nothing either good or bad, but thinking makes it so” is 90c9df0d556ab1dc558c98fe3566ba473c5c8418e748b28fd70ab594d4137e43. But are they really unique? Should Not-Shakespeare J. Simpson be able to remove a period and claim new ownership? Or did a pen drip?

What if I take Punk 4743 and convert it from 24x24 to 48x48. Again, a simple sha256 gives me much different identities even though they should be indistinguishable. Now if I compress the 24x24 and 48x48 I should get these same digital signatures provided I know what form of media I am using and that my upsampler didn’t so something magical in the process. So maybe that is interesting. Does distinguishability have components?

Problem 1: Compressibility.

This is all a much bigger problem with Ethereum than it should be with the IC if we approach it the right way. On the IC we should be able to have the digital bits live alongside our ownership records. But there is still nothing keeping two canisters claiming the same image is unique. To do that you need governance of some kind that ascribes and proves ownership, perhaps in an ongoing way. Probably within a reasonable time frame for decision-making.

Problem 2: Uniqueness

I’ve also heard of people talking about NFTs that change. I think this just nullifies the ability for us to even have a discussion about this. Unless the changes are deterministic based on a seed and unless the current state is within a computable space for all reasonable times t, I don’t think we can consider something to be distinguishable. We can loop back to crypto addresses here and even use the crypto that the IC uses as an example. Key shares are roughly infinite on the IC and they move forward in time so that old keys can be invalidated. So they change and change almost infinitely, but in a way that is deterministic such that you can trace them back to the root key. If you are making a morphing NFT that can’t be traced back to its seed in a programmatic manner(probably within the calculation scope of what the IC can do) then you probably aren’t making a distinguishable item(an NFT).

Problem: 3 Determanism

All of this is not to say that you can’t have other fields in your distinguishable and crypto secure row that do all kinds of non-deterministic, cool, repeatable, behavior. Again we call these smart contracts for a reason and we want to do all kinds of as-of-yet unforeseen things with them. But, if we’re going to come up with a standard around NFTs we can’t throw in the whole kitchen sink of “what I want an NFT to be today”.

This is not an exhaustive list, but I’d propose we have to answer these questions as we discuss the standard:

  1. How do I prove my uniqueness to the world?
    a. How do I compress my digital properties in a consistent manner?
    b. Who is enforcing this methodology?
  2. What parts of me are deterministic enough to be considered part of the NFT?

A couple of initial thoughts:

1a and 1b. An NFT should describe their compressibility and enforcement methodology themselves so that they can declare their own provability. For images and sound, this should be easy. We publish a blackholed canister that takes in a file, does a standard bit of compression and performs a statistical analysis of the remaining bits in context and produces some kind of signature that will be unique for all appropriately distinguishable media files. I have a suspicion this is some of what Orygin is working on. This interface could be generalized to a registry as well so that we end up with a kind of copyright dao registry where media goes in and it get registered and awarded if it passes the uniqueness checks. This might get complicated when it comes to composability. We should talk more about that. If I combine two images by puting one next to the other, Have I created enough of a thing for it to get awarded uniqueness? Or should it be derivative of the components? Can we detect that?

  1. We just need to get honest with ourselves on this one and stop calling everything an NFT. Smart contracts are smart contracts. Some are NFTs, but not all of them. If you are going to funge your NFT in the future in an indeterministic way then you probably aren’t making an NFT. Could it be a valuable, cool, smart object that people want to pay a bunch of money for? Sure! We just have to draw the boundaries somewhere for our standard that won’t fit inside the tent. Does this move a lot of game-oriented objects outside the boundaries? Yes, it does. But there is probably an equally memetic name for those that we can come up with that will catch fire as well.

Other random thought after reviewing the departure labs most recent NFT spec: I think it might be helpful to move all the http stuff out of the “standard”. I think the http wrapper should be its own thing. It makes sense to publish them together, but ideally, the standard should be modularized into the pieces that are necessary to reason about the NFT and those that are not.

Generally, I think we shold all start to think in terms of “interfaces” instead of “standards”. An NFT “standard” could be made up of the following “interfaces” : com_token_ownable, com_token_transferable, com_token_approvable, com_nft_royalty, com_nft_unique_provability, com_notify_subscribable, etc

…not a complete set of thoughts…but what I had on my mind this past weekend.

13 Likes