Roadmap for Tokens in the Cosmos SDK

[ig-shaun]

The Interchain NFT and Metadata working group has over the past 6 months been working on a set of specifications which build on the latest web standards for DIDs, Verifiable Credentials, and the nascent spec for Authorisation Capabilities.

Which we strongly believe should be systematically applied as the standard for identifying on-chain assets, associating metadata with these assets, and to provide delegatable decentralized authorizations for invoking services related to the assets.

At the start of this work, we anticipated the spec could initially be implemented as an updated version of the BaseNFT module. To provide a pathway towards a universal Tokens module and to demonstrate how developers of any module which handles on-chain assets can implement the specification.

The specification provides what we believe to be a straightforward way for any module, on any Cosmos application chain, to uniquely and unambiguously identify and interface with assets.

The result is a sub-set of DID methods which we have named Interchain Identifiers (IIDs).

IIDs extend DIDs with additional features that are uniquely required for NFTs and other on-chain assets.

Responding to requirements we have identified for an initial set of NFT use-cases and user stories.

IIDs are DIDs. So they are self-describing URIs which are fully compliant with RFC3986 (which the proposed CAIP-19 approach to identifying on-chain assets does not fully conform to).

Implementing the IID specification for NFT asset types would immediately support tokens having truly chain-independent provenance. We have since seen proposals from other groups which build on this idea –including a DID:NFT method from Ceramic Protocol, for representing ERC721 tokens as DIDs.

For starters, any IID compatible DID Method -on any chain or registry- would enable authentication of the asset owner, using information which is already stored on-chain.
This opens up a large innovation space. For instance, NFT owners could conceivably authenticate to log-in, invoke services and access data, using a CryptoKitty or a piece of Digital Art!

Applying the chain-independence of DIDs to NFTs gives us a new, universal approach for interoperable token services such as mint, transfer, burn, or any other custom behaviors that can be implemented by services on the same chain or across chains.
This approach is particularly relevant to Cosmos, given the inherent lack of post-deployment composability of Cosmos Go modules, compared to smart contract systems.

We agree that there needs to be a pragmatic and incremental approach to implementing the vision of the full IID specification into the Cosmos SDK roadmap.

Proposals

We will be posting additional Github discussions, leading from the conclusions of the current phase of the working group process, to flesh out the following proposals.

The first will propose the IID specification should be formally adopted through a Cosmos SDK ADR. Which would lead to the implementation of a Cosmos DID Method for any Cosmos application chain to immediately begin using IIDs for authentication, authorization and value transfers on their own chain and across chains through IBC. This will also enable assets, such as NFTs on Cosmos, to interface with any DID-enabled wallet. In ways that are interoperable with other IID or broader DID-compatible systems.

The second proposal (Tokens 2.0) will provide a roadmap for developing a universal Cosmos SDK Tokens module, which will offer several advanced features. Responding to the use case requirements which have been identified through the Interchain NFT and Metadata working group. Also implementing the more pluralistic Token Taxonomy Framework which recognizes that there are many possible classes of different base types of tokens required for a plethora of real-world use cases.

The features of Tokens 2.0 could include:

• LinkedResources in a format which is privacy-respecting
• Token templates which enable versatile token composability
• Token classes which separate the control over collections of tokens from token ownership
• Behaviors and Properties that can be defined and controlled at both the class and instance level
• Arbitrary derivatives and re-integrations for supporting different patterns of token relationships
• Functional composition by adding and removing services programmatically, both on the token and class level.
• Authorization Capabilities for off-chain, decentralized delegation and verification. Which provides a versatile mechanism for building complex business logic into tokenized systems
• Off-chain identifier creation for cost-free establishment of new identifiers
• A polymorphic mediator for enhancing herd privacy though service abstraction

An iterative approach, starting with NFTs

The details of this Tokens 2.0 module proposal will evolve as we gain input from the community.

Given the scope of ambition and iterative approach, we need a concrete strategy to get out a good solution for NFTs first. Preferably one that can evolve to take us from present needs to the future potential.

Step 1 Start with BaseNFT

We propose to start by building on the Comos SDK BaseNFT module. The IrisNet iteration of BaseNFT, which is already Stargate compatible, is a good candidate for this. The IrisNet team is keen to progress their implementation and support the roadmap towards Tokens 2.0

Step 2 Add IID support

1. Map internal asset identifiers to a unique namespace defined by did:cosmos:<chain>:<module>:assetId
2. Implement support for a DID Resolver method that takes a DID targeting the module, e.g. in the format did:cosmos:<chain>:<module>, and retuns a valid IID Document (marshalled into JSON), which contains verification relationships and methods that use the token owner's cryptographic material with standard Cosmos cryptography.

This will result in an IID-enabled NFT module which can issue NFTs and offers the capability to use these NFTs for authentication to both on-chain and off-chain services. (See the IBC-enabled DIDs discussion).

We believe this is a relatively short lift that could demonstrate how literally any Cosmos module that manages on-chain assets can be upgraded to support IIDs, with standard handlers, etc.

We are confident this minimal functionality can be implemented and tested to be deployed for the hub by Q3.

Step 3 Add Token Composability

1. Add services to derive and integrate tokens and set up arbitrary relationships between NFTs and other tokens. Which starts with a method for locking an NFT and minting fungible share tokens, using the Supply function of the Bank module.
2. Add methods for adding and removing NFT services for arbitrary composability, through configuration of the IID Document properties –rather than developers having to build custom handlers for each new configuration.

The IID specification enables any on-chain or off-chain service to be specified for an NFT, without needing to implement all of these features within the token module itself.

Step 4 Additional Core Services

• Swap: atomic swap of one token for one or more other tokens of any collection (NFT in, NFT/s out)
• Convert: atomic lock & mint from another token collection under the authority of the owner of that collection or denom. (NFT in, coins out)
• Redeem: atomic lock & mint a fungible token from an existing class under the authority of the owner of that denom (NFT in, coins out)

At this point, we will have extended the range of derivatives to allow for truly arbitrary relationships between both NFTs and Fungible tokens.

Step 5 and beyond: Implement the Tokens 2.0 Proposal

Steps 1-4 get us to a minimum-viable NFT module that quickly iterates to a fundamentally improved approach that is much more suited to today's NFT marketplace, meets the demands of real-world use cases, and is future-proofed.

The Tokens 2.0 proposal will provide a path torwards an even more powerful and developer-friendly solution to build NFT and token applications of all kinds.

For instance, Tokens 2.0 would in principle be able to support a native Cosmos CryptoKitty implementation, with custom services for breeding and auction. The token creator would be able to use the Tokens module for all standard NFT functions (mint, transfer, burn, etc.), with fully customizable properties and behaviors.

The path forward for Tokens 2.0 is currently being designed and will be presented as a separate discussion.

We welcome feedback on this proposed approach.

[charleenfei]

Hi Shaun, thanks for this. Just for semantic/thematic clarity, it would be nice to box the token aspect of this discussion out. I think what you have termed Step 1 is covered in this discussion #9065, and it might be confusing/redundant to reiterate any NFT roadmap here. If it makes sense for you, it would be interesting to hear a fleshing out of how an IID "module"/ how IID might work for assets minted from a cosmos sdk module. So, this is the topic you surfaced in Step 2 of this post.

[fedekunze]

So there's the larger question of what is a core piece of infra and what's application-specific. I feel like most of the items outlined here (with exception of maybe 1. and 3.) are application-specific.

Keep in mind that it's the core SDK engineers that will have to maintain these modules from now on for everything related to updates, major SDK changes but also security vulnerabilities. If @cosmos/regen_cosmos-sdk_write is willing to do it then it's ok to include them I guess.

[jandrieu]

@fedekunze I would say that from an architectural design perspective, the goal is that the tokens functionality be usable by any range of applications with minimal forking or customization. Current proposals, for example, can't provide CryptoKitties functionality without extensive modification.

Instead, we'd like to define a tokens module that handles 90-95% of token functionality, so that, for example, with a CryptoKitties clone, all that needs to be custom coded are the bespoke features for that token, such as "breed". Minting, transferring, burning, and property and behavioral CRUD operations are all standard.

We don't see the the different steps in the roadmap as being application-specific as much as enabling a configurable approach for arbitrary functionality to meet the needs of applications we have discovered in our requirements gathering process. That is, we are proposing an application-agnostic framework that can work with the widest range of use cases.

For example, while not all tokens are going to have specific demands about mutability and immutability at both a class and instance level, we know of different use cases that do have varying requirements for this. Rather than presuming at the token module level who should get to mutate what--e.g., is a particular property controlled by the token creator or by the token owner, or is it fixed for all tokens in that class--we are advocating that the token module allow this to be flexibly configured based on the token creator's needs.

We see the same tradeoff in the derive and integrate methods for arbitrary relationships between any two tokens. For example, consider an NFT that represents a property right to 100 acres of land. You might derive a new token (assume 100 derived tokens) that wholly subsumes the property right of the originating token and creates a new set of tokens with whatever rights you need. The new tokens could represent a fungible right to 1% of an indivisible interest in any control or proceeds from the parent. It's fungible with the other 99 peer tokens, but is itself uniquely tied to the origin token. Or you could have 100 new tokens that each represent a non-fungible right to control of, and proceeds from, just 1 specific acre out of that originating set. Even more flexible, there's no reason one can't derive into multiple different token types, such as voting/control rights verses a right to proceeds.

The proposed approach avoids hard-coding these kind of relationships, allowing token creators to configure the module to meet their needs.

[fedekunze]

See #9065 (comment)

[charleenfei]

https://github.com/medibloc/panacea-core/blob/master/x/did/types/did.go

this is an really interesting project which has already launched on mainnet in 2019 with a DID module which seems to follow the w3c spec pretty closely --

[hulatown]

For Step 4:

1. Is there any overlaps between "Convert" and "Redeem"?
2. There should be a new Service for "NFT/coins in, coins/NFT out"? For example in NFT marketplace, people will use coins to buy NFT; owner will sell NFT for coins. This was also quite needed for Uptick application when we tried to build it with BaseNFT function. Maybe we can name this kind of service as a "Trade" or so.