KIP-0008: Non-fungible token standard

[fmelp]

No description provided.

[fmelp]

@sirlensalot there is one thing that conceptually I don't understand. Is there no way of identifying the NFT somehow? Like the hash of the file or something like that? Or it's enough to just say 'it's a thing and it belongs to this account'?

[fmelp]

also wonder if we can include the ERC-1155 in here too. It's basically being able to issue multiple of the same NFT. Use cases: music, limited editions, etc..

[sirlensalot]

@sirlensalot there is one thing that conceptually I don't understand. Is there no way of identifying the NFT somehow? Like the hash of the file or something like that? Or it's enough to just say 'it's a thing and it belongs to this account'?

Pretty sure that's up to the implementation, and we're better off there because you can use any string value as the id of the item, as opposed to ERC-721 where it's just a number/hash. But even there, I suspect an items table would map the id to JSON, a hash, what have you, specific to the contract.

[sirlensalot]

also wonder if we can include the ERC-1155 in here too. It's basically being able to issue multiple of the same NFT. Use cases: music, limited editions, etc..

That's interesting, because as you know kswap.tokens is a multi-token contract and basically has the same signature.

It's a little gross that they just plopped ERC-20 on top of ERC-721. I get it, transfer has a very similar shape. But for an ERC-20, that "id" I guess becomes the symbol, and conflating a fungible symbol with an NFT id seems very wrong to me.

It's good to think about though. We had been thinking for multi-token that the upcoming Pact implicit argument feature would handle that. With kswap.tokens, it would be something like (implicit kswap.tokens "coin:abc") which is a module reference to kswap.tokens parameterized with the name of the specific liquidity token.

Is ERC-1155 in wide use?

[corxi]

Hello everyone, I have just found this thread, hope it's not too late to chip in. 1155 is a fantastic solution employed by Enjin to tokenise in-game items. It's working very well. Now the goal for NFTs, with a market screaming for it, is community ownership of either a digital or physical item. I want to be able to tokenise a physical item and to do that I must divide the NFT into however many parts I need. In my mind, ideally the output of the division may bear the original NFT ID number and a unique incremental reference number to preserve the uniqueness. All from 1 single smart contract. Am I mad?

[emilypi]

Thanks for the comments @corxi - I don't think you're mad! @fmelp could you comment on this?

[sirlensalot]

@corxi check out KIP-0011, the Poly Fungible standard. It's basically ERC-1155 with decimals, but that's a big improvement because it allows fractional ownership: for example, a poly fungible with total supply 5.0 and precision 3 would allow 5 items to have fractional ownership of 0.001 or greater. But that is only one way to slice it. Would love to hear your thoughts! We merged KIP-0011 already (colorblock project is using it) but we can always refine it more. https://raw.githubusercontent.com/kadena-io/KIPs/master/kip-0011/kip-0011.md

[sirlensalot]

Closing this KIP for now as it is superseded by Poly Fungible (KIP 0011).

[corxi]

Thanks for the reply @sirlensalot KIP-0011 is certainly a big step forward particularly for NFTs. Colorblock is a great implementation of it. The poly-fungible properties ensure flexibility. However, in the project we have recently submitted to Kadena, we envisage NFTs in a parent/children hierarchy as opposed to precision. Example: let's NFT a statue (physical item). The NFT will contain all relevant details (history, location, etc). It is decided that this statue will be sold in fractions so 10000 more children NFTs, with the value of $1,00 each, bearing the parent NFT ID reference, will also be created, for a total of 10001 NFTs. This is useful because, should the statue be moved from a Scottish castle to a US museum, only the parent NFT will be edited (to bear the new location) and will change hands. The remainder children NFTs will remain with the respective owner. This is applicable to many business processes. What do you think?