Display asset allocation

[Keith-CY]

Any assets on CKB can be allocated on CKB or BTC due to the RGB++ protocol, so there's a confusion about the distribution.

E.g. the seal token https://explorer.nervos.org/xudt/0x178fb47b597a56d48b549226aff59f750b4784250c7f40f781b64ef090a8a0a7

It shows 40906 holders on CKB

It consists of CKB holders and CKB Cells of BTC holders. It's correct from the perspective of CKB. But it's confusing for users since the real holders should be CKB holders and BTC holders

Here I would suggest showing the following data

1. Holder Addresses: CKB holders + BTC holders:
2. Holder Allocation(tooltip or something):

   protocol	count
   secp256k1	cell count of secp256k1 lock
   omnilock	... of omnilock
   joyid	... of joyid lock
   rgb++	... of rgb++ lock
   lock hash	... of unknown lock hash

[Sven-TBD]

@Kirl70 Could you add a pop up for the address acount

PRD : https://vs0cjf.axshare.com/?id=8k4520&g=14&p=_697_update_a_new_way_for_showing_holders

cc @rabbitz

[Kirl70]

Design Draft:
https://www.figma.com/design/6XNoimRDbFTTNm016rbIdU/Magickbase?node-id=39141-49780&t=P4fGDu7Ra10gUDUX-1

[Daryl-L]

Chinese translation

[Sven-TBD]

en	zh
Holder Allocation	地址分布
There are {{CKBHolderAmount}} CKB Holders and {{BTCHolderAmount}} BTC holders of current asset.	当前地址有{{CKBHolderAmount}} CKB地址持有人及{{BTCHolderAmount}} BTC 地址持有人
secp256k1	secp256k1
omnilock	omnilock
joyid	joyid
rgb++	rgb++
lock hash	lock hash

[Daryl-L]

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

[Keith-CY]

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

I would suggest an API as

{
  "holders": {
    "btc": "number",
    "ckb": {
      "secp256k1": "number",
      "omnilock": "number",
      "others": "number"
    }
}

The total count of ckb holders can be calculated in the frontend

[Daryl-L]

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

I would suggest an API as

{
  "holders": {
    "btc": "number",
    "ckb": {
      "secp256k1": "number",
      "omnilock": "number",
      "others": "number"
    }
}

The total count of ckb holders can be calculated in the frontend

The lock hashs should be returned an array, for convenience to add new lock
And I think it is both ok whether to return the ckb holder amount or to calculate from the lock hashes, and I would prefer the data returned from the backend

{
  ckbHolderAmount: 1000, // optional
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

[Daryl-L]

Magickbase/ckb-explorer-frontend#382

[rabbitz]

1. Create table udt_statistics:

Columns:

• udt_id
• contract_id: Contract associated with the lock_script code_hash of the address owning the UDT asset
• ckb_addresses_count: Number of CKB addresses held by the contract
• bitcoin_addresses_count: Number of Bitcoin addresses held by the contract

Index:

• Unique index on [udt_id, contract_id]

2. Categorize and aggregate UDT holders' addresses in udt_accounts by lock script code_hash.

3. Refresh udt_statistics data when udt_accounts data changes.

[rabbitz]

udt info add holder_allocation pr: nervosnetwork/ckb-explorer#1978

[staging] e.g.

https://ckb-explorer-staging.magickbase.vercel.app/xudt/0x78e21efcf107e7886eadeadecd1a01cfb88f1e5617f4438685db55b3a540d202

{
    "data": {
        "id": "3355130",
        "type": "udt",
        "attributes": {
            "symbol": "UBBQT",
            "full_name": "Unique BBQ TEST",
            "icon_file": null,
            "published": true,
            "description": null,
            "type_hash": "0x78e21efcf107e7886eadeadecd1a01cfb88f1e5617f4438685db55b3a540d202",
            "type_script": {
                "args": "0x30d3fbec9ceba691770d57c6d06bdb98cf0f82bef0ca6e87687a118d6ce1e7b7",
                "code_hash": "0x25c29dc317811a6f6f3985a7a9ebc4838bd388d19d0feeecf0bcd60f6c0975bb",
                "hash_type": "type"
            },
            "issuer_address": "ckt1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqga7eurwgfm534kew3092y28sp3mwlqpqcptqy24",
            "udt_type": "xudt",
            "operator_website": null,
            "email": null,
            "total_amount": "99008765590000000",
            "addresses_count": "405",
            "holder_allocation": {
                "ckb_holders_count": "540",
                "btc_holders_count": "98"
            },
            "decimal": "8",
            "h24_ckb_transactions_count": "9",
            "created_at": "1711928465602",
            "xudt_tags": [
                "rgbpp-compatible",
                "layer-2-asset",
                "supply-unlimited"
            ]
        }
    }
}

[Keith-CY]

I will propose a simple implementation before the API is all ready

---

PR from @Daryl-L is ready: https://github.com/Magickbase/ckb-explorer-frontend/pull/382/files

[Daryl-L]

Magickbase/ckb-explorer-frontend#383

[rabbitz]

Readme: https://ckb-explorer.readme.io/reference/udt-holder-allocation
PR: nervosnetwork/ckb-explorer#1991

Request

curl --location --request GET 'https://ckb-explorer-api-staging.magickbase.com/api/v1/udts/0xe6396293287fefb9f26d98eb0318fe80890908f0849226ad0c8cab2d62f1e351/holder_allocation' \
--header 'Accept: application/vnd.api+json' \
--header 'User-Agent: Apifox/1.0.0 (https://apifox.com)' \
--header 'Content-Type: application/vnd.api+json' \
--header 'Host: ckb-explorer-api-staging.magickbase.com' \
--header 'Connection: keep-alive' \
--header 'Cookie: AWSALB=bv4bxoRUlPUZdhJKtM3Ljsyfgl8OjV+Ap8aEykOkf0J7Y/mV91GU8LL2Om5OtDHrqomuPcx4D0TXI7sWJHf0UIt2vqKs9JPY+6AxEn+avIXiy9uviR2ntW3P/8/0; AWSALBCORS=bv4bxoRUlPUZdhJKtM3Ljsyfgl8OjV+Ap8aEykOkf0J7Y/mV91GU8LL2Om5OtDHrqomuPcx4D0TXI7sWJHf0UIt2vqKs9JPY+6AxEn+avIXiy9uviR2ntW3P/8/0'

Response

• ckb_holder_count is the sum of holder_count in lock_hashes.

{
    "btc_holder_count": 0,
    "lock_hashes": [
        {
            "name": null, # contract name
            "code_hash": "0x75ac906998b047602967d7f89505bb9817e405b89f868111ded51d672f9e260e", # contract code hash
            "holder_count": 8
        },
        {
            "name": "secp256k1_blake160",
            "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8",
            "holder_count": 1
        },
        {
            "name": null,
            "code_hash": "0xb8d8fbfd27e538ea0f74e16cccf576740d830daa1202045bcf82c96f1ed48ee7",
            "holder_count": 17
        },
        {
            "name": "JoyID",
            "code_hash": "0xd23761b364210735c19c60561d213fb3beae2fd6172743719eff6920e020baac",
            "holder_count": 120
        },
        {
            "name": "omni_lock v2",
            "code_hash": "0xf329effd1c475a2978453c8600e1eaf0bc2087ee093c3ee64cc96ec6847752cb",
            "holder_count": 901
        }
    ]
}

@Daryl-L @Keith-CY The interface has been updated on staging, and the UDT data has been refreshed.

[FrederLu]

The data on Staging is normal.
https://ckb-explorer-frontend-in-magickbase-repo-4h1oyyizz-magickbase.vercel.app/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5

https://pudge.explorer.nervos.org/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5

BTC data on Testnet shows abnormalities.

[rabbitz]

The data on Staging is normal. https://ckb-explorer-frontend-in-magickbase-repo-4h1oyyizz-magickbase.vercel.app/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5

https://pudge.explorer.nervos.org/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5 BTC data on Testnet shows abnormalities.

This may be because the previous data has not been refreshed, and there has been no recent udt transaction, so the data update will not be triggered. After the manual update, the data is consistent.

[FrederLu]

This may be because the previous data has not been refreshed, and there has been no recent udt transaction, so the data update will not be triggered. After the manual update, the data is consistent.

Verified.