Revisiting T2CR Policy

Proposal
#1

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.

Untitled%20Diagram

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.

4 Likes
KIP-31: T2CR Primary Document Update
#2

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.

2 Likes
#3

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.
kleros_symbol

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
#4

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.

#5

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.

2 Likes
#6

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.

2 Likes
#7

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.

1 Like
#8

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.

#9

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

#10

Let’s put this to vote.

1 Like
#11

Before putting it to vote in snapshot, why don’t we do a few iterations of writing Policy -> Feedback -> Rewriting… until we got it more polished?
I’m severely biased against Case Law. I want Policy to be the main reference point jurors have around the dispute. The biggest problem I see in T2CR Policy is that it leaves too much space for subjectivity, and subjectivity gives jurors an excuse to fall into the trap of following Case Law to obtain consistency in midst of the chaos. Consistency is not necessarily good, why would it be a good thing for cases to be solved consistently wrong?
Specific issues to solve or to note, as noted in Telegram before:

  • Precise language. Policy must be concise as possible on things. If something can be stated objectively, it is not wasted effort: please let’s specify concrete solutions to concrete problems and depend less on weasel words such as “common sense”, “jurisprudence”, or “morals”. They are not forbidden, just less preferable. Issues that still will depend on some subjectivity are emphasized.
  • First of all, T2CR should have consistent good resolutions. 1024x1024 minimum sounds fine to me. 128x128 quality is simply too low and will cut use cases for the T2CR. PNG, and transparent background must be enforced, unless the background is pivotal to the logo, the background is dark and encloses the logo, the background is either colorful or striking, or the background is found in almost all revelant sources.
  • Logos cropped on the edges must be rejected.
  • In case of inconsistency, allow any reasonable defendable field. Example, if a token is listed differently in CMC and CoinGecko, submission can reasonably be listed with any of those names. Rationale is that it is preferable to have the data to not have it, those inconsistencies are not important, and if and when Edit is implemented, it will be fixable in the future. It’s just way too risky for submitters given current state of gas price.

Things that need to be clarified:

  • Is square resolution mandatory in logo?
  • Stance on capitalization. (I suggest same treatment, if inconsistent, accept any as valid.)

Features I’d desire for next T2CR version:

  • Edit function. Editor changes fields / replaces ipfs logo or anything editable, and after some time without successful challenges, the Edit is commited. How would edit affect the use case? Maybe punish submitters that only have small mistakes less, as their error will be easily fixable? (I’d prefer to just be merciless, really, as PNK reward is there for a reason and allowing mistakes and supporting Edits with PNK would make for perverse incentives.)
  • Challenges to submissions must state at least one clear clause that has been infringed, dispute will only go around that specific accusation and have to . This cannot be implemented in the current state of Kleros as:
    • Challengers could just say “either this is wrong, this is wrong or this is wrong”, possibly listing all possible things that could be possibly infringed, and still attacking submitter at all fronts. Maybe make it so that proving one of the accusations wrong is enough to disqualify the case?
    • More importantly, if submission was wrong and someone challenges with an invalid claim, the submission would end up having to be accepted without giving a second challenger the chance to attack it. Maybe change the smart contract to allow to multiple challenges?
  • Requesters for removal also have to state why something must not be in T2CR anymore. Ideally, as Edit function will be added, removal will be more rare.

I really typed a lot. I could attempt to write a first prototype of this Policy myself if you’d like so that you can bomb me with feedback. Let’s have this crystal clear Policy before voting. I believe this solves almost all “injustices” (it’s not unjust because it’s Kleros, more like doubtful) I’ve seen.

1 Like
#12

Thanks for taking the time to write this.

I agree that rules should be as clear as possible, leaving minimum space for subjectivity.

Requiring 1024x1024 will make more than half of the list invalid, this might be a problem. Otherwise OK.

I disagree with the rule you propose “logos should not be cropped on the edges”. In practice, sometimes you crop a bit too much and sometimes a bit too less, both of them ‘spoils’ the image almost negligibly. Let’s remember the initial objective, we want symbols that are good-looking. So we are not actually interested in pixel-level errors. So instead, I believe it’s better to evaluate images visually in a previously agreed resolution (e.g. 128x128)

I agree that we should favor requesters side on submissions, or as you said “any reasonable defendable field”.

Square resolution simplifies things, so yeah.

For capitalizations, again we should allow any reasonable defendable field. If there are multiple correct representations, accept any of them.

Edit function is I think a must-have but it requires a new contract and some rework, so we can’t do it with this proposal.

I don’t know how to force requesters of removals to state reasonings. Why not just recheck all conditions if they still met? This should do for challengers.

#13

We could have features that are not to be rejected on submission or challenged on edit. Such as:
square resolution is not enough of disqualifier to reject submission, but editing the logo to a square resolution cannot be rejected either.
I think of it as in the X’s in Karnaugh maps, values that don’t matter. Or, properties that are preferred to others but are not enough to disqualify an entry. Edit would make this possible and make submitters/challengers/funders feel less like gambling

#14

In my proposal minimal imperfections are already OK.

But if you don’t require that, for example, if there is huge vertical space in the image, when fitted into a visual container on a client’s application, the symbol inside the image will look very small.

#16

All those removal requests and challenges are showing that the policy lacks a bit of clarity.

I propose just to add:

Minor logo issues which are not visible on 10x10 cm display do not prevent admission to the list.