Display asset allocation

Keith-CY commented 5 months ago

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

Holder Addresses: CKB holders + BTC holders:

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 commented 5 months ago

@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 commented 5 months ago

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

Daryl-L commented 5 months ago

Chinese translation

Sven-TBD commented 5 months ago

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 commented 5 months ago

Need a API data returned as follow

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

Keith-CY commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

https://github.com/Magickbase/ckb-explorer-frontend/pull/382

rabbitz commented 5 months ago

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]

Categorize and aggregate UDT holders' addresses in udt_accounts by lock script code_hash.
Refresh udt_statistics data when udt_accounts data changes.

rabbitz commented 5 months ago

udt info add holder_allocation pr: https://github.com/nervosnetwork/ckb-explorer/pull/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 commented 5 months ago

~~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 commented 5 months ago

https://github.com/Magickbase/ckb-explorer-frontend/pull/383

rabbitz commented 5 months ago

Readme: https://ckb-explorer.readme.io/reference/udt-holder-allocation PR: https://github.com/nervosnetwork/ckb-explorer/pull/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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

Magickbase / ckb-explorer-public-issues