BED Page and other Token Stats bugs
Closed this issue · 7 comments
Describe the bug
Coingecko is slow to roll out the MCAP for BED, and this seems to be a common pattern with them. Alongside this, there seems to be a bug caused by this that prevents the hiding of the supply cap stat, which should not show for simple indices
Expected behavior
The BED product page should show an MCAP differently than it currently does.
By default, the value should be '--'.
If MCAP is provided by CoinGecko, instead show it.
Else, a rough estimate of MCAP should be calculated, formatted, and show (currentSupply * CG Price). This also requires a user to connect their wallet. You might have to pass this value in and add it to ProductTokenStatsProps (this will cascade to a few changes on each product page)
For supply cap: @ src/components/ProductPage/ProductTokenStats.tsx:30
Move supplyCap ? to line 39 below, following the pattern on streamingFee (ln 32)
Screenshots
Additional context
Supply data is coming from the token contract, so it will require a provider.
oh yay!
I'll dig in and see what I can do.
Thanks for the details in the post.
Supply data is coming from the token contract, so it will require a provider.
Why do we want to fallback to the Coingecko currentSupply if we've already fetched the supply from the token contract and have that available in this component (via currentSupply)? Is the supply data that comes from the token contract not reliable?
Supply data is coming from the token contract, so it will require a provider.
Why do we want to fallback to the Coingecko currentSupply if we've already fetched the supply from the token contract and have that available in this component (via
currentSupply)? Is the supply data that comes from the token contract not reliable?
The primary is the CG MCAP, not 'currentSupply'. The pricing on CG is generally reliable but the math required to calculate MCAP may not be as accurate as the actual MCAP, which is why it should be the fallback (currentSupply * CG Price).
This should eventually get overwritten with on-chain data that we don't currently have.
Right. I understand the best option is CoinGecko market cap. In the fallback scenario, are you proposing we use CoinGecko currentSupply or token contract currentSupply? #336 uses token contract currentSupply.
Right. I understand the best option is CoinGecko market cap. In the fallback scenario, are you proposing we use CoinGecko currentSupply or token contract currentSupply? #336 uses token contract currentSupply.
Token contract current supply, CoinGecko price
Token contract current supply, CoinGecko price
Thanks for clarifying and sorry for my confusion. I agree with that proposal. Sorry I split the fix for this into two separate PRs. Can we re-open until #336 or something similar is merged?
Sure thing