[Proposal] T2CR Primary Document Update

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

#21

My Proposal

Scope

This is a curated list of Ethereum blockchain tokens.

Name And Ticker

  • The name should be the most commonly used display (marketing) name to refer to the token. It does
    not necessarily need to be the canonical or official name given by project creators nor the one in
    the token contract.
  • Token and coin suffixes should be avoided, unless a name with suffix is already well established.
  • Name and ticker 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.

Symbol

  • The symbol should represent the token.
  • The symbol should be a transparent PNG (Portable Network Graphics) of at least 128x128 and at most 2500x2500 pixels. It should
    not be more than 1 Megabytes. It should be centered and take most of the space
    available in the image. It should not include the project or token name unless the
    symbol always includes it. It should be of a definition high enough such that it should
    not appear pixelated or blurry unless those are on-purpose features of the symbol.
    The logo should be fully included.

Warning

  • Contract addresses are an attack vector and should be checked carefully.
  • In case of duplicates, only the first submission should be accepted. The most
    recent submissions appear highest in the list.
#22

So which items do you want to add to the proposal? I can try and compare with the current policy, but I noticed you also changed some language so I think it would make sense to point out specific things you want to change.

#23

I rewrote it completely actually.

#24

Thing is I agree with some of the additions you made in your rewrite. I also disagree with some of the things you wrote. But I don’t know which rules other people would want to see included or rewritten. Writing it as a whole new proposal makes it hard to discuss it’s substance or entirely agree with it, especially since there seems to be no motivation for any of the changes.

For example I noticed you rewrote this rule to include only Token and coin suffixes which is something I highly disagree with.

So I guess I would not be in favor of your proposal.

#25

@martijn Can you please explain why you disagree?

#26

Well in my specific example of the suffix rule, I think there are way more suffixes that should be avoided like version numbers etc. We can’t possibly know which ones will appear so that’s why the catch-all is there. I see no reason to rewrite that.

@clesaege When do we vote in this proposal? Do we wait on the other proposals so we can batch them?

#27

@martijn If the proposal is final, you can make a “Vote” thread with the final proposal and liking to this one.

#28

If there aren’t any comments on the current proposal I’ll move this to the vote phase in 24 hours.

1 Like
#29

Well, i am still not in favor of reducing the minimum required pixel size nevertheless rest is fine to me.

KIP-17: T2CR Primary Document Proposal B
#30

This proposal has been put to a vote.

#31

I just saw proposal being put to vote: KIP-16: T²CR Primary Document Update A

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

I think it’s dangerous.

There were many migrations in the past.

New chain is the new chain.

ERC20 on Ethereum is mostly gone, trash, worthless.

Definitely not a representative example.

(I did not participate in the discussion earlier because I couldn’t care less, just like some other tokens on the agenda)

#32

I guess I do not really understand what you’re trying to say. The argument for listing all tokens, ERC20 or not, migrated or not, is that we don’t know which dApps will pull data from the TCR. Say for instance I wanted to make a trustless dApp tracking my historical token amounts, or which cryptokitties I bought/sold. Like you said, some new tokens aren’t even ERC20.

#33

I see, old delisted migrated tokens can be OK for historical reasons.

I wish it was clearer. Maybe addition of “deprecated” badge?

Otherwise - as I said - it can be dangerous.

  • Kleros has some reputation.
  • TCR has some reputation.
  • Hundred thousand ETH worth of dollars.

Someone can have a look, see something, assume “yeah it’s legit”

That’s why adding old / migrated / scam / deprecated tokens is dangerous, unless we add badges to them.

I did not participate in the discussion earlier because I couldn’t care less

The 128px or 200px does not matter to me, the whole TCR is just an experiment in governance and creating loads of cases… I think it succeeded

EDIT / UPDATE: couldn’t care less about he exact wording. One way or another it’s an experiment in governance, decision making, reaching consensus.

I joined the discussion late. I genuinely think that tokens that are migrated are no longer cool. But yeah, historical reasons. To indicate that - need to add badge. Also a bounty to add badged. Bounty for removal: Bounty discussion - rewards for removing tokens?

(stuff gets complicated)

(more important problems to solve)