Non Fungible Token (NFT) Standard [Community Consideration]

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.

1 Like

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

2 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.

5 Likes

If everything needs to be on the chain in the future, then the copyright of the image is reasonable as an artwork NFT, but what is the standard of the NFT and what value will the NFT leave to people after the hype?
I think it may be a set of standards, a set of standards that can be used for the Internet of Everything in the future.

But just like the NFT that attracted attention because the giants entered the market, the standard voice of NFT may also be in their hands, but our decentralized blockchain feels like a people’s revolution. Maybe this time it will be different. .

This is awesome!

The part I have time to comment on at the moment is this:

I think the topic of retention has an opportunity to be addressed. Would you recommend this be up to the implementor instead of this “standard” , or maybe it warrants its own standard that can be adopted in addition to an NFT interface?

For example, a controller might delete a canister or decide not to top up their cycles. This is a unique problem space to IC that I’ve been contemplating.

Thanks!

Edit:
I do like the term “standard”. It’s a way to communicate direction and intent. The interfaces, part of the standard, provide ways to adhere to the direction.

The issue I have with “standard” is that implies both interface and behavior as well as complete description. We very rarely have “complete description” in the smart contract world because the devil is in the implementation.

Example: An early draft of an ICP20 token had a seemingly innocent line in it that specified that the balance of the two accounts involved in a transfer should always add up to the original balance. Make sense right? Except that it rules out any number of valid token contracts that have a carrying cost or tax built into them to sustain the underlying system. A catallax token has a carrying cost that is taken out on each transaction and dumped to a UBI pool that flows backward through the ledger. Should the standard be so descriptive that it rules out those kinds of applications?

I think we really just need to focus on the signature of how canisters talk to each other and avoid specifying implementation. Support systems pop up that implement these interfaces and we end up getting interactions with a wide range of tools “for free.” A token can implement a wide range of very specific or very general behaviors. Most of the general behaviors fall into a nice set of logical groupings.

1 Like

The copyright fee of the creator should be taken into account

Thank you @senior.joinu

The Key Difference between these fungible and non-fungible tokens is, Fungible is entirely exchangeable with each other one. And, Non-Fungible Token is completely the opposite of fungible token. its un-exchangeable and Unique.

1 Like

GitHub - Ceto-Labs/non-fungible-token, Explore the implementation of erc1155 on dfinity

2 Likes