CIP-???? | On-Chain Token Metadata Standard #137

savaki · 2021-10-12T12:02:26Z

The following CIP proposes an on-chain metadata standard to work along aside existing off-chain metadata standards.

savaki · 2021-10-12T13:12:55Z

See discussion on Cardano forums here, https://github.com/savaki/CIPs/blob/master/CIP-0030/CIP-0030.md

rphair · 2021-10-12T14:36:45Z

See discussion on Cardano forums here, https://github.com/savaki/CIPs/blob/master/CIP-0030/CIP-0030.md

Did you mean to include this link in your last comment? 🤔 https://forum.cardano.org/t/cip-on-chain-token-metadata-standard/79153 ... otherwise it's a link to your proposal draft itself 😎

savaki · 2021-10-12T14:38:55Z

Going to resubmit as it looks like CIP-30 is already taken

AndrewWestberg · 2021-10-28T20:57:47Z

CIP-0031/CIP-0031.md

+ticker      | OPTIONAL | when present, field and overrides default ticker which is the asset-name |
+url         | OPTIONAL | https only url that refers to metadata stored offchain.  The URL SHOULD use the project domain and MUST return authenticity metadata in either html or json format (see below) |
+desc        | OPTIONAL | additional description that defines the usage of the token |
+logo        | REQUIRED | MUST be either https, ipfs, or data.  logo MUST be a browser supported image format.


Mismatch in this table to the examples. Table uses "logo", but examples use "icon".

thanks, fixed to icon in latest

SebastienGllmt · 2021-11-23T10:02:30Z

CIP-0031/CIP-0031.md

+asset-name  |          | hex encoded asset name |
+ticker      | OPTIONAL | when present, field and overrides default ticker which is the asset-name |
+url         | OPTIONAL | https only url that refers to metadata stored offchain.  The URL SHOULD use the project domain and MUST return authenticity metadata in either html or json format (see below) |
+desc        | OPTIONAL | additional description that defines the usage of the token |


Probably it's good to highlight that desc and logo are different form the CF registry

Oops, I accidentally pressed "approve" instead of comment, but I don't oppose this CIP anyway

KtorZ

This item was discussed during today's meeting.

A few points were raised:

The discussions around this proposal are very similar to those that happened for CIP-0025 so make sure to review the discussion(s) that happened during that time and in particular, the points that were made about:
- Pros and cons of storing data on-chain
- Using schemas from https://schema.org to try leveraging already standardized schema
The proposal is currently missing a rationale section which we expect to go over at least the following points:
- Pros and cons of storing data on-chain in this manner.
- Comparison with CIP-0025
- A mention to CIP-0026 and the off-chain approach (feel free to also add a mention to this CIP in CIP-0026 at the same time).
The fields currently summarized in a table should be defined as a separate JSON schema. See CIP-0010, CIP-0025 or CIP-0026 as examples.
The proposal makes use of the metadata label 20, which needs to be registered on CIP-0010 as part of this PR (may be worth considering the label 31 to match the CIP's number?)
The structure of the repository has changed recently, so please rename the file as README.md (under the same directory).

KtorZ · 2021-11-23T10:42:02Z

CIP-0031/CIP-0031.md

+policy-id   |          | token policy id        |
+asset-name  |          | hex encoded asset name |
+ticker      | OPTIONAL | when present, field and overrides default ticker which is the asset-name |
+url         | OPTIONAL | https only url that refers to metadata stored offchain.  The URL SHOULD use the project domain and MUST return authenticity metadata in either html or json format (see below) |


What would define the project domain 🤔 ? Or more exactly, how a consuming client like a wallet would know what the domain is for a particular metadata. This echoes to the "authenticity metadata" below.

KtorZ · 2021-11-23T10:44:49Z

CIP-0031/CIP-0031.md

+
+The url provided in the token metadata should return content in either html or JSON format.  
+
+* In JSON format, the url should return a JSON block of the same shape as the on-chain token metadata that includes both the policy-id and asset-name to be verified.


Maybe a silly question but, if it is required for downstream consumers to query the url provided in the token metadata ... why do we require to include all metadata on-chain in the first place? Wouldn't it be more efficient (space-wise) to only include: (a) a URL, (b) a hash of the expected metadata on-chain, and let client gather other metadata off-chain?

Also, how does one whether a given URL is valid? Do we expect wallets to whitelist some URLs for known tokens?

michaelpj · 2021-12-06T14:47:53Z

This PR also needs some discussion of the security aspects. As far as I can tell, it has the same issues as #118.

michaelpj · 2021-12-08T12:25:39Z

To elaborate a little, this currently assumes that the first minting is performed by the party who "organized" the token creation. This is not necessarily the case, and so if this were to become a standard, anyone who used a scheme where they weren't the first minter could be attacked by whoever was the first minter (since they would get to set the metadata).

In other words, adopting this as a standard would make it an attack vector against people who use (perfectly reasonable) schemes of token issuance that don't happen to look like a typical NFT drop.

crptmppt

Hi Matt, this PR was discussed in Editor meeting 35 in addition to the PR conversations. Consensus is that there needs to be a more fleshed out addressing of the edgecases to make sure this doesn't accidentally expose users to inadvertent vulnerabilities if going non-standard ways...

Thanks for trying to answer current concerns to move this PR along!

moving the numbering to 35 tentatively

sp33dy · 2022-01-05T11:43:40Z

Hi all,

Given there is no agreed standard, this is having a big impact on those minting tokens right now. This is what I'm now doing for new tokens:

(1) Mint 1 token with this standard first
(2) Mint the rest of the tokens with the 721 NFT standard (so it can be seen in pool.pm)
(3) Register in the token registry

I'm doing this in the hope that any tool/wallet looks through all metadata and if it finds a '20' standard (and it could be just the first one), it uses that over the 721. For projects like HOSKY, this was first minted with 721 and recently extended with a 20 and then another 721 update on top; it's now locked out.

I can see this problem getting worse as more people bring tokens to the table where they NEED to lock their policies. I really dislike the Token Registration, because this information (in my opinion) should be stored onchain; immutable. However, if we don't have a standard, things start to drift apart very quickly and trust will be lost in terms of the metadata side.

I continually explain to people that these standards only affect onchain metadata; i.e. the tokens are first class citizens and live and move like ADA. So we should be able to resolve this quickly?

Kind regards

VEGAS Pool (sp33dy is simply my github handle)

mkazlauskas · 2022-01-21T12:15:45Z

Should specify min and max length for ticker and probably the rest of the string fields.Ticker max length has been recently increased from 5 to 9 in offchain-metadata-tools.

theachyutraj · 2022-01-24T07:26:42Z

Hi all,

Given there is no agreed standard, this is having a big impact on those minting tokens right now. This is what I'm now doing for new tokens:

(1) Mint 1 token with this standard first (2) Mint the rest of the tokens with the 721 NFT standard (so it can be seen in pool.pm) (3) Register in the token registry

I'm doing this in the hope that any tool/wallet looks through all metadata and if it finds a '20' standard (and it could be just the first one), it uses that over the 721. For projects like HOSKY, this was first minted with 721 and recently extended with a 20 and then another 721 update on top; it's now locked out.

I can see this problem getting worse as more people bring tokens to the table where they NEED to lock their policies. I really dislike the Token Registration, because this information (in my opinion) should be stored onchain; immutable. However, if we don't have a standard, things start to drift apart very quickly and trust will be lost in terms of the metadata side.

I continually explain to people that these standards only affect onchain metadata; i.e. the tokens are first class citizens and live and move like ADA. So we should be able to resolve this quickly?

Kind regards

VEGAS Pool (sp33dy is simply my github handle)

I'm sorry I can't find a mint transaction of HOSKY where they use the '20' metadata. Could you please point me to one? Thanks!

sp33dy · 2022-01-24T08:11:54Z

Hi,

https://cardanoscan.io/token/f03c3a145fc45a873d999e0ef0b594d681a2238e?tab=minttransactions

Shows all the mint transactions.. So:

1e0612fbd127baddfcd555706de96b46c4d4363ac78c73ab4dee6e6a7bf61fe9 was our original 721 as 1 Quadrillion mint

f6f8192d0ba5649f0b9a18913003c41d122baa09190237353a30afddf38d09a8 was our '20' mint:
metadata: https://cardanoscan.io/transaction/f6f8192d0ba5649f0b9a18913003c41d122baa09190237353a30afddf38d09a8?tab=metadata

cb1fa55134b120d652c6d17ad83029d67be23f02d0542cb54100f343839c295c was the burn of that additional token with '20' standard.

0a4a906b24d21c3f4b8c061fd9b98f1b14a3bc9d6744f21a3a767ce4c964c16f was a new mint with 721 and the HOSKY image included

b67b3aa6713f9c8b313d38e56f0283304defbf1316848dac625a0ccdb770bd56 was a burn of it due to an error in the image

Finally:

2ca69dd7e0980e14d3a54a6c354a83e4a9a6969360a142e392691c2808541d0c was minted with the final 721 and correct HOSKY image. By rights, the '20' standard above should be picked up as the first and only '20' mint.

Giving us a total of 1 Quadrillion + 1 HOSKY Tokens before the policy locked on new years eve '21.

Kind regards

VEGAS

SmaugPool · 2022-01-24T08:13:11Z

CIP-0035/CIP-0035.md

+# Specification
+
+Minters of tokens on the Cardano blockchain main optionally choose to associate the following transaction metadata to facilitate off-chain labeling of tokens.
+When doing so, transaction metadata MUST be included in the same transaction that mints the asset id.


This does not precise which mint tx to use when there are several for the same asset.

CIP 25 requires to use the last mint tx (burns are not considered mints but this should be precised), which allows to update the metadata as long as the policy allows it by minting a duplicate then burning it.

This point should be precised in my opinion (for now I don't know how to implement the lookup).

I agree that it needs to be precise. I recommend that the FIRST time the "20" metadata appears is the only one that matters. For something like decimals, you should get it right the first time and never change it.

nilaysaha · 2022-02-10T17:19:22Z

Hi.

Currently struggling with requirements of some sort of onChain RBAC requirements for smart Contract, when issuing NFT for real world assets such as real estate (https://www.reitcircles.com). Because in this case there are several real world triggers of loss of ownership. etc. that require special legal actions to be taken including freezing of assets if required (bad actors and bad weather scenarios).

One of the chains that has taken care of this is Algorand via their "ASA (Algorand standard Asset)" standard.
[https://developer.algorand.org/docs/get-details/asa/](ASA docs) and hence it is wise to learn from the standard they have created and will be relevant for Cardano as well.

If one sees there are a set of parameters that can be broadly classified as "mutable" and "immutable"

Mutable ones are basically on-chain addresses that acts as some sort of heirarchy of addresses to serve RBAC:

manager address
reserve address
freeze address
clawback address

And immutable ones are:

Creator
assetname
unitname
total
decimals
defaultfrozen
url
metadatahash

And both the above set are on-chain parameters.

They have made an extensive study of the use cases underlying real world uses cases which can be summarised under 7 use cases:

Asset creation
Asset Reconfiguration (mutable parameters above)
Asset Freezing
Asset Destruction
Asset Transfer
Asset Revocation
Asset Opt-in (means for certain cases people need kyc and opt-in to receive assets. Just like cookie opt-in)

As you see, for our project, we are now facing this challenge of implementing the above use cases for smart contracts. I was wondering if someone from the Plutus community can help me understand which of the above can be implemented with the cardano SC scenario (as it exists today) and which would require protocol level changes and cannot be done using the SC as of now.

Thanks and looking forward to some discussion.

mangelsjover · 2022-02-28T09:42:42Z

Hi @savaki ,

Could you please provide an update on this PR?

Thank you very much.

WhitemanE0 · 2022-03-15T08:19:02Z

CIP-0035/CIP-0035.md

+It is not expected nor desired for all tokens to contain `CIP-31` metadata.
+
+
+


Any move forward on this CIP?
Is it likely or onlikely it will be supported?
I think positive to On-Chain Token Metadata Standard, becouse currently fungible tokens massively being minted with CIP-25 which is confusing. And offchain token registry is not robust solution

If one need an example to try support draft CIP, I have minted some according to this CIP:
https://pool.pm/$whiteman/%40f0a2917d

gitmachtl · 2022-04-02T15:41:06Z

Shouldn't the metadata not be signed with the policy.skey like we do with the metadata registry?
Also, i don't see the requirement to have included in the first minting process. Just make it that the first appearance on chain counts, and all of the ones afterwards not.

Padierfind · 2022-04-12T06:58:50Z

Hello everyone.

Can't we make this whole proposal a little bit more aligned with the already existing NFT Metadata standard? Where's the mimetype, why no subfiles, why does the asset name need to be hex-encoded?

{
  "20": {
    "<policy_id>": {
      "<asset_name>": {
        "ticker": "<string>",
        "name": "<string>,
        "image": <uri>,
        "mediaType": "image/<mime_sub_type>",
        "description": <string | array>,
            "files": [{
              "name": <string>,
              "mediaType": <mime_type>,
              "src": <uri | array>,
              <other_properties>
            }],
        "decimals": 6,
        "version": "1.0"
      }
    }
  }
}

would be my proposition.

What do you think?

gitmachtl · 2022-04-12T09:58:53Z

The hex representation is used internally by all tools, its independent from a charset. The assetName was always specified in the CDDL as a byteArray, not as a charArray. People started to use them with just chars, but thats not the correct way to handle assetNames. Tools like cardano-cli have changed a while ago to use the right hex-representation format. The metadata registration used this format since the beginning. So its logical to use this universal approach in all tools to be indepentent from the local / utf charset.

Mimetype for the icon/image is not needed IMO. Because all tools i know do an internal filetype check anyways depending on the fileextension or just on a general base. I don't think many tools trust the registered mime/type really and not displaying a correct icon png because the mimetype was set to image/jpeg.

mangelsjover · 2022-04-12T18:07:46Z

Hello @savaki ,

Could you please provide an update on this PR?

Thank you very much.

M.

AndrewWestberg · 2022-04-12T22:08:11Z

Can't we make this whole proposal a little bit more aligned with the already existing NFT Metadata standard?

... or why not just add an optional "decimals" and "ticker" fields to the existing 721 standard? Everything else is just duplication.

rphair · 2022-07-15T01:13:37Z

(comment deprecated)

Patientdame

Please I want my token back

rphair · 2022-10-01T11:38:18Z

We don't have any update from @savaki after a handful of invitations over the course of the year, so I think it's appropriate to close this now.

(edit, p.s.) There might be a practical solution in here somewhere & perhaps someone else in the community will take this over & reopen this... but given the time & feedback above it would likely make more sense to open up a new PR.

AndrewWestberg · 2022-10-01T13:49:04Z

I think @savaki left SundaeSwap which is where this CIP originated. Tagging @Quantumplation in case it needs re-opening.

rphair · 2022-10-01T13:54:34Z

thanks @AndrewWestberg for the follow-up 🙏

Quantumplation · 2022-10-12T18:27:03Z

@rphair Sorry for the lack of response on this. I have no particular skin in the game for metadata standards; I've had some chats with the Cardano Foundation about it, and about what my opinions on the topic are, but I'm happy to follow any (or multiple) standards that the community directs;

Given that this is deployed on-chain by a number of projects, though, could we assign it a CIP number for easy historical reference, as many tools will likely want to support this standard for legacy purposes until another standard emerges?

gitmachtl · 2022-10-12T18:50:26Z

Just to comment on this PR: The hardware wallets with the decimals baked into the firmware are not using transaction metadata with key 20 as a source or any other metadata on the chain. Only reference is the cardano-token-registry

rphair · 2022-10-12T18:54:04Z

@Quantumplation we've been having a lengthy discussion (@KtorZ @michaelpj) as of #331 (comment) about whether CIPs can go on file with a Rejected status (e.g. #336) indicating institutional or community support for not doing something in the way that's described.

What I gather you're suggesting here is that the same kind of reference be made... but for something that is in active use, except that by not following through with the CIP process, it would remain a de facto standard which nobody has taken the final responsibility to document officially.

My dogmatic belief is that it's not a standard if nobody is willing to document it conclusively, and therefore the content here should likewise be given a Rejected status (rejected as a standard in this case: not "rejected for use"). If agreed then this could & should in fact also be given a CIP number and a Rejected state just like the pending CIP-0070 which is our flagship "anti-standard" CIP.

The exact label & definition of "Rejected" is pending #331 and whatever rewrite of CIP-0001 comes afterward, so I would propose that this CIP draft be assigned that classification after that rewrite is complete & that "Rejected" status becomes official.

Quantumplation · 2022-10-12T19:58:55Z

@rphair I think we're on the same page, I'm speaking from a more pragmatic standpoint.

Specifically, I agree that we shouldn't consider this a "standard" without someone to take up the banner to get it over the finish line and document it in high-fidelity for new projects to adopt. I would do so, but frankly I'm juggling enough as it is, and can't find the time to think through what the best version of this looks like, or whether an entirely different approach is better.

But, whether we like it or not, this format has been adopted by several projects; so, while I think we want to actively discourage new projects from adopting this for their token (until it or another standard reaches that bar), there are still people who will want to refer to this, mostly from a historical / legacy support perspective: wallets, block explorers, DEX's, etc. will want to present this data to users, because those projects still want to provide the best and most comprehensive user experience to their users.

So, those people need a moniker to refer to this by, for discussions, JIRA tickets, code, etc.

It sounds like, though, a rejected CIP would still be assigned a CIP number, which satisfies that need.

savaki added 5 commits October 12, 2021 06:41

initial commit

f1975da

added examples

5cfe97d

added notes

15a4720

added additional notes

e32dcb5

updated comment url

cebec71

renamed CIP-30 to CIP-31

8b90ef5

savaki changed the title ~~CIP-0030 On-Chain Token Metadata Standard~~ CIP-0031 On-Chain Token Metadata Standard Oct 12, 2021

crptmppt added tentative CIP labels Oct 13, 2021

AndrewWestberg reviewed Oct 28, 2021

View reviewed changes

renamed logo to icon for consistency

508e71b

SebastienGllmt approved these changes Nov 23, 2021

View reviewed changes

KtorZ reviewed Nov 23, 2021

View reviewed changes

alessandrokonrad mentioned this pull request Nov 24, 2021

Asset and Collectibles sorting input-output-hk/nami#107

Closed

crptmppt added the State: Last Check Review favourable with disputes resolved; staged for merging. label Dec 7, 2021

crptmppt removed the State: Last Check Review favourable with disputes resolved; staged for merging. label Dec 16, 2021

crptmppt suggested changes Dec 16, 2021

View reviewed changes

crptmppt changed the title ~~CIP-0031 On-Chain Token Metadata Standard~~ CIP-0035 | On-Chain Token Metadata Standard Dec 16, 2021

Update and rename CIP-0031/CIP-0031.md to CIP-0035/CIP-0035.md

1d9fbd0

moving the numbering to 35 tentatively

mkungla mentioned this pull request May 6, 2022

Ensure correct On-Chain Token Metadata before policy expires howijd/howijd.network#136

Open

1 task

SmaugPool reviewed Jan 24, 2022

View reviewed changes

rhyslbw mentioned this pull request Feb 14, 2022

CIP-35? | Plutus Core Evolution #215

Merged

WhitemanE0 reviewed Mar 15, 2022

View reviewed changes

KtorZ changed the title ~~CIP-0035 | On-Chain Token Metadata Standard~~ CIP-0038? | On-Chain Token Metadata Standard Mar 17, 2022

mangelsjover added the State: Waiting for Author Proposal showing lack of documented progress by authors. label Apr 12, 2022

alessandrokonrad mentioned this pull request Jul 15, 2022

CIP-0067 | Asset Name Label Registry #298

Merged

KtorZ changed the title ~~CIP-0038? | On-Chain Token Metadata Standard~~ CIP-???? | On-Chain Token Metadata Standard Aug 2, 2022

Patientdame suggested changes Sep 13, 2022

View reviewed changes

rphair closed this Oct 1, 2022

rphair mentioned this pull request Apr 2, 2024

CIP-0119? | Governance Metadata - DReps #788

Merged


		The url provided in the token metadata should return content in either html or JSON format.

		* In JSON format, the url should return a JSON block of the same shape as the on-chain token metadata that includes both the policy-id and asset-name to be verified.

		It is not expected nor desired for all tokens to contain `CIP-31` metadata.

CIP-???? | On-Chain Token Metadata Standard #137

CIP-???? | On-Chain Token Metadata Standard #137

Conversation

savaki commented Oct 12, 2021

savaki commented Oct 12, 2021

rphair commented Oct 12, 2021

savaki commented Oct 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KtorZ left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelpj commented Dec 6, 2021

michaelpj commented Dec 8, 2021

crptmppt left a comment

Choose a reason for hiding this comment

sp33dy commented Jan 5, 2022 • edited Loading

mkazlauskas commented Jan 21, 2022

theachyutraj commented Jan 24, 2022

sp33dy commented Jan 24, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nilaysaha commented Feb 10, 2022

mangelsjover commented Feb 28, 2022

WhitemanE0 Mar 15, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gitmachtl commented Apr 2, 2022 • edited Loading

Padierfind commented Apr 12, 2022

gitmachtl commented Apr 12, 2022 • edited Loading

mangelsjover commented Apr 12, 2022

AndrewWestberg commented Apr 12, 2022

rphair commented Jul 15, 2022 • edited Loading

Patientdame left a comment

Choose a reason for hiding this comment

rphair commented Oct 1, 2022 • edited Loading

AndrewWestberg commented Oct 1, 2022

rphair commented Oct 1, 2022

Quantumplation commented Oct 12, 2022

gitmachtl commented Oct 12, 2022

rphair commented Oct 12, 2022 • edited Loading

Quantumplation commented Oct 12, 2022

sp33dy commented Jan 5, 2022 •

edited

Loading

sp33dy commented Jan 24, 2022 •

edited

Loading

WhitemanE0 Mar 15, 2022 •

edited

Loading

gitmachtl commented Apr 2, 2022 •

edited

Loading

gitmachtl commented Apr 12, 2022 •

edited

Loading

rphair commented Jul 15, 2022 •

edited

Loading

rphair commented Oct 1, 2022 •

edited

Loading

rphair commented Oct 12, 2022 •

edited

Loading