Token image support
Feature requested in #320
The screenshot below is an approximate rendering of the change:

Hrm I don't think we should rely on github to serve this content as it's introducing another dependency. Might need to rethink how we approach this
Hi @nick,
I had the time to look at this from the perspective of Ethereum Lists ; here's what I learned:
- There are currently about 1958 tokens listed there, but about two-thirds of them don't have any information about images. The (751) tokens that have their "logo" field populated have been compiled into this list: EthereumListsTokenCollection.xlsx
- Between the tokens in the list above and the 6064 token images hosted using TrustWallet's github repository, I found some in common; such tokens can be identified by the field Logo Alt Source.
Reading about this a little more, I see that Metamask favors EIP-747's idea that users should be allowed to add token information (to their wallet) themselves; this may include URLs to the token image, and it seems like the argument here is that storing this information on the client side (with the provider being blind to it) is a step in the direction of (more) decentralization. From EIP-747, I also learned that list-maintainers like Metamask may face political pressure from (certain) asset creators to list "otherwise unknown" assets on such platforms.
Update [14th May, 2021]:
The README on Metamask's "contract metadata" repository recommends that asset creators move away from using the list. Despite that however, the list seems to be on a steady state of growth - with about 60 additions in the last three months.
@nick if we implemented an approach in which DShop would try to serve the image from, say Github first, failing which, it would try a 'fallback' URL, would we have mitigated the issue you mentioned?
I'm checking in on this proposal since it's spent a few weeks without an update. @nick, when possible, could you please respond to the question above?
@nick, Your concern about the centralization of token images is a shared one (see EIP 2569). Given the uncertainty of the timeline in which we may see that proposal come to fruition, however, I'm advocating for us to implement the approach I previously mentioned.
@shahthepro Would you please review the commits that follow this comment, and recommend changes if any?
Best, Rajath