Skip to content

Commit 15a0cd1

Browse files
alessandrokonradAlessandro Konrad
alessandrokonrad
and
Alessandro Konrad
authored
CIP-NFTMetdataStandard (#85)
* CIP-NFTMetdataStandard * changed metdata structure according proposed comment; added 721 label to CIP-0010 registry; added backward compatibility with hint to version 2.0 including schema.org * made clear in the description that mediaType is required inside the files property * changed to CIP-0025 Co-authored-by: Alessandro Konrad <ales@Alessandros-MBP.fritz.box>
1 parent 265c5f7 commit 15a0cd1

File tree

2 files changed

+131
-0
lines changed

2 files changed

+131
-0
lines changed

‎CIP-0010/registry.json

+4
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,8 @@
11
[
2+
{
3+
"transaction_metadatum_label": 721,
4+
"description": "CIP-0025 - NFT Metadata Standard"
5+
},
26
{
37
"transaction_metadatum_label": 1967,
48
"description": "nut.link metadata oracles registry"

‎CIP-0025/CIP-0025.md

+127
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
---
2+
CIP: 25
3+
Title: NFT Metadata Standard
4+
Authors: Alessandro Konrad <alessandro.konrad@live.de>, Smaug <smaug@pool.pm>
5+
Comments-URI:
6+
Status: Draft
7+
Type: Informational
8+
Created: 2021-04-08
9+
Post-History: https://forum.cardano.org/t/cip-nft-metadata-standard/45687 and https://www.reddit.com/r/CardanoDevelopers/comments/mkhlv8/nft_metadata_standard/
10+
License: CC-BY-4.0
11+
---
12+
13+
## Abstract
14+
15+
This proposal defines an NFT Metadata Standard for Native Tokens.
16+
17+
## Motivation
18+
19+
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.
20+
So the link to the metadata needs to be established differently.
21+
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:
22+
23+
> Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens
24+
> are always created in specific forging operations, we can always trace them back through their
25+
> transaction graph to their origin.
26+
27+
(Section 4.1 in the paper: https://hydra.iohk.io/build/5400786/download/1/eutxoma.pdf)
28+
29+
## Considerations
30+
31+
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](#update-metadata-link-for-a-specific-token)).
32+
33+
## Specification
34+
35+
This is the registered `transaction_metadatum_label` value
36+
37+
| transaction_metadatum_label | description |
38+
| --------------------------- | ------------ |
39+
| 721 | NFT Metadata |
40+
41+
### Structure
42+
43+
The structure allows for multiple token mints, also with different policies, in a single transaction.
44+
45+
```
46+
{
47+
"721": {
48+
"<policy_id>": {
49+
"<asset_name>": {
50+
"name": <string>,
51+
52+
"image": <uri | array>,
53+
"mediaType": "image/<mime_sub_type>",
54+
55+
"description": <string | array>
56+
57+
"files": [{
58+
"name": <string>,
59+
"mediaType": <mime_type>,
60+
"src": <uri | array>,
61+
<other_properties>
62+
}],
63+
64+
<other properties>
65+
}
66+
}
67+
"version": "1.0"
68+
}
69+
}
70+
```
71+
72+
The **`image`** and **`name`** property are marked as required. **`image`** should be an URI pointing to a resource with mime type `image/*` used as thumbnail or as actual link if the NFT is an image (ideally <= 1MB).
73+
74+
The **`description`** property is optional.
75+
76+
The **`mediaType`** and **`files`** properties are optional.<br /> **`mediaType`** is however required inside **`files`**. The **`src`** property inside **`files`** is an URI pointing to a resource of this mime type. If the mime type is `image/*`, **`mediaType`** points to the same image, like the on in the **`image`** property, but in an higher resolution.
77+
78+
The **`version`** property is also optional. If not specified the version is `1.0`. It will become mandatory in future versions if needed.
79+
80+
This structure really just defines the basis. New properties and standards can be defined later on for varies uses cases. That's why there is an "other properties" tag.
81+
82+
The retrieval of the metadata should be the same for all however.
83+
84+
Optional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is:
85+
86+
```
87+
{
88+
"721": {
89+
"<policy_id>": {
90+
"<asset_name>": {
91+
"name": <string>,
92+
"image": <uri | array>,
93+
}
94+
}
95+
}
96+
}
97+
```
98+
99+
### Retrieve valid metadata for a specific token
100+
101+
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:
102+
103+
1. Find the latest mint transaction with the label 721 in the metadata of the specific token
104+
2. Lookup the 721 key
105+
3. Lookup the Policy Id of the token
106+
4. Lookup the Asset name of the token
107+
5. You end up with the correct metadata for the token
108+
109+
### Update metadata link for a specific token
110+
111+
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.
112+
113+
## Backward Compatibility
114+
115+
To keep NFT metadata compatible with changes coming up in the future, we use the **`version`** property. Version `1.0` is used in the current metadata structure of this CIP.
116+
Version `2.0` will introduce [schema.org](https://schema.org).
117+
118+
## References
119+
120+
- Mime type: https://tools.ietf.org/html/rfc6838.
121+
- CIP about reserved labels: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/CIP-0010.md
122+
- EIP-721: https://eips.ethereum.org/EIPS/eip-721
123+
- URI: https://tools.ietf.org/html/rfc3986, https://tools.ietf.org/html/rfc2397
124+
125+
## Copyright
126+
127+
This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).

0 commit comments

Comments
 (0)