xUDT Information Convention RFC

English
1

Background

xUDT (RGB++) assets on CKB are similar with ERC20 assets on Ethereum, they lack protocol-level uniqueness constraints for token names. Considering the convention of the Bitcoin ecosystem, we need to introduce some standard regarding uniqueness and length.

Scope

  • The following conventions cover inscription info cell & unique cell, combining the two for processing. For example, they only allow one asset to use the same name among them.

  • These conventions only consider the Symbol and do not consider the Name field.

# Unique cell
{
  "code_hash": "0x2c8c11c985da60b0a330c61a85507416d6382c130ba67f0c47ab071e00aec628",
  "hash_type": "data1",
  "out_point": {
    "tx_hash": "0x67524c01c0cb5492e499c7c7e406f2f9d823e162d6b0cf432eacde0c9808c2ad",
    "index": "0x0"
  },
  "dep_type": "code"
}

Name confliction

  • Only the first occurrence of a duplicate asset name on the chain is acknowledged; subsequent occurrences are marked as “duplicate”.
  • Case sensitivity is ignored during duplicate comparison, meaning “Seal” is considered the same as “SEAL”.
  • Any addition of invisible characters (including spaces) to the name, regardless of whether there are similar assets, is treated as a “duplicate”.
  • For wallets and exchanges, duplicate assets are directly hidden.
  • For browsers, “duplicate assets” are labeled as “Risk Asset - RGB++ incompatible”, while non-duplicate assets are labeled as “RGB++ Compatible”. In places where the aforementioned text is too long to display, symbols such as [!] and [+] are used for marking.

Letters

  • For exchanges, only the ASCII visible character subset is supported.
  • For wallets and browsers, the supported character range includes:
    • ASCII visible characters subset
    • A subset of emojis: to be determined
  • For assets that use unsupported characters, the asset name is uniformly displayed as “INVALID”.

Length range

  • Only assets with Symbol length of 4-5 characters are processed normally.
  • Assets falling outside this range are treated as “duplicate assets”.

Verification

  • There exists a whitelist that can override the above rules.
  • This whitelist is hosted on Cell Studio’s GitHub repository. Project owners submit their token information, which is reviewed and released after verification. Assets listed on the whitelist are prioritized and displayed regardless of the above rules. Other assets with the same name are automatically marked as “duplicate assets”.
  • As of now, there is no whitelist available.

Assets mark

Ecosystem apps should add label / mark for every asset to provide some critical information:

  • Issuance mark: L1 issue / L2 issue to identify where the coins are issued, on Bitcoin with rpgpp_lock or CKB with normal lock
  • Supply mark: Limited supply / Unlimited supply to identify whether a coin could be issued arbitrarily.
7 Likes
2

We need to set a deadline or condition, and remove any naming conflict detection after these conditions are met, same goes for length range.

1 Like
3

I think case sensitive is necessary. For example, can you say that “Turkey” is “turkey”?

4

Perfection is an elusive concept, and there is no such thing as a perfect entity in this world. In fact, when you describe something as perfect, it may already have lost its perfection. Of course, there is also no such thing as a perfect design, and we always need to make trade-offs and compromises in the design process. Regarding the idea of differentiating between uppercase and lowercase letters, I believe it is a flawed approach. Imagine this: Turkey, tUrkey, tuRkey, turKey,… TURKEY. All possible combinations of uppercase and lowercase letters can be used, and if all these tokens appear in the trading market at the same time, it will undoubtedly complicate matters. Don’t you think so?

3 Likes
5

唯有这一点不认可，审核，被谁审核呢？Who is qualified to judge? 只要项目方审核了，那原本首个部署的就变成了“重复”，部署和mint产生的费用，以及发生的交易，谁来负责？这个规则不符合区块链去中心化、抗审查对精神。code is law，项目方不是law。

6

It’s something like Uniswap token list, you can build your own list if you don’t like the default ones.

2 Likes
7

Hey @Cipher, congratulations on the development of this metadata format and getting it adopted by Nervos Explorer!! :hugs:

I was wondering, given a xUDT for which I want to add on-chain metadata, like iCKB xUDT, which tool is advised?

Is utxostack/unique-cell’s generator-example the correct one to use?

Love & Peace, Phroi

8

Hi, phroi,

The community has developed the open-source project xudtlogos, which not only supports displaying logos but also allows users to upload xUDT information for Dapps to use. Currently, Dapps like Omiga and UTXOSwap are utilizing this project.

1 Like
9

Hey @yixiu.ckbfans.bit, thank you for letting me know!! :hugs: Have you tried reaching out to the Nervos Explorer folks?

At the moment feels like iCKB xUDT will have to support both meta standards, which is ok. On one side the one that you are proposing is the most straightforward and pretty similar to the original Uniswap token lists idea, when multiple lists created by different entities can coexist. On the other side I just finished coding the typescript utility for adopting the standard proposed in this RFC.

Love & Peace, Phroi