[Proposal] T2CR Primary Document Update

Proposal
#1

—DRAFT—

Current policy: https://ipfs.kleros.io/ipfs/QmQGDs9jvWJxRAmCVtTXy3EPQeMj2dPMtLnr5WrWqYUYy6/t2cr-primary-document.pdf

I propose we update the current primary document of the T2CR as follows:

Add:

  • “Requests are not to be denied listing based on token creation date, token swap status (with non-ethereum chains), usecase or token activity”
    …
    I’ve seen some cases lately that try to determine the relevance of a listing in the T2CR. Some argue some requests should be denied because the token requested is simply too old, not used anymore, swapped to another chain etc. These entries however might still hold value in the T2CR for historical dapps or other research/explorer dapps. We need a policy rule that makes this clear.

  • “All submissions must be tokens with smart contracts deployed on the Ethereum (ETH) mainnet.”
    …
    Although reasonably implied it wouldn’t hurt to explicitly state all tokens should be deployed on the Ethereum mainnet. In case of a chain split we follow the chain that inherits the ETH ticker from the community.

Modify:

  • “The token symbol should be a transparent PNG of at least 200x200 px.”
    to say
    “The token symbol should be a transparent PNG of at least 128x128px and at most 2500x2500px”
    …
    The motivation for this rule change is simple: there are currently 78 entries in the T2CR that violate the 200x200px rule. Changing the minimum requirements to 128x128px would lower that number to 17 violations (which would still need to be removed). Most 128x128px symbols look fine on screen.
    Furthermore I propose a limit on the maximum dimensions of a symbol. There are already cases like noku that load slow from my end, and I consider myself to have quite a good internet connection. When considering the projected use cases for the T2CR I don’t feel like a higher quality is desired/necessary. (implementing a maximum of 2500x2500 will put 6 entries in violation if accepted)

Remove:

  • “Project names and tickers should be carefully checked.”
    …
    This rule is vague and moreover contradicts: “The name should be the most commonly used name […]” by implying the T2CR requires a project name. To prevent confusion we should remove this rule.

Please comment on what you think should be added, modified or removed. This draft is meant to be updated frequently so to take in all the feedback, so please do leave some feedback :smiley:

—DRAFT—

2 Likes
#2

This looks great.

#3

The one @0xferit proposing: https://gist.github.com/ferittuncer/2656b0a326b71781c9184666d84a51be

1 Like
#4

Add

“Requests are not to be denied listing based on token creation date, token swap status (with non-ethereum chains), usecase or token activity”

Maybe there should be a warning about not inventing rules in general. Just apply the rules written and that’s it.

Modify

“The token symbol should be a transparent PNG of at least 128x128px and at most 2500x2500px”

Good idea about symbol pixel sizes, I’m adding it to my proposal as well.

Remove

“Project names and tickers should be carefully checked.”

Yeah, I removed this as well.

#5

I think it’s better to be explicit about which cases should not be denied. You’re right that under the current policy they shouldn’t be denied either, but in practice this still happens. “Just apply the rules written and that’s it.” doesn’t work well. Jurors tend to vote with emotion if there isn’t a clear directive in the policy.

We should probably merge our proposals to have one proposal to vote on. So if you have any more suggestions I would love to hear it.

#6

IMO most confusions are caused by a lack of clear definition on what the T2CR is supposed to list.

By now for me a token is either a currency/point (ERC20 style) or an NFT (ERC720 style) smart contract built on Ethereum with a real project/purpose behind it, but don’t expect newcomers to be aware of it. There really isn’t any definition of what a token is in the introduction post.

Easy to imagine that people just assume that if it is an ERC20 token then it is okay, if it is not widely known as an active ERC20 then it is not okay. Case in point: EOS despite being one of the most popular coin, which previously has an ERC20 token has never been submitted.

2 Likes
#7

I understand the need to cap png logo max size, but i am not sure for lowering the minimum size to 128x128:
It may lead to more nitpicking disputes around quality.

#8

I think most quality disputes have been about random pixels or cut off logos. I don’t think lowering these requirements will be a problem. Take a look at the Basic Attention Token submission. If find that this 128x128 logo is clearly good enough.

If we don’t lower the pixel requirements we need to cut almost 24% of TCR listings.

#9

I agree on the BAT one, but it is one example only.

As for updating the TCR listing to fit latest enforced criteria/rules, i tend to believe it’s rather a matter of incentive to remove tokens and submit them again in the correct way (but i understand the goal of reducing the work of course).

#10

I can give you 61 more if you want. It’s mostly early submission, but they all look fine really.

Yeah it’s not ideal. I’d rather push the maximum pixel limit all the way down to like 512x512px as I believe higher quality is really unnecessary, but that would also mean the removal of a lot of submission which isn’t great :’).

#11

Do you think it’s a good idea to include something like:

“All submissions must be tokens with smart contracts deployed on the Ethereum (ETH) mainnet.”

I think leaving what a token exactly is purposely vague is a good thing. Eventually people will only list entries in the T2CR if a dapp is going to use that listing. It’s impossible to pursue a complete list of tokens on the Ethereum blockchain anyway ;p.

#12

Looks good to me :+1::+1::+1:

1 Like
#13

But then, we need to write an exclude rule for everything. And when we don’t, people will come with an excuse “but there was no excluding rule for it”.

Instead, we should write what should be included in the list, with inclusive rules, and consider any submission fulfill all requirements valid and the rest not valid.

#14

No, we just write rules for things that are vague. Nothing wrong with that. I get that it’s not pretty, but what you’re describing only works in an ideal scenario.

I think general court policy says something about not being able to lose based on non-existent policy, or atleast it should. So people can always refer to that.

#15

Well currently, there is a warning in the other direction

(General court policy)
Jurors should attempt to interpret disputes according to the “spirit of the dispute” unless the arbitrable contract or the policies of the subcourt state otherwise.

That’s to avoid cases where jurors make a literal application of a rule, despite everyone agreeing that it was not what the rule was meant for. Or where jurors would not sanction something which was obviously bad, because there is not rule forbidding it explicitly.

During Doges On Trial pilot, some people submitted pornographic pictures of doges which were rejected by the jurors, despite no rule explicitly rejecting porn doges. So it seems the community has been more inclined to the “spirit of the dispute”, rather than strict literal application of rules.

#16

I really agree with making the logo requirements less strict. We must always keep in mind what is the purpose of the rule.

We want to have nice logos so we have a nice looking Dapp with aesthetic consistency, but this should not end in arguing for hours over “is this quality good enough”?

I heard from lots of people who want to submit tokens but don’t do it because they are afraid that the submission will be challenged over a technicality about the image or so.

By easing this friction, I think the amount of submissions will be higher and also the usefulness of the TCR.

#17

Would it be useful to include a “minimum passable” logo example in the primary document? Serves as a reference point for new jurors and submitters, since some points will always be subjective, ex:

…It should be of a definition high enough such that it should not appear pixelated or blurry unless…

#18

Not sure this is something for in the primary document. Furthermore I think pixelation and blurriness should be evaluated on a case to case basis.

#19

I see a contradiction point between the will of lowering quality rules strictness and the will of keeping a solid good looking listing.
There is probably a balance to find but, imo, if quality requirements are to be too low, it won’t be good as we would probably witness a lot more low quality logo submissions.

#20

The curated list of tokens aim to represent tokens as they are. If the official website represents token with a low quality image, curated list can do that way as well, I think.