NFT Module

[okwme]

Summary

Either an extension to the bank module to support non-fungible tokens or a new module specifically for non-fungible tokens.

Problem Definition

There is currently no simple solution for supporting non-fungible tokens which make up a large and growing category of decentralized applications.

Proposal

Request for comment about the best way to implement this feature and what exactly this feature should entail. Questions include:

• Should this process actually take place in the ICS repo?
• Should this be part of bank module or it's own module?
• Should metadata be included as part of this module?
• Should this spec follow or extend the ERC-721 standard? the emerging ERC-1155 standard? the EOS dgoods standard?

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

Thanks for creating this issue @okwme and brining light to NFTs in the SDK. This is something I would love to see come from a community contribution but is also something I think we can plan into a future milestone.

Some thoughts, I really do enjoy the ERC-721 open standard. I think it's very well documented and has numerous implementations already (e.g. 0x, CryptoKitties, Trust Wallet, etc...). I haven't actually read ERC-1155 in it's entirety yet, but it seems that there is continuing discourse on its adoption (correct me if I'm wrong). Essentially, I think we can adopt and incorporate a lot of useful concepts from ERC-721.

My initial thoughts are that NFTs should not be incorporated into the existing bank module, but instead should be their own module(s). NFTs can be separate by domains in which case each domain would be it's own NFT module (e.g. x/kitties_nft) or we could have one domain-agnostic NFT module too. Either way, I absolutely think the SDK should contain a reference implementation + spec.

What are your thoughts @okwme?

[jackzampolin]

I really really like the idea of using existing standards here. Lets not reinvent the wheel if we don't have to.

[okwme]

I agree on both accounts that it should follow the work done on 721 that's already been tested as useful. Most of 1155 is about increasing the gas efficiency of 721 and opinions about combining registries of erc-20 and erc-721. These features don't really apply to an SDK NFT.

I think the biggest change between an Ethereum based NFT and an SDK NFT is the ability to store much more Metadata on chain. Because storage on ETH is shared across all participants it's expensive and so the solution was to put metadata off chain and just include a tokenURI endpoint that returns an RFC 3986 URI—typically http(s) or ipfs. That URI returns a JSON object with information about that NFT. This makes it difficult for that information to be accessed and used for on-chain transactions. This could be a problem if for example the NFT were an asset like a Centrifuge-style invoice where the contents of the invoice are only represented by a hash but another on chain transaction needs access to actual data in that invoice—maybe hourly rate. You'd need an oracle to confirm that content if it lived off-chain but with an SDK chain it can be readily accessible.

I think this feature should be supported by modifying the 721 spec where the tokenURI doesn't return the URI but the actual metadata resource itself. This resource may elect to contain a tokenURI that points to off-chain data, in case storage of such data does in fact make more sense off-chain. However it also enables onchain data to be accessible in a predictable format in case it is deemed useful on chain.

The following methods from the 721 standard would need to become Msg Types:

• transferFrom(address _from, address _to, uint256 _tokenId, bytes data)
  • This is a transfer function that includes the ability to transfer an asset on behalf of another user. We'd need to keep track of allowances so that a user would be able to give permission to another party to move assets on their behalf. This might be necessary for pegs as well–maybe the permission includes chain-ids as well?
• approve(address _approved, uint256 _tokenId)
  • This would be a necessary component of transferFrom to approve transfers on behalf of other parties.
• setApprovalForAll(address _operator, bool _approved)
  • Variation of approve to allow multiple approvals at once
• safeTransferFrom(address _from, address _to, uint256 _tokenId)
  • This version of TransferFrom checks with the party receiving the NFT to confirm they are prepared to accept the asset or whether they have an action that should be performed upon receiving it. Maybe out of scope for first Cosmo NFT spec but also good to consider this. Maybe we'd have a registry of recipients who can decide whether they accept an NFT sent to them or reject it?
• safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data)
  • This is a variation of safeTransferFrom without a data parameter. This data parameter is used to daisy-chain arbitrary on chain transactions. Something similar might be another Msg type that might want to be executed directly following the first transaction. QUESTION: Is it possible to create arbitrary transaction that bundle multiple MsgTypes? Maybe for 1st draft this implementation should not be reproduced on Cosmos.* safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data)

The following queriers would need to be created from the 721 spec:

• balanceOf(address _owner)
  • Number of NFTs the address owns
• ownerOf(uint256 _tokenId)
  • Owner address of a specific NFT
• getApproved(uint256 _tokenId)
  • If transferFrom includes the ability to move on behalf of others it would be necessary to check the approvals
• isApprovedForAll(address _owner, address _operator)
  • An extension to the ability to check for approvals

The Metadata spec is actually separated from the required fields of the NFT. This might also be good to make optional with a reference to whether or not they exist. Something like EIP 165 would be needed for that and should also be considered. In the mean time we could expect the following queriers for metadata:

• name()
  • Return a string for the NFT family name
• symbol()
  • Return a string for the NFT family symbol
• tokenURI
  • This should be replaced with an actual metadata data object. Even if all data is stored off chain the tokenURI for that data could be contained within the returned data object.
• metadata
  • This would return an object with a minimum of the ERC-721 metadata scheme, plus optional additional info under tokenURI. The return format may be a parameter so that if the recipient is prepared to parse JSON they can do so, but may also be able to request it with a different serialization.

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
        },
        "tokenURI": {
            "type": "string",
            "description": "A URI pointing to a resource with more token related metadata that doesn't belong on chain."
        }
    }
}

It might also be useful to have more Cosmos specific information per NFT. Maybe a parameter for origin chain? If the specific token is being held across chains, maybe it would be good to distinguish which NFTs are being held by users and which are being held by validator sets. If the asset is being held by a validator set it would be good to be able to tell whether a user holds the wrapped version of the NFT on the other side of the validator set.

Curious as to other attributes that may be useful for NFTs in the context of Cosmos, anyone else have some ideas?

[okwme]

Some thoughts as we build the draft implementation here: #4118

• Should the NFT module support multiple denominations of NFTs like the Cosmos Bank?
  • If so, the denom needs to be included in all queries
  • It could also be that the denom is only required if there is more than one denom registered there
• Should the Module include Mint and Burn abilities or should they be separate Modules?
  • What is the standard way of including / extending modules?
  • This is actually relevant to whether there should be a single nft module as well as a nfts module for when multiple denoms are needed
• Should the standard come with optional marketplace functionality like buying NFTs?
  • We thought this was useful but should be separated from the NFT module

[okwme]

Some really great discussion related to this topic over at #4153

[shrugs]

Unless there's an existing pattern around having name and symbol as top-level queries (forgive me, I know nothing about cosmos), it could make sense to put those as part of the metadata query and associated spec. ERC-20's existence mandated that ERC-721 did the same with name/symbol.