Include a Token details page

[blockscout]

Include a Token details page

[acravenho]

Yes, the transaction has should like to the transaction details page.

[igorffs]

@acravenho I seems that we could merge this task with #50. wdyt?

[igorffs]

@acravenho I seems that we could merge this task with #50. wdyt?

Sorry, I got it wrong. This is actually a new page (just like this one https://etherscan.io/token/0x0e8d6b471e332f140e7d9dbb99e5e3822f728da6), it makes sense to keep it in a single issue. 👍

[igorffs]

@acravenho would it be correct to assume that:

1. We're going to have only the TokenTransfer tab in our first version.
2. We'll leave the "Price" section out of the first version given the decision of not using the price in USD or Eth of a token, for now.

[acravenho]

LGTM 👍

[gfreh]

@acravenho two new questions that have just popped up:

1. In case we have more than one Token Transfer in the same call to the Token contract, should they be isolated in that list?
2. What links should redirect the Contributor to the Token page? At Etherscan, not all links redirect to there, and we still have the Contract Address details page.

[acravenho]

1. Since this is the token page, every token transfer should have its own box very similar to how etherscan operates.
2. Clicking a link on the address page token dropdown should bring the user to this page filtered by the user.
   Clicking on the token name from the transactions list tab should bring you to this page as well filtered by the user. There doesn't look like there is a link on mockups for this but it should be included.

[gfreh]

1. Ok!
2. Regarding this one:
   2.1. Do you believe the filtering feature is required for the first release or can we hold it off? There is no field for that in the mockups (there is a search field but I believe that is a different thing 🤔 )
   2.2. I believe there is another place we might want to have a link to the token page: in the transaction details page, where the token symbol is shown (as described by #386). Is it correct?

[gfreh]

Hey, @amandasposito! I've been testing this issue and found some small issues I've listed below:

• There seems to be some problem with the timestamp label. For my contract, all transfers are labeled with the 21 hours ago label, although they've taken place many days ago.
• Not sure if this is related to the issue above, but the sorting seems to be wrong for my contract address too.
• In the top area, I believe we should show the token name instead of Token Details (not sure what to display when the token has no name 🤔)
• The Total Supply seems not to be considering the decimals for the token. For my contract again, the total supply shown was 1,000,000,000,000,000,000,000,000 FREH, but the correct value should be 1,000,000. The other 18 zeros are decimal places (not actually in the acceptance criteria... I believe we discovered that after this issue was started 😕). This is only required for ERC20 tokens that have the decimals info indexed.
• Total supply is misspelled in the top area (there is a missing p).
• The transactions hash should be a link to the transaction details page.

ps.: I'll use this comment to add any issue I find.

[acravenho]

It could be an issue with the last updated timestamp instead of block validated timestamp.

[gfreh]

@acravenho Not sure if we've discussed it before, but for this page, should the transaction hash be a link to the transaction details page?

[gfreh]

@acravenho All the fixes are working fine!

We have just two extra questions:

• We noticed that the burn address is being considered when calculating the number of addresses that were involved in token transfers for that token. We've noticed that Etherscan doesn't count it. Should we remove it from the count? I'm not sure what is the use case for this info, if it's required to be precise or if users just want to see the order of magnitude.
• We noticed that there is one single case in Sokol where the Token's Total Supply was stored as null. Is it something we should expect in the explorer app or should that be handled by the indexer?

[acravenho]

@gfreh

1. When 0x0000000000000000000000000000000000000000 is the sender of tokens, they are being minted and when 0x0000000000000000000000000000000000000000 is the receiver of tokens they are being burned. We should stay in line with what Etherscan is doing and count them as transfers.

2. We should be handling this in explorer app because it is an optional value for ERC721 and other token EIPs.

[gfreh]

As we've just discussed on a call:

1. We've misunderstood that address count in this issue. Instead of the count of addresses that have been involved in token transfers, it should display the count of addresses that have balance > 0 for that token. Since we don't have a way to do that right now (it's being developed by #50 and #514), we'll have it fixed with the creation of the Holders tab.
2. In that case, for now, we're going to hide the entire Total Supply block. In the future, we might be able to retrieve the total supply by summing the balances of all holders.