hirosystems / explorer

Explore transactions and accounts on the Stacks blockchain. Clone any contract and experiment in your browser with the Explorer sandbox.
https://explorer.hiro.so/
MIT License
141 stars 102 forks source link

Add number of accounts associated with asset and related data #627

Open wbnns opened 2 years ago

wbnns commented 2 years ago

Is your feature request related to a problem? Please describe. Centralized exchanges that are potentially listing Stacks assets (e.g. CityCoins, DIKO, xBTC, and others) need to be able to verify on-chain, the number of accounts associated with an asset. This is colloquially known as distribution. Assets with low distribution (low number of holders) are higher risk because this is a sign that there is not much traction with the asset, and that it is highly controlled by a very small number of holders.

In listing applications, exchanges often want to see where they can source this information on-chain. Currently on the Stacks network, this isn't possible. An exchange needs to trust that the asset has sufficient distribution. This will create headwinds as Stacks-based assets look to gain traction across centralized exchanges.

It is crucial that Stacks-based assets have many CEX listings as this is what allows liquidity to enter in to the network from not only other networks/chains, but also from the deep wells of capital associated with fiat.

Describe the solution you'd like Ability to be able to see number of holders for an asset. Example, using Wrapped Bitcoin on Ethereum: https://etherscan.io/token/0x2260fac5e5542a773aa44fbcfedf7c193bc2c599

You can clearly see number of holders.

2022-01-26-10:41:07

Bonus points if we can also see number of transfers and a pie graph of token distribution. For example, if there were 10000 holders but 1 holder controls 99% of the supply, this would make the asset very high risk to list because of the potential for there to be a rug pull. https://etherscan.io/token/tokenholderchart/0x2260fac5e5542a773aa44fbcfedf7c193bc2c599

Describe alternatives you've considered Currently, the only way to achieve this goal would be for every single asset to come up with their own way of deriving this information in a trustless way, so that a CEX can be assured that the information that is being provided is correct, verifiable on-chain. This does not seem scalable or beneficial for the growth of the network, nor for helping Stacks assets secure more listings on CEXs.

Cc: @philipdesmedt @pstan26

philiphacks commented 2 years ago

This would be an important improvement to the explorer, I agree.

saralab commented 2 years ago

cc: @andresgalante @markmhx

wileyj commented 2 years ago

Wouldn't this be a better question to ask https://github.com/hirosystems/stacks-blockchain-api ?

The data may already be there, there's just not an easy way to retrieve it currently

whoabuddy commented 2 years ago

Also curious if this could be achieved on a dashboard with https://stacksonchain.com

STX Whales: https://stacksonchain.com/addressbalance Other token whales: https://stacksonchain.com/tokenwhales

Also some further analysis on MIA: https://stacksonchain.com/dashboards/MiamiCoin-($MIA)/10

wileyj commented 2 years ago

Also curious if this could be achieved on a dashboard with https://stacksonchain.com

STX Whales: https://stacksonchain.com/addressbalance Other token whales: https://stacksonchain.com/tokenwhales

Also some further analysis on MIA: https://stacksonchain.com/dashboards/MiamiCoin-($MIA)/10

yea, it's definitely doable - but it would easier to retrieve the data if there was a dedicated endpoint in the APi i think

wbnns commented 2 years ago

Thanks you all!! :raised_hands:

rswol commented 2 years ago

We have added the API method on api.stacksdata.info (the backend of https://stacksonchain.com) that returns the supply and number of holders for all coin contracts out there:

If you need details, you can find it here: https://stacksdata.info/api.html#operation/coins

louiseivan commented 2 years ago

I would love to second @wbnns on this. I'm doing a lot of BD with exchanges and these data points are very much needed, even if we can't prioritize this on the stacksexplorer, we can do this on other data visualization tools such as Stacksonchain, stackst, stxsats and more...

diwakergupta commented 2 years ago

@saralab this is actually something best addressed within the API, then Explorer and others can take advantage of it. cc/ @zone117x @rafaelcr

markmhendrickson commented 2 years ago

@landitus Let's draft the UI needed for adding this to the explorer and provide it as input for @rafaelcr as he sets up support on the API-side (per https://github.com/hirosystems/stacks-blockchain-api/issues/1130) to minimize design discrepancies with data made available.

I'd recommend starting with the comprehensive approach as suggested by @wbnns in which we show the "number of transfers and a pie graph of token distribution" in addition to the simple accounts tally.

andresgalante commented 2 years ago

@rafaelcr Is this data on the API?

rafaelcr commented 2 years ago

@andresgalante not yet, unfortunately, but we still plan on adding an endpoint that would give this information

andresgalante commented 1 year ago

Related to https://github.com/hirosystems/explorer/issues/1088

andresgalante commented 4 months ago

@eugeniadigon Let's review this one and consider it for the new design

ginny-d commented 4 months ago

@eugeniadigon Let's review this one and consider it for the new design

Is this the new holders table mentioned yesterday?

andresgalante commented 4 months ago

@eugeniadigon there are more ideas than just the holders on FTs, for example a list of Whales, and holders for STX

BLuEScioN commented 3 months ago

I am working on this now. @ginny-d Is there anything else we want to add to the holders tab? Or perhaps we can leave the additional designs for the redesign.

ginny-d commented 3 months ago

I am working on this now. @ginny-d Is there anything else we want to add to the holders tab? Or perhaps we can leave the additional designs for the redesign.

I'll include this on the redesign scope