[FR] Add iCKB Scripts to the Explorer

[phroi]

Hello folks at Nervos Network, iCKB here 👋
After passing both internal and external audit, iCKB scripts have been deployed on Testnet and Mainnet.

Please, could you list the scripts on the explorer?

I'd like to point out a couple of gotchas:

• All the scripts (iCKB Logic, Limit Order and Owned-Owner) are used both as lock scripts and type scritps.
• On both testnet and mainnet iCKB xUDT use a reference by data1 of xUDT.

Keep up the Great Work 💪
Phroi

[Keith-CY]

Hi @phroi appreciate your brilliant work

There are 3 scripts:

• iCKB Logic
• Limit Order
• Owned-Owner

They will be labeled by PR #1788

Before this PR is merged, could you please add the following to each of them:

1. a brief description of the script
2. a link to the source code if possible
3. a link to the docs if possible

[phroi]

Hey @Keith-CY, thank you for creating the pull request draft!! 🤗

[phroi]

Additionally, @Hanssen0 told me there is a form to submit token info in explorer. I double checked if I could add this data with my commit, but the token data seem to be stored in a DB, not in the repo, I guess to safeguard the token creator email. By the way, good job in returning an already anonymized email directly from the DB for existing tokens 👍👍

I looked into the form and I see a couple of potential issues.

xUDT form seems incomplete respectfully to its sUDT counterpart

VS

On testnet the form does not seem to allow xUDT(final_rls) as token type

Edit: Pudge explorer seems to already recognize iCKB xUDT(final_rls) on Testnet as xUDT, so maybe this is not an issue.

@Keith-CY could you provide guidance?

[Keith-CY]

Additionally, @Hanssen0 told me there is a form to submit token info in explorer. I double checked if I could add this data with my commit, but the token data seem to be stored in a DB, not in the repo, I guess to safeguard the token creator email. By the way, good job in returning an already anonymized email directly from the DB for existing tokens 👍👍

I looked into the form and I see a couple of potential issues.

xUDT form seems incomplete respectfully to its sUDT counterpart

VS

On testnet the form does not seem to allow xUDT(final_rls) as token type

Edit: Pudge explorer seems to already recognize iCKB xUDT(final_rls) on Testnet as xUDT, so maybe this is not an issue.

@Keith-CY could you provide guidance?

Hi @phroi sorry for replying late.
A complementary convention(https://talk.nervos.org/t/xudt-information-convention-rfc/8030) has been proposed along with the xUDT protocol so basic token info can be published and synced on the chain. The convention covers symbol, decimal and name, so these fields are removed from the form.

A real-world case can be found in the output#1 of transaction https://explorer.nervos.org/transaction/0x56ba1d12aac8064807c088ffbc2481d74ebca78f934e307fc129a0c66cf866fb

It was generated by https://github.com/utxostack/rgbpp-sdk/blob/develop/packages/ckb/src/utils/rgbpp.ts#L248-L255

[phroi]

Hey @Keith-CY, thank you for your complete reply!! You provided a couple of links, but I didn't see in those links an easy to use tool for adding this metadata on-chain 🤔

After a bit of digging I found utxostack/unique-cell’s generator-example, is it the correct one to use? (I'm also double checking with Cipher)

Love & Peace, Phroi

[Keith-CY]

Hey @Keith-CY, thank you for your complete reply!! You provided a couple of links, but I didn't see in those links an easy to use tool for adding this metadata on-chain 🤔

After a bit of digging I found utxostack/unique-cell’s generator-example, is it the correct one to use? (I'm also double checking with Cipher)

Love & Peace, Phroi

Yes, it does help. The xUDT info should be encoded as https://github.com/utxostack/rgbpp-sdk/blob/develop/packages/ckb/src/utils/rgbpp.ts#L248-L255, and placed at https://github.com/utxostack/unique-cell/blob/master/generator-example/src/index.ts#L55 to be deployed in a unique cell.

[phroi]

The xUDT info should be encoded as https://github.com/utxostack/rgbpp-sdk/blob/develop/packages/ckb/src/utils/rgbpp.ts#L248-L255

It feels like this other utility takes also care of the encoding: https://github.com/utxostack/unique-cell/blob/3b50fe272defec038e69bea224ab2bba8727056c/generator-example/src/lumos.ts#L60-L64

[phroi]

Both scripts have the exact same functionality, except they use different libraries, rgbpp-sdk vs Lumos.

So Unique cell represents the xUDT metadata in its cell data, my questions now are:

• How is this metadata bound to the actual xUDT token?
• Does this protocol assumes that external parties already know the binding between name and xUDT type hash?

Love & Peace, Phroi

[Keith-CY]

Both scripts have the exact same functionality, except they use different libraries, rgbpp-sdk vs Lumos.

Appreciate the verification.

So Unique cell represents the xUDT metadata in its cell data, my questions now are:

• How is this metadata bound to the actual xUDT token?

xUDT info needs to accompany the xUDT token mint/issuance transaction when being committed on-chain. Although it can be deployed multiple times, the CKB explorer will only retain the first compliant one and bind it to the xUDT token issued in the same transaction. Non-compliant xUDT info will be ignored, and an already bound xUDT info will not be updated by subsequent deployment. This can be considered an off-chain protocol.

• Does this protocol assumes that external parties already know the binding between name and xUDT type hash?

Love & Peace, Phroi

Yes, this is the only xUDT info pattern currently encouraged for adoption. We have referenced this pattern in our documentation and example code, and we hope that all projects will recognize and follow it as well.

[phroi]

xUDT info needs to accompany the xUDT token mint/issuance transaction when being committed on-chain.

In iCKB users mints iCKB at will, possibly in every transaction

[Hanssen0]

Yes, this is the only xUDT info pattern currently encouraged for adoption. We have referenced this pattern in our documentation and example code, and we hope that all projects will recognize and follow it as well.

For the situation of iCKB, things are different. Everybody can mint the token when they satisfy the requirement, and we didn't specify the metadata at the beginning.

So here are the questions:

1. Can we create the metadata after the first issuance?
2. If others create different metadata after us, will it be modified?

[phroi]

Although it can be deployed multiple times, the CKB explorer will only retain the first compliant one and bind it to the xUDT token issued in the same transaction. Non-compliant xUDT info will be ignored, and an already bound xUDT info will not be updated by subsequent deployment. This can be considered an off-chain protocol.

Let me check if this possibility is viable:

1. I can create a one off iCKB xUDT mint that binds the metadata to the iCKB xUDT
2. Later on users will not need to mint/reference this metadata cell again in their txs

@Keith-CY @Hanssen0 is this viable/correct from the xUDT Information Convention standpoint?

[Hanssen0]

is this viable/correct from the xUDT Information Convention standpoint?

I think it is.

[Keith-CY]

Although it can be deployed multiple times, the CKB explorer will only retain the first compliant one and bind it to the xUDT token issued in the same transaction. Non-compliant xUDT info will be ignored, and an already bound xUDT info will not be updated by subsequent deployment. This can be considered an off-chain protocol.

Let me check if this possibility is viable:

1. I can create a one off iCKB xUDT mint that binds the metadata to the iCKB xUDT

2. Later on users will not need to mint/reference this metadata cell again in their txs

@Keith-CY @Hanssen0 is this viable/correct from the xUDT Information Convention standpoint?

Yes, the xUDT info deployed in step 1 will be treated as the de facto one, and infos deployed in following transactions will be ignored

an already bound xUDT info will not be updated by subsequent deployment.

as mentioned at #1784 (comment)

[phroi]

I'd like to point out that nowhere in the explorer token submit form is mentioned the adoption of the xUDT Information Convention. Also the RFC is not clear, it's missing examples and any reference to code implementations.

@Keith-CY kindly provided examples and code, but until now I was missing critical information for interpreting them. Thanks to your efforts more or less now I got the gist of it, thank you both!! 🙏

Now I'll try once again to understand how to create this on-chain metadata.

Please, make this process more straight-forward for future developers who want to list their token on the explorer. Also it could be useful creating a complete RFC with all the usage assumptions, examples and code references. And update this RFC as new usage patterns emerge.

Love & Peace, Phroi

[phroi]

Deploying the Metadata On-chain

Following the examples, I created a small utility for deploying the iCKB xUDT token info. Using it I deployed the metadata on Mainnet and Testnet.

Compiling the Form

Later on, I submitted the token info with form found at the bottom of explorers:

• Mainnet went fine as you can see
• Testenet failed as you can see

Testnet form submission failed in the following way:

I guess this depends on the reference by data1 on testnet (instead of type) of xUDT, as explained in the first message.

@Keith-CY can you let me know when this bug is fixed?

Considerations

This process is unsafe. Say an attacker targeted iCKB xUDT before I committed the metadata:

• He could registered it as "Mickey Mouse" (or whatever deviant name he chooses) with the on-chain metadata convention, as anyone can mint iCKB xUDT.
• He could registered an iCKB logo with some vulgar profanities, a domain he controls and his own email with the online form.

Given all this, at this point it could make more sense to switch back to a more traditional approach, like the one pursued by CKBFansDAO/xudtlogos.

Love & Peace, Phroi

[phroi]

PS: also ckb1qzda0cr08m85hc8jlnfp3zer7xulejy... is definitely not the manager address/lock, just a very much random address used to deploy the on-chain data

[Keith-CY]

PS: also ckb1qzda0cr08m85hc8jlnfp3zer7xulejy... is definitely not the manager address/lock, just a very much random address used to deploy the on-chain data

This is a new use case, and it should be marked permissionless. But how can we differentiate it from the general xUDT issuance?

[phroi]

For starters, using which logic the explorer got that specific address?

For example, why not using:

• The real owner script of the xUDT?
• The lock that locks the on-chain xUDT metadata?

The current explorer choice seems arbitrary...

But how can we differentiate it from the general xUDT issuance?

I'm not sure which is the underlying criteria. Then again, for example if the explorer detects that multiple different addresses could reasonably be the manager address, then the explorer should refrain from giving possibly inaccurate information.

Love & Peace, Phroi

[zmcNotafraid]

For starters, using which logic the explorer got that specific address?

For example, why not using:

• The real owner script of the xUDT?
• The lock that locks the on-chain xUDT metadata?

The current explorer choice seems arbitrary...

But how can we differentiate it from the general xUDT issuance?

I'm not sure which is the underlying criteria. Then again, for example if the explorer detects that multiple different addresses could reasonably be the manager address, then the explorer should refrain from giving possibly inaccurate information.

Love & Peace, Phroi

Thanks for your advice! I will handle it.

[Keith-CY]

I'd like to point out that nowhere in the explorer token submit form is mentioned the adoption of the xUDT Information Convention. Also the RFC is not clear, it's missing examples and any reference to code implementations.

@Keith-CY kindly provided examples and code, but until now I was missing critical information for interpreting them. Thanks to your efforts more or less now I got the gist of it, thank you both!! 🙏

Now I'll try once again to understand how to create this on-chain metadata.

Please, make this process more straight-forward for future developers who want to list their token on the explorer. Also it could be useful creating a complete RFC with all the usage assumptions, examples and code references. And update this RFC as new usage patterns emerge.

Love & Peace, Phroi

@Hanssen0 do we have a complete guide for the xudt info deployment so we can lead users to it? It would be great if there is an online tool for it.

[Hanssen0]

It would be great if there is an online tool for it.

Check https://app.ckbccc.com. We provided tools for one-owner-issuance mode.
But I afraid it's impossible to have a tool for arbitrary token issuance.

Given all this, at this point it could make more sense to switch back to a more traditional approach, like the one pursued by CKBFansDAO/xudtlogos.

I have the same opinion with Phroi.

[Keith-CY]

Given all this, at this point it could make more sense to switch back to a more traditional approach, like the one pursued by CKBFansDAO/xudtlogos.

I have the same opinion with Phroi.

The traditional approach leads to project teams being less proactive or even neglectful in submitting token info.

Additionally, the traditional way requires manual review, which we cannot handle.

In contrast, an open submission system can prompt them to eagerly submit necessary info to avoid misleading information being updated.

We have provided an API (https://ckb-explorer.readme.io/reference/update-sudt-info) to allow projects or platforms to integrate it into workflows.

[Keith-CY]

Testnet form submission failed in the following way:

I guess this depends on the reference by data1 on testnet (instead of type) of xUDT, as explained in the first message.

Hi @phroi sorry for replying late.

The failure to submit complementary info for 0xd485c2271949c232e3f5d46128336c716f90bcbf3cb278696083689fbbcd407a is due to the missing necessary token info, such as symbol and decimal.

It's marked as an unknown token and is inaccessible because the transfers cannot be decoded without symbol and decimal.

It can be found in the list but cannot be visited.

[zmcNotafraid]

Deploying the Metadata On-chain

Following the examples, I created a small utility for deploying the iCKB xUDT token info. Using it I deployed the metadata on Mainnet and Testnet.

Compiling the Form

Later on, I submitted the token info with form found at the bottom of explorers:

• Mainnet went fine as you can see
• Testenet failed as you can see

Testnet form submission failed in the following way:

I guess this depends on the reference by data1 on testnet (instead of type) of xUDT, as explained in the first message.

@Keith-CY can you let me know when this bug is fixed?

Considerations

This process is unsafe. Say an attacker targeted iCKB xUDT before I committed the metadata:

• He could registered it as "Mickey Mouse" (or whatever deviant name he chooses) with the on-chain metadata convention, as anyone can mint iCKB xUDT.
• He could registered an iCKB logo with some vulgar profanities, a domain he controls and his own email with the online form.

Given all this, at this point it could make more sense to switch back to a more traditional approach, like the one pursued by CKBFansDAO/xudtlogos.

Love & Peace, Phroi

All cell with code_hash: 0x50bd8d6680b8b9cf98b73f3c08faf8b2a21914311954118ad6609be6e78a1b95 and hash_type = data1 have tagged as xudt.But the above token has no unique cell, so we can't display its info. Please check @phroi

[phroi]

All cell with code_hash: 0x50bd8d6680b8b9cf98b73f3c08faf8b2a21914311954118ad6609be6e78a1b95 and hash_type = data1 have tagged as xudt.But the above token has no unique cell, so we can't display its info.

Not sure I understand, I'm pretty sure that I deployed the appropriate unique cell on testnet: https://pudge.explorer.nervos.org/transaction/0x8b33577d05662003f206fb2886c32810866dca51821f0db31e3a05b06a7e3bf9

@zmcNotafraid @Keith-CY maybe I made a mistake, could tell me where? 🤔

[zmcNotafraid]

All cell with code_hash: 0x50bd8d6680b8b9cf98b73f3c08faf8b2a21914311954118ad6609be6e78a1b95 and hash_type = data1 have tagged as xudt.But the above token has no unique cell, so we can't display its info.

Not sure I understand, I'm pretty sure that I deployed the appropriate unique cell on testnet: https://pudge.explorer.nervos.org/transaction/0x8b33577d05662003f206fb2886c32810866dca51821f0db31e3a05b06a7e3bf9

@zmcNotafraid @Keith-CY maybe I made a mistake, could tell me where? 🤔

In our design logic, only first xudt with unique cell will parse their info and save. The first xudt apperars in tx. After discuss, we will set this xudt's info first, then refactor this logic.

[phroi]

Hey @zmcNotafraid sorry for the inconvenience, thank you!! Please, let me know when I can resubmit the form! 🙏

Love & Peace, Phroi

[phroi]

Progress

The error changed from

UDT is not found

to

UDT verification is not found

Love & Peace, Phroi

[Keith-CY]

Progress

The error changed from

UDT is not found

to

UDT verification is not found

Love & Peace, Phroi

Hi @phroi

I've submitted info for this token before, so there's a modify token info button at https://testnet.explorer.nervos.org/xudt/0xd485c2271949c232e3f5d46128336c716f90bcbf3cb278696083689fbbcd407a and the veri-code will be sent to my e-mail address

[phroi]

Thank you @Keith-CY, finally we can close this issue then 🥳

Love & Peace, Phroi