Cardano Improvement Proposals

CIP 25 - Media NFT Metadata Standard

Contents

Abstract

This proposal defines an Media NFT Metadata Standard for Native Tokens.

Motivation

Tokens on Cardano are a part of the ledger. Unlike on Ethereum, where metadata can be attached to a token through a smart contract, this isn't possible on Cardano because tokens are native and Cardano uses a UTxO ledger, which makes it hard to directly attach metadata to a token. So the link to the metadata needs to be established differently. Cardano has the ability to send metadata in a transaction, that's the way we can create a link between a token and the metadata. To make the link unique, the metadata should be appended to the same transaction, where the token forge happens:

Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens are always created in specific forging operations, we can always trace them back through their transaction graph to their origin.

(Section 4.1 in the paper: https://hydra.iohk.io/build/5400786/download/1/eutxoma.pdf)

Considerations

That being said, we have unique metadata link to a token and can always prove that with 100% certainty. No one else can manipulate the link except if the policy allows it to (update mechanism).

Specification

This is the registered transaction_metadatum_label value

transactionmetadatumlabel description
721 NFT Metadata

General structure

The structure allows for multiple token mints, also with different policies, in a single transaction.

{
      "721": {
        "<policy_id>": {
          "<asset_name>": {
            "name": <string>,
    
            "image": <uri | array>,
            "mediaType": image/<mime_sub_type>,
    
            "description": <string | array>,
    
            "files": [{
              "name": <string>,
              "mediaType": <mime_type>,
              "src": <uri | array>,
              <other_properties>
            }],
    
            <other properties>
          }
        },
        "version": <version_id>
      }
    }

CDDL

Version 1\ Version 2

Optional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is:

Version 1

{
      "721": {
        "<policy_id>": {
          "<asset_name>": {
            "name": <string>,
            "image": <uri | array>
          }
        }
      }
    }

Version 2

{
      "721": {
        "<policy_id>": {
          "<asset_name>": {
            "name": <string>,
            "image": <uri | array>
          }
        },
        "version": 2
      }
    }

Retrieve valid metadata for a specific token

As mentioned above this metadata structure allows to have either one token or multiple tokens with also different policies in a single mint transaction. A third party tool can then fetch the token metadata seamlessly. It doesn't matter if the metadata includes just one token or multiple. The proceedure for the third party is always the same:

  1. Find the latest mint transaction with the label 721 in the metadata of the specific token
  2. Lookup the 721 key
  3. Lookup the Policy Id of the token
  4. Lookup the Asset name of the token
  5. You end up with the correct metadata for the token

Update metadata link for a specific token

Using the latest mint transaction with the label 721 as valid metadata for a token allows to update the metadata link of this token. As soon as a new mint transaction is occurring including metadata with the label 721, the metadata link is considered updated and the new metadata should be used. This is only possible if the policy allows to mint or burn the same token again.

Backward Compatibility

To keep NFT metadata compatible with changes coming up in the future, we use the version property. A future version will introduce schema.org.

References

This CIP is licensed under CC-BY-4.0.