NEP: Non-fungible Token Standard

[KanTouLe]

The following standard outlines a non-fungible tokens(henceforth referred to as "NFTs") standard for the NEO blockchain that will provide systems with a generalized interaction mechanism for tokenized Smart Contracts. This mechanic, along with the justification for each feature are defined. A template and examples will be also provided to enable the development community.

[hal0x2328]

There is a group on the NEO Smart Economy Discord in channel #nep-nft that has been working on an NFT standard proposal as well, and there is already a working implementation in Python at https://github.com/Splyse/neo-nft-template

It would be useful if NEL and CoZ could collaborate on a single NFT standard instead of making competing ones.

[KanTouLe]

@hal0x2328
Trinity foundation and NEL will continue our current NFT NEP development and we welcome the community to join us.
Thank you.

[saltyskip]

In the future can we please refrain from marketing proposals like this...as seen here

https://medium.com/@TrinityProtocol/new-nep-standard-trinity-foundation-showing-new-things-in-korea-4d5989e30b21

This proposal right now is at best, a stub, and to be honest I don't believe it should be open given its current state. How can anyone have a meaningful discussion on this proposal when it is basically just a list of methods. It gives no rationale on why each method is necessary or how it will be used practically.

Let's compare what we have here to EIP-721

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

We should hold ourselves to higher standards than this proposal.

[KanTouLe]

@saltyskip
Thank you for your attention.
This proposal's formats reference to the other standard of neo.
If you have questions about the method in the list, welcome to the discussion.

[Arbio5zt]

I also think the proposal with feather details @saltyskip will much better to understand and easy to follow.

[saltyskip]

@RunLyo In the abstract you state that a "justification for each feature are defined" however it is not actually done. If the justification for the majority of features were defined I would have a lot less problems with this proposal.

Additionally, I think any proposal that has a analog in Ethereum should have a section dedicated to what is learned and improved from the respective proposal in Ethereum

[erikzhang]

Now we have 3 different NFT Standard proposals: #30 , #37 , #41 .
We need to choose one to accept.

[erikzhang]

@RunLyo I have some questions for you to answer.

1. As a Non-fungible Token Standard, why we need totalSupply and balanceOf? Since each token is not the same, there should be no need to count the number of tokens in an account?

2. In the case of a transfer, if we know the tokenId, we can get the owner of it. So there's no need to provide the from parameter for transfer?

3. Since the allowance and transferFrom methods are both optional, the approve should be optional too.

4. What is the purpose of takeOwnership?

5. Why is tokenMetadata optional? I think it should be the core method of the NFT standard.

[erikzhang]

In addition, there is a description in the ERC721:

NOTE: Current limitations in Solidity mean that there is no efficient way to return a complete list of an address's NFTs with a single function call. Callers should not assume this method is implemented efficiently (from a gas standpoint) and should strenuously avoid calling this method "on-chain" (i.e. from any non-constant contract function, or from any constant contract function that is likely to be called on-chain).

But in Neo, we have great ways to return the complete list of NFTs. So we really don't need tokenOfOwnerByIndex.