Component: Token Icon (Wallet + Bridge)

[heycorwin]

Problem Summary

The wallet and bridge teams are in need of a standard for how to display token icons. With the addition of icon in the token contract metadata, we now have an option for token contracts to support an icon. With its addition, we need to consider the following:

1. A "default" or "empty state" icon, that is displayed when no icon is provided by the contract.
2. An icon "standard" to inform how token icons should be displayed in the context of a UI
3. A way to indicated modified tokens (eg wrapped or bridged) so that they may be distinguishable from unmodified tokens (eg vanilla NEAR or an unmodified NEP141)

This discussion is related to:

• Display of Fungible Token Balances
• Display of bridged tokens within the bridge UI

Solution

The following guideline is an attempt to outline a simple but flexible system to display token icons in the context of an interface. My suggestion is that we create a component that takes the icon provided by the contract (if provided), and displays it in various states depending on if and how the token has been modified.

cc @chadoh @djsatok @vgrichina @Patrick1904

[stefanopepe]

To cut time to release a token, is it possible to also use unicode to generate the icon? https://unicode-table.com/en/blocks/
This would instantly enable a very large set of characters, with the cost of a few bytes (up to 12)

[alexauroradev]

Looks nice, but what about some services that rounds the icons, like https://coinmarketcap.com/ ? Prepended modifier may not be shown correctly.

[heycorwin]

Alright so @djsatok made a great point that third party exchanges are going to have limitations of their own for how they choose to display token icons. It's in our best interest to avoid any scenarios where any visual elements from our approach might get clipped. The standard for displaying token icons in 3rd party exchanges and wallets currently is a 24px ellipse. It's safe to assume that anything outside of this is at risk of not being displayed properly.

To account for this, I think we'll be pretty limited in how we choose to differentiate between an unmodified and modified token. I propose that a modified token receive the following treatments:

• A single color stroke "wrapping" the token. The color of the stroke is determined by the primary brand color of the chain where the token currently resides. (eg Ethereum lavender)
• A CSS filter to desaturate the base icon. In this way, when a token is "bridged" or "wrapped", its color is extracted, and is "returned" if it returns across the bridge.

.modified-token {
    border: 2px solid var(--primary-brand-color);
    filter: grayscale(100%);
}

While in isolation, this approach isn't as descriptive as the initial proposal, we'll need to rely on the token symbol (eg wNEAR or nDAI) to provide additional context about how the token has been modified.

Here is what this looks like in practice:

[alexauroradev]

@corwinharrell I believe the color overlay is much better than grayscale. Let's try this out. 👍

[vgrichina]

@corwinharrell @djsatok maybe we should add a tiny ETH diamond (or 🌈 ) as a badge to refer to bridged tokens?

exchanges can follow similar pattern or honestly do whatever, I don't think there is strict adherence to which icons to use

[vgrichina]

Also note that around 5–10% of people in US are colorblind. So relying on color coding only generally not good for accessibility. Which might be ok if we duplicate info in text, etc – just smth to keep in mind.

[chadoh]

exchanges can follow similar pattern or honestly do whatever, I don't think there is strict adherence to which icons to use

By the end of Q2 I'd like to see us include these icons in the on-chain metadata to be used by all apps that display these tokens

[heycorwin]

Also note that around 5–10% of people in US are colorblind. So relying on color coding only generally not good for accessibility. Which might be ok if we duplicate info in text, etc – just smth to keep in mind.

@vgrichina beating me at my own game! Yes thank you for this reminder. We should definitely be making sure that any implementation is accessible. I'll revisit with an accessibility check to ensure colorblind users are able to distinguish between them. The trouble with adding additional graphic elements (eg ETH diamond or the "w" as shown in the first exploration), is that it will be virtually illegible at 24px x 24px, or will be cutoff by any exchanges cropping token icons to fit the standard 24px format.