ICS 17: Nonfungible token transfer packet specification

[cwgoes]

Similar to #9, but for nonfungible (unique) tokens, perhaps with metadata.

[vshvsh]

Relevant links

Ethereum NFT standards

Original NFT https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
Multi-token ethereum/EIPs#1155
Re-Fungible (NFT ownership parts) ethereum/EIPs#1634
Multi-class token https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1203.md
Composable NFT (NFT bundle) ethereum/EIPs#998

Ethereum EIPs are a treasure trove of NFT use cases and corresponding logic. For a mature network we can assume usage won't be any less convoluted. People want to have simple NFT, semi-fungible tokens, batched NFTs, security (as in Howey test security) tokens, fungible ownership rights over a non-fungible token, tokens that are one-way fungible, or fungible but with a twist, all sort of things.

EOS NFT standard

https://dgoods.org/

EOS standart is notable in a way it has a lot of metadata for a token, and different schemas for different categories. A chain that doesn't bother itself with limiting state size too much has a very different approach to on-chain data commitments.

[vshvsh]

NFT/semi-fungible tokens use cases:

1. digital assets (art, game items, rare pepes), token represents ownership
2. deeds to digital or non-digital assets (ENS domain NFT wrapper, tokenized art/land/ownership shares etc.), may have some convoluted transfer/fungibility logic based on regulations and real world objects represented by the deed
3. badges (diplomas on blockchain) - usually non-transferable or only transferable in exceptional case. Tied with identity management
4. identity/PKI tokens (Urbit's azimuth points, Decentralized ID ledgers)
5. permission tokens (transferable multisig? not sure I know of a real example)
6. composite tokens (nft bundles, partial ownership tokens)

I think we should focus on 1. and compatible tokens in this issue, namely, NFT/semi-fungibles that can be transferred in a permissionless way, do not expire, do not have a complex fungibility logic.

That will cover a lot of use cases and will provide a base for more complex NFT standards.

[vshvsh]

What do we want to do with NFTs+ICS? I think there are two big cases we might want to implement right from the start:

1. Simple transfer: NFT from account in chain C1 to account in chain C2
2. Transfer + task. Consider a NFT marketplace chain: a user usually wants to send NFT to a marketplace and put a price to it all in one transaction. We might want a generic packet standard for "transfer and do something chain-specific".

Also, a thing to consider (also concerns fungible token transfers): can we do state channels over IBC? Selling and buying items on marketplace chain within counterfactual state channels, tokens never leaving their origin chain would be so cool.

[zmanian]

The simplest form the NFT's over IBC is such that static NFTs can be moved between chains but mutations to the state of the NFT require returning the NFT to the home chain.

Future improvements to the IBC system could enable distributed mutation of NFTs for instance by allowing a Hub to enforce a while list of what chain-ids are allowed to mutate the internal state of an NFT.

[zavgorodnii]

ERC 721 specifies the tokenURI() method which returns an infoUrl (usually an IPFS link) that leads to the metadata associated with the token, which should be a Token Metadata JSON Schema (same ERC 721). This approach looks reasonable (because keeping the token data on-chain is costly), but people are likely to want more flexibility when it comes to storing their data, and we expect several (field-specific) standards to exist.

It might be useful to provide information that could tell external software whether a particular token's data representation is compatible with a specific standard, and it might be more user-friendly to encode it somewhere inside infoUrl (because this will save the user a great deal of time required to follow the infoUrl and get the actual data). It might look like this (just an example):

/ipfs/QmZU8bKEG8fhcQwKoLHfjtJoKBzvUT5LFR3f8dEz86WdVe/format/erc721

[vshvsh]

Alternatively, exact metadata scheme can be specified in its own field in the packet structure or in the metadata itself (thus not being part of the packet at all)

[okwme]

We started discussing the appropriate changes to the NFT schema over in this issue:
cosmos/cosmos-sdk#4046

And began building a draft implementation here: cosmos/cosmos-sdk#4118

I need to update the issue with some of the choices we made on the draft but one of the thoughts that are already outlined in the issue is with regard to the metadata. Using tokenURI on 721's is a pretty terrible developer experience and has resulted in the biggest users of NFTs like OpenSeas and RareBits to not use the endpoint after an initial pull and cache of the data. Even coinbase wallet uses the openseas API instead of querying the tokenURI themselves. I think one of the big value adds of an application specific blockchain is that storing metadata on chain is feasible if desirable in certain scenarios.

For instance if the info contained in the metadata JSON object meant to be returned by the tokenURI needs to be accessed by another on-chain function. For this reason we thought that a Cosmos NFT should contain the minimum Metadata standard information (https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md) in addition to a tokenURI field for further off-chain data. Our current NFT type struct looks like:

type NFT struct {
	Owner       sdk.AccAddress `json:"owner"`
	Name        string         `json:"name"`
	Description string         `json:"description"`
	Image       string         `json:"image"`
	TokenURI    string         `json:"token_uri"`
}

(The Token ID is used as a key when storing the NFT so is not contained in the NFT struct itself)

[vshvsh]

Should we converge on a single schema for token data or IBC packet can be a subset? How valuable is IBC packet space compared to CosmosSDK chain space? Naive estimation is roughly three times more valuable (packet goes origin->hub->destination making a footprint in three chains) - is it enough to move, say, description to the external metadata?

[zavgorodnii]

@okwme Do I get you right: you say that any metadata call will return an ERC721 JSON metadata object, but this object might contain (under the tokenURI field) either a link to an external resource or actual metadata (that is somehow serialized)?

[okwme]

Hi @oopcode yes the description above is meant as a compromise between on-chain and off-chain data. This is the solution that has been implemented in the v1 NFT module that is an open PR at the moment: cosmos/cosmos-sdk#4209

However I've been considering the idea of a flexible metadata lately and I'd like v2 to separate the metadata into an interface that can have nested features to accommodate as flexible as a metadata schema as possible. It might even make sense to move the metadata into it's own module that can be used to describe any asset on an SDK chain (including fungible tokens).

The metadata should stay on the origin chain as that should be the only trusted source of truth about that asset and it should be up to the origin chain who can update metadata and when.

[cwgoes]

I believe this is obsolesced by more recent work of the NFT standardisation working group.

[Ywmet]

Is nft ibc implement，we have some idea to define it which based on ics20 for evm chain.