creating an undue burden on the project creators to provide a largely static amount of information via different web
forms and authentication schemes rather than simply publishing this information to the blockchain directly.
+
### CPS-0001: Metadata Discoverability and Trust
+
[CPS-0001](https://github.com/cardano-foundation/CIPs/pull/371) presents a problem of metadata discoverability and
+
This CIP attempts to address and solve several of the issues proposed in CPS-0001 but is most likely not a "complete"
+
solution and is rather narrowed (for the time being) to the scope of token projects although with some refinement to
+
the schema could potentially be expanded to support additional scopes.
+
The primary purpose of this CIP is to enhance discoverability of token projects utilizing and parsing only the
+
information contained on-chain. In the first version of this CIP we address the discoverability of top-level information
+
related to "Token Projects" such as NFT and FT projects needing to provide social media handles, human-friendly names,
+
The goal of both minimizing redundant data stored on-chain and enhancing discoverability of projects for platforms
+
like DExes and NFT Marketplaces is specifically referenced in Example #3 above.
+
Note that while some external chain indexing and validation will ultimately be required, there is no off-chain,
+
centralized or decentralized trusted repository of additional information required (although aspects of the metadata
+
provided may rely on off-chain storage solutions).
+
This CIP aims to ensure metadata "correctness" on two different fronts.
+
1. **Actual Data Correctness**
+
- This CIP utilizes a strongly-typed, numerically indexed data structure that should minimize common errors and
+
omissions observed in less strictly-typed standards. Parsers of the data presented within the scope of this
+
should ignore any non-specified or non-conforming data.
+
- Specifically in the context of correctness via proving provenance of the metadata, this CIP aims to address
+
correctness via the same data witness standards utilized by CIP-26 although with a slightly modified data
+
Currently existing solutions for things like NFT Project verification standards rely on trust methods such as
+
publish a special message on your website, send us a DM from your Twitter account, and other less secure means of
+
validating provenance of the data.
+
As mentioned in the *Data Provenance* note on Data Correctness above, this CIP minimizes the trust required by relying
+
on a verifiable witness signature versus currently existing solutions which largely rely on off-chain trust mechanisms
+
for proof of provenance. Therefore, we increase trust in the data by describing a relatively simple means of data
+
validation while decreasing the need for trust outside the scope of the on-chain metadata.
Where applicable the 0 (zero) index of all specification documents is reserved for an optional semantic version
-
to enable future extensions to this and CIP-specific sub-standards.
+
identifier to enable future extensions to this and CIP-specific sub-standards.
A numeric-indexed structure is used to support required and optional fields in a format that is compatible with both
CBOR and JSON transport formats with minimal changes to the data structure and to minimize the possibility of
-
or capitalization issues.
+
misspelling or capitalization issues.
### Registration Metadata Format
-
| Index | Name | Type | Required | Notes/Examples |
-
|-------|-------------------|-----------------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-
| 1 | Policy ID | String | Yes | The hex-encoded Native Asset Policy ID that is being registered in this request. |
-
| 2 | Feature Set | Array \<UInt\> | Yes | An array of unsigned integers specifying none or more CIP standards utilized by the tokens of this project. Should reference the assigned CIP number. |
-
| 3 | Validation Method | Array \<String\> | Yes | How should this payload be validated. |
-
| 4 | Nonce | UInt | Yes | A simple cache-busting nonce. Recommend to use the blockchain slot height at the time of submission. Only the highest observed nonce value should be honored by explorers. |
-
| 5 | Oracle URI | Array \<String\> | No | Reserved for future use, URI to an informational oracle API for this policy |
-
| 6 | [CIP Details] | Array \<CIP_Details\> | No | If one or more of the CIPs addressed in the Feature Set have additionally defined metadata, it may be added here |
+
| Index | Name | Type | Required | Notes/Examples |
+
|-------|-------------------------------------|-----------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
| 1 | Scope | Array \<Uint,*\> | Yes | An array defining the scope of this registration (for greater compatibility with CPS-0001). The first entry should be an unsigned integer value identifying the type of scope while the second entry addresses the specific scope of registration |
+
| 2 | Feature Set | Array \<UInt\> | Yes | An array of unsigned integers specifying none or more CIP standards utilized by the tokens of this project. Should reference the assigned CIP number. |
+
| 3 | Validation Method | Array \<String\> | Yes | How should this payload be validated. |
+
| 4 | Nonce | UInt | Yes | A simple cache-busting nonce. Recommend to use the blockchain slot height at the time of submission. Only the highest observed nonce value should be honored by explorers. |
+
| 5 | Oracle URI | Array \<String\> | No | Reserved for future use, URI to an informational oracle API for this policy |
+
| 6 | [CIP Details](#cip-specific-fields) | Array \<CIP_Details\> | No | If one or more of the CIPs addressed in the Feature Set have additionally defined metadata, it may be added here |
The following fields are required in all token registration submissions.
+
Currently, this CIP concerns itself with the scope of *Tokens* with relation to CPS-0001 as described in the Motivation
+
section. However, the specification is left flexible to encapsulate additional scopes and contexts (Stake Pools, dApps,
+
etc.) should the specification become adopted and the community desire to expand the scope of this CIP.
+
- **0**: Token Project Scope. The scope identifier should consist of an array with the first element set to 0 and the
+
element being the Policy ID referenced and governed by the remainder of the registration information.
-
`h'00000002df633853f6a47465c9496721d2d5b1291b8398016c0e87ae'`
+
`[0, h'00000002df633853f6a47465c9496721d2d5b1291b8398016c0e87ae']`
#### 2. Feature Set \<Array:Integer\>
-
#### 3. Witness Method \<Array:String\>
+
#### 3. Validation Method \<Array:String\>
in this CIP as a two-element array consisting of the hex-encoded policy ID and asset ID of the token to be used as a
beacon token for the purposes of smart contract interactions.
-
***CIP-Specific Fields***
+
##### CIP-Specific Fields
| index | name | type | required | notes |
|-------|-------------------|--------|----------|----------------------------|
-
***TODO: Change CIP-Specific documentation to include and utilize CDDL format.***
+
***CIP-25 & CIP-68 Top-Level Object Fields***
+
Both CIP-25 and CIP-68 are specifications describing a standard for storing and retrieving NFT metadata from the chain.
+
To this end, we have given them the same data structure although each will utilize their own numerical index in the
+
feature set and CIP-Specific details section of the registration.
+
These sections may be separated in the future if the respective CIPs diverge in terms of the data or information that
+
may be useful to provide about one format or the other diverge in the future.
+
| index | name | type | required | notes |
+
|-------|---------------------|--------|----------|--------------------------------------------------------------------------------------------------------------------------------------------|
+
| 0 | Version | String | No | Default: "1.0.0", which version of this specification is in use |
+
| 1 | NFT Project Details | Object | No | Provide additional context and information about this particular NFT "Collection" for consumption by marketplaces, explorers, and wallets. |
See [CIP25](CIP-25) for a description of a non-fungible token project policy registration.
([CIP25.json](CIP-25/CIP25.json) as an example, [CIP25.schema.json](CIP-25/CIP25.schema.json) for schema documentation).
-
***TODO: Change CIP-Specific documentation to include and utilize CDDL format.***
+
***CIP-26 Top-Level Object Fields***
+
| index | name | type | required | notes |
+
|-------|-----------------|------------------------|----------|-------------------------------------------------------------------------------------------|
+
| 0 | Version | String | No | Default: "1.0.0", which version of this specification is in use |
+
| 1 | Fungible Tokens | Array\<Token Details\> | No | An array of one or more fungible token registration objects covered by this registration. |
See [CIP26](CIP-26) for a description of a fungible token specific registration ([CIP26.json](CIP-26/CIP26.json) as an
example, [CIP26.schema.json](CIP-26/CIP26.schema.json) for schema documentation). This information can replace the
currently used in those registrations along with a few additional fields.
Because it is possible that multiple fungible tokens could be minted under a single Policy ID, the format for CIP-26
-
is slightly different. Here we include an array of fungible token details inside of an array to enable multiple tokens
-
the same policy to be registered in a single transaction.
+
tokens is slightly different. Here we include an array of fungible token details inside of an array to enable multiple
+
tokens under the same policy to be registered in a single transaction.
-
***Fungible Token Details Fields***
+
***Token Details Fields***
| index | name | type | required | notes |
|-------|----------------------|----------|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##### CIP-27: Cardano NFT Royalty Information
-
TODO: Write and link info for Royalty Information registration
+
***CIP-27 Top-Level Object Fields***
+
| index | name | type | required | notes |
+
|-------|-----------------|--------|----------|-----------------------------------------------------------------|
+
| 0 | Version | String | No | Default: "1.0.0", which version of this specification is in use |
+
| 1 | Royalty Details | Object | No | An object detailing the project royalties as defined in CIP-27 |
+
***Royalty Details Fields***
+
| index | name | type | required | notes |
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4&s=80)
