Revisiting T2CR Policy

Dear decentralized justice enthusiasts,

The aim of the registry is to curate legit tokens with proper names and symbols. We need symbols to use them as icons, not high resolution, pixel-perfect images. But with the current rules of T2CR, many submissions got rejected because of tiny symbol imperfections. And this is not the aim of the registry.

That’s why I propose this ruleset for T2CR. The main change is relaxing symbol requirements.

Awaiting your input.

➤ All submissions must be tokens with smart contracts deployed on the Ethereum

(ETH) mainnet.

➤ The name should be the most commonly used name to refer to the asset. It does

not necessarily need to be the official name given by project creators nor the one in

the token contract. Suffixes such as, but not limited to: “Token”, “Coin” should generally be avoided, unless a name with suffix is already well established. Names should be treated like brand names (spelling wise). This means that the

correct spelling is dictated by the project owners, unless consensus forms around a

different spelling.

➤ Contract addresses are an attack vector and should be checked carefully.

➤ In case of duplicates, only the first submission should be accepted.

➤ Requests are not to be denied listing based on token creation date, token swap

status (with non-ethereum chains), use case or token activity.

➤ Symbols should be fully included. They should be a transparent PNG of at least 128x128px and it should not be more than 1MB. They should be centered and be in a minimum square transparent frame so that the symbol barely fits inside. They should not include the project or token name unless the symbol always includes it.

Symbols are intended to be used as icons (at a maximum size of 128x128pxs), not meant to be displayed in high resolutions. They should be of a definition high enough such that image should not appear pixelated or blurry when displayed in 128x128pxs unless those are on-purpose features of the symbol or unless its the best image available.


Examples for Potential Disputes

  • The symbol is looking sharp without any visible problems when displayed in icon size (128x128pxs) but there are some visual problems in the original resolution. - Accept Submission
  • The symbol is looking centered when displayed in icon size (128x128pxs) but it’s not perfectly centered when displayed in original resolution. - Accept Submission
  • The symbol looks like fitting in the minimum square frame when displayed in icon size (128x128pxs) but when displayed in original resolution there is a tiny space left. - Accept Submission

To summarize, unless visual problems are visible in icon size, disregard them.


I think we should strive to keep the T2CR the highest quality list out there and this means making sure information including logo are well standardized and of high quality.

Also keep in mind that relaxing logo requirements would decrease the rejection rate (thus challenger revenues) and to keep the list secure, it would need to be compensated by an increase of the deposit.

I think it is better to keep the list high quality and submission deposits low.

We could however clarify what “centered” and “most of the space” mean taking care not to make the policy more confusing.


We should clearly define if we want the T2CR to have “high-quality logos” or “high-quality symbols”. The giant gap between 128px and 2500px seems to make it unclear for jurors what the purpose of the images in the T2CR is.

Below, you can see a high-quality symbol of 128px. It is sharp, but when you zoom in the slightest, edges will begon to blur - thus making it unfit for use as a logo.

Since the T2CR is mainly used to list assets (with their appropriate token symbols), I suggest we guide the users towards “high-quality symbols”. This way, potential partners like Coingecko, CMC, Uniswap, and others can more easily adopt our list as a back-end.

If we want to be a list for high-quality project logos, instead of token symbols, we should create a list with SVG’s, since .PNG use is quickly fading as a standard for logos.

1 Like

Although we’ve discussed the MinImage size being 128px, I think I’d hardcode that at upload level to something higher regardless of the slight extra weight on the T2CR.

For me, 512px would be a minimum to help stave off challenges similar to what Lorens described.

This proposal assumes a specific use case for the T2CR, namely only using the images as icons. While it may be true that currently this is the most relevant usecase for the T2CR I’m not sure we should narrow the scope of the T2CR.

Instead maybe create a new (child) TCR that links icons to the submissions. This way the requirements for that TCR can also be really strict (like only 128x128 allowed). Only argument against that is that it requires submitting 400 icons to a new TCR, but that comes also with more cases.


I agree with Martijn here, there are many use cases possible for the T2CR. Just because there is only 1 use case as this moment, does not mean that there will be more in the future. What if anyone wants to use the T2CR to build a crypto information website, displaying the logos at a larger size than 128x128 pixels. We should not restrict the T2CR to 1 use case, this will reduce the possibilities of the T2CR.

This reminds me of the time that Ethfinex was the only use case for the T2CR. Someone argued that some tokens should not be added to the T2CR, because they would never be listed on Ethfinex (for instance, because of a token swap from Ethereum to its own native blockchain). A precedent was set when the jury ruled to still list those tokens, as T2CR use cases would reach beyond Ethfinex in the future. The same is happening now. The T2CR will reach beyond Tokenlists for Uniswap, thus we shouldn’t narrow down it’s scope, and keeping the T2CR as high-quality as possible.


But it’s already restricted to that. Minimum resolution is 128x128 so client applications can’t assume more than that, even if some of the images are bigger than 500x500.

Actually, increasing resolution requirement doesn’t change that. You can always find few bad pixels when you view the image in full resolution. But those few bad pixels become invisible when image is sized down.

What would you vote if this proposal was put in vote? If you would vote no, please comment including why and with what change you would vote yes.

  • Yes
  • No

0 voters