initial commit

CIP-0030/CIP-0030.md

@@ -0,0 +1,104 @@
+---
+CIP: 30
+Title: On-Chain Token Metadata Standard
+Authors: Matt Ho <matt.ho@gmail.com>
+Comments-URI: https://github.com/cardano-foundation/CIPs/pulls/118
+Status: Draft
+Type: Standards
+Created: 2020-10-12
+License: CC-BY-4.0
+---
+
+# Abstract
+
+This specification defines a new transaction metadata label (i.e. `20`) and entry for [CIP-0030] to associate token metadata during a minting transaction.  Unlike CIP-28, this
+proposal is intended to define a specific schema to allow basic information about fungible tokens to be provided On-Chain.
+
+# Motivation
+
+The (Cardano Token Registry)[https://github.com/cardano-foundation/cardano-token-registry] is a centralized Off-Chain governance system to manage token 
+metadata.  This proposal aims to provide an On-Chain solution to the same problems that will afford users a much higher degree of trust than the existing
+system.  
+
+Specifically, this proposal aims to solve for the following:
+
+* Provide a standardized way to associate an icon and a ticker with a token
+* Provide a mechanism that allows the viewer to evaluate the trustworthiness and/or authenticity of a token
+
+# 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.
+
+> <sub>NOTE</sub>
+>
+> The following provides an example of the proposed on-chain metadata:
+```json
+{
+  "20": {
+    "<policy-id>": {
+      "<asset-name>": {
+        "ticker": "SUNDAE",
+        "url": "https://dex.sundaeswap.finance/assets/{policy-id}.{asset-name}",
+        "desc": "SUNDAE",
+        "icon": "ipfs://ipfs/<ipfs-hash>",
+        "icon-<size>": "ipfs://ipfs/<ipfs-hash>",
+        "decimals": 6,
+        "version": "1.0"
+      }
+    }
+  }
+}
+```
+
+Field       |          | Description            |
+:---        | :----    | :----                  |
+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) |
+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.
+logo-&lt;size&gt; | OPTIONAL | allows teams to provide icon 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
+decimals    | OPTIONAL | how many decimal places should the token support? For ADA, this would be 6 e.g. 1 ADA is 10^6 Lovelace
+version     | OPTIONAL | when not specified, version will default to `1.0`
+
+> <sub>NOTE</sub>
+>
+> The following provides an example of the alternate proposed on-chain metadata reference:
+
+```json
+{
+  "20": {
+    "<policy-id>": {
+      "<asset-name>": {
+        "ref": "https://assets.sundaeswap.finance",
+      }
+    }
+  }
+}
+```
+
+In some cases, it is not practical or desirable to have embed the metadata on-chain.  In these cases, this proposal allows the on-chain
+
+
+Field       |          | Description            |
+:---        | :----    | :----                  |
+policy-id   |          | token policy id        |
+asset-name  |          | hex encoded asset name |
+ref         | REQUIRED | https only url that holds the metadata in the onchain format (see above).  The URL SHOULD use the project domain and MUST return the token metadata as described above
+
+
+### Authenticity Metadata
+
+To help prevent adversaries from creating fake tokens with the intent to defraud users, projects may authenticate tokens using domains they control.  This
+mechanism provides users a better understanding of where their tokens came from.
+
+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.
+* In HTML format, the url should contain the a `meta` tag with `name` of `cip-30:authenticate` and a value of a comma separate list of tokens to declare as authenticate where tokens are formatted as `{policy id}{hex-encoded asset name}` with no space in between
+
+
+
+