CIP - On Chain Token Metadata Standard

Developers CIPs
1

Hello everyone,

In this proposal, I’d like to propose a standard for onchain token metadata.

Motivation

The current Cardano token registry is held in a github repository, GitHub - cardano-foundation/cardano-token-registry. The challenge with managing token metadata off chain is it requires both centralization and a level of trust in both the managing party and the process by which new tokens are added to the registry. This approach creates potential opportunities for abuse.

Proposal

Instead of storing the metadata off chain, I propose that the metadata is stored on chain in a manner similar to the very successful NFT standard. I would propose a new metadata label:

  • transaction_metadatum_label - 20 (as a hat tip to the ERC20 standard)
  • description - Token Metadata

To provide flexibility developers with respect to their minting scripts, the metadata can be associated with any transaction that mints the given policy id and does not require that the specific asset id be minted in the transaction.

The first valid occurrence of a policy id and asset name pair will be considered authoritative and immutable.

{
  "20": {
    "<policy-id>": {
      "<asset-name>": {
        "ticker": "SUNDAE",
        "url": "https://dex.sundaeswap.finance",
        "logo": "ipfs://ipfs/<ipfs-hash>",
        "logo-<size>": "ipfs://ipfs/<ipfs-hash>",
        "validation": "https://dex.sundaeswap.finance/assets/{policy-id}.{asset-name}",
        "decimals": 6,
        "version": "1.0",
        <other properties>
      }
    }
  }
}
  • ticker - is an optional field and overrides the which is the default ticker
  • url - should point to the team url. allows external parties to take the reputation of the url into account when evaluating the trust worthiness of the token. As value of this trust wanes with time as token gains a history of on chain usage, it’s ok if this url is incorrect at some point in the future (because the team is defunct or changes urls)
  • logo - should be either https, ipfs, or data
  • logo-<size> - allows teams to optionally provide their logo in different sizes. the recommended values of size are 16, 32, 64, 96, 128. logos are assumed to be square so that logo-64 would refer to a 64x64 logo
  • validation - provides protection against malicious parties attempting to forge a token from a real time.
  • decimals - how many decimal places should the token support? For ADA, this would be 6 e.g. 1 ADA is 10^6 Lovelace
  • version - of this proposal

Off-chain Approach

Because of transaction size constraints, an off-chain approach is also supported:

{
  "20": {
    "<policy-id>": {
      "<asset-name>": {
        "offchain": "ipfs://ipfs/<ipfs-hash",
        "version": "1.0",
      }
    }
  }
}
  • offchain - the ipfs url containing the metadata block (see below)
  • version - of this proposal

offchain metadata block

 {
  "ticker": "SUNDAE",
  "url": "https://dex.sundaeswap.finance",
  "logo": "ipfs://ipfs/<ipfs-hash>",
  "logo-<size>": "ipfs://ipfs/<ipfs-hash>",
  "validation": "https://dex.sundaeswap.finance/assets/{policy-id}.{asset-name}",
  "decimals": 6,
  "version": "1.0",
  <other properties>
}
4 Likes
2

There are some good points raised in the (ongoing) discussion of the currently considered CIP-0028 (which also enforces the timing of the token minting & metadata submission) about how to handle multiple registrations… perhaps it would help to include these in this proposal as well? In particular the comment:

So at the least I think this CIP needs a proposal for what to do in case of multiple registrations. A simple solution would be to privilege the first such registration; but this then introduces incentives for front-running such transactions in order to squat metadata.

2 Likes
3

Thank you. I’ve reposted this as a CIP here, CIPs/CIP-0030.md at master · savaki/CIPs · GitHub

My general sense is that this use proposal attempts to address a very specific issue that is more limited in scope than CIP-28 and consequently (hopefully) the issues around timing should not apply. Said more practically, once the SUNDAE token was issued, I would find it very strange indeed if a future party could rename it to the MONDAE token.

1 Like
4

sounds like it’s ready for peer review then :sunglasses: … also you can add another line (in addition to your PR link itself) like this to your CIP draft, which points back to this discussion thread, in case you get responses here as well as Github:

Comments-URI:
https://forum.cardano.org/t/cip-on-chain-token-metadata-standard/79153

1 Like
5

This proposal for metadata is extremely incomplete. I’m sorry, but this is amateur hour here. People use the metadata for more than trading cards and collecting.

3 Likes
6

Cheers for driving that conversation - there is clear understanding that the registry is a centralized tool - but one needed.
Generally we should try to not use the blockchain as a datastore - it isn’t meant to be / blocks have a finite space they can allocate. Some kind of alternate structure can however support tokens, and considerations should try to minimize the impact on the main chain!
Here are the CIP meeting notes from 5/11/21 where this specific aspect was touched to then (when the NFT standard was being discussed).
As a sidenote - consider joining the meetings if the time is appropriate to surface ideas or considerations of interests: they are all public and open to all - next one is in 24 hours!

1 Like
7

My hope is that we can aim for a hybrid approach, where alternate copies of registries can be hosted by entities in the ecosystem - copy/paste of the existing ones, maybe with custom attributes or functionalities? - While moving towards decentralizing the service eventually through smart contracts - but it’s very early and so for right now, the Foundation can step up and help nurture the tool directly!

1 Like
8

Exactly what I needed! You just saved me several hours. Thanks!
→ DGCustomerFirst

9

Copying Ethereum standards almost verbatim was also proposed for NFT meta data once upon a time. While there is nothing inherently wrong with this approach there is also nothing inherently correct about it either. To propose a data standard, that presumably should be globally adopted, you have two obvious approaches:

  1. Be generic enough to support all use cases without limitation
  2. Be interoperable enough to adapt to all use cases without burden

Otherwise it is significantly better to do as Cardano has already done and leave it flexible and open to interpretation on an as-needed basis.

NFT Metadata CIP Reference: https://forum.cardano.org/t/cip-nft-metadata-standard

2 Likes
10

I really like and support this proposal, but really worry about this:

“The first valid occurrence of a policy id and asset name pair will be considered authoritative and immutable.”

As we’ve found with NFT’s, over time mistakes are made and things can be corrected, because the latest is taken.

Given this has NOT been accepted but projects right now need to MINT. If you implement this, there is no option for projects minting right now; i.e. I have several clients that I need to mint their tokens right now and will likely follow this in hope OR the 721 (subject to the client). We’ll leave the policy open for a year so that we could REMINT a single token and burn it, in order to update the Metadata (as you can with the 721 standard), but what you propose nulls and voids this strategy (whilst agreements are made).

Could we PLEASE adopt the the 721 strategy? Once the Policy is locked, the metadata can’t be changed anyway. So let’s use the script capability to do this??

Kind regards

11

I think you could mint “new tokens” (using a new policy) and airdrop them to current (older) token holders as an alternative / more flexible approach to waiting.