Skip to main content

CIP-0067

Abstract​

This proposal defines a standard to identify Cardano native assets by the asset name to put them in an asset class, as intended by their issuer.

Motivation: why is this CIP necessary?​

As more assets are minted and different standards emerge to query data for these assets, it's getting harder for 3rd parties to determine the asset class and associated extra assumptions that may arise from this identification. For example, if an asset is identified as a non-fungible token, a third party is interested in its onchain associated metadata. This standard is similar to CIP-0010, but focuses on the asset name of a native asset.

Specification​

To give issuers the option to classify assets, the asset_name MUST be prefixed with 4 bytes encoding the following binary value:

[ 0000 | 16 bits label_num | 8 bits checksum | 0000 ]
  • The leading and ending four 0s are brackets
  • label_num has a fixed size of 2 bytes (Label range in decimal: [0, 65535]). If label_num 0x00de
  1. Calculate CRC-8 checksum => 0x14
  2. Add brackets and combine label => 0x000de140

Verify a label​

We have the following asset name: 0x000de140

  1. Slice off the first 4 bytes of the asset name => 0x000de140
  2. Check if first 4 bits and last 4 bits are 0b0000 (0x0)
  3. Slice off the 2 label_num bytes and apply them to the CRC-8 algorithm. If the result matches with the checksum byte, a valid label was found and it can be returned. => 0x00de
  4. Convert to decimal => 222

Reserved labels​

These are the reserved asset_name_label values

asset_name_labelclassdescription
0 - 15-private use

Adding an entry to the registry​

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in RFC 2119.

Those wishing to propose an addition to this registry MUST draft a new CIP describing the standard for implementing the token. Once the CIP has achieved the Under Review status the proposer SHALL make the necessary edits to registry.json. These changes SHOULD be submitted under a separate pull request against the CIP repository and include a brief description of the standard and a link to the CIP Pull Request describing implementation details.

Test Vectors​

Keys represent labels in decimal numbers. Values represent the entire label, including brackets and checksum in hex:

0     : 00000000
1     : 00001070
23    : 00017650
99    : 000632e0
533   : 00215410
2000  : 007d0550
4567  : 011d7690
11111 : 02b670b0
49328 : 0c0b0f40
65535 : 0ffff240

Rationale: how does this CIP achieve its goals?​

Asset name labels make it easy to identify native assets and classify them in their asset class intended by the issuer. Since the identification of these native assets is done by third parties, the design is focused on the usability for them.

First, the label should be quickly parsable with a first check. That is, an initial check on an asset name that is easy and will exclude a big subset of the available token names that do not follow standard. This is why the label starts and ends with 0000 in bits. Additionally, in its hex notation, this is differentiable by a human in its readable form, a more common representation.

Secondly, the remaining verification on whether a certain asset_name_label standard is followed should be a one shot calculation. Here we mean that the calculation of the check should be straightforward, the label should not be fitted via brute force by a third party. That's why the label contains the bit representation of the integer label it tries to follow.

Another thing that is important to understand is that an oblivious token issuer might not be aware of this standard. This could lead to the unintentional misinterpretation by third parties and injection attacks. We can minimize this attack vector by making the label format obscure. That is why the label also contains a checksum derived from the asset_name_label to add characters that are deterministically derived but look like nonsense. Together with the above zero "brackets", and the fixed size binary encoding, it make it unlikely someone follows this standard accidentally. The CRC-8 checksum is chosen for it low-impact on resources and its readily available implementations in multiple languages.

Path to Active​

Acceptance Criteria​

  • Get support for this CIP by wallets, explorers, minting platforms and other 3rd parties.
  • Get support by tools/libraries like Lucid, PlutusTx, cardano-cli, etc. to generate/verify labels.

Implementation Plan​

This CIP is licensed under CC-BY-4.0.

CIP Information​

This null ./CIP-0067 created on 2022-07-13 has the status: Proposed.
This page was generated automatically from: cardano-foundation/CIPs.