https://ipfs.kleros.io/ipfs/QmP722Ynu5shWiyZU8TFgH88PLtL8tH9QmPjcDh6Y8ThAE
Changes:
(-) 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.
(-) 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.
(+) - The name should be the most commonly used display (marketing) name to refer to the token. The ticker should be the most widely used one. None of them necessarily need to be the canonical or official name/ticker given by project creators nor the one in
the token contract. In case of a tie, favor the name and ticker from the official sources.
Justification: First and second rule is contradicting: In first rule it says: “It does not necessarily need to be the official name …” but in the second: “… This means that the correct spelling dictated by the project owners …”. I removed this contradiction and said they should be the most common ones and not necessarily the official ones. I also added, favor official sources to avoid neck and neck debates, where both claims seem correct.
(-) Suffixes such as, but not limited to: “Token”, “Coin” should generally be avoided,
unless a name with suffix is already well established.
(+) Token and coin suffixes should be omitted, unless, the suffixed name is well established and when you omit the suffix, the project name and token name becomes the same. In case of a tie, favor the name without a token and coin suffix.
Justification: We are curating tokens in the list and %99.9 times we will have problem with token and coin suffixes, I prefer to well define a rule instead of loosely defining it to create potential trivial debates in future. Also, I added an extra rule to avoid debates like “IDEX” vs “IDEX token” or “ZB” vs “ZB token”. Lastly I added a rule to favor names without suffix in case of a tie to avoid neck and neck debates, where both claims seem correct.
(-) The token symbol should be a transparent PNG of at least 200x200 px. It should
not weight more than 1MB. 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.
(-) Attached Logos should be PNG format with a transparent background.
(+) 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.
Justification: I rephrased these two rules. Also, I clearly indicated that the symbol should represent the token. In cases where projects and tokens have different symbols, this matters. Finally, I lowered the required minimum resolution to 128x128 as it’s enough for a symbol and there are a lot of tokens with symbols below 200x200 resolution.
(-) Project names and tickers should be carefully checked.
Justification: Deleted as it’s redundant.
(-) In case of duplicates, only the first submission should be accepted. The most
recent submissions appear highest in the list.
(+) In case of duplicates, if the token is already registered with another submission, reject subsequent submissions for the same token.
Justification: Same rule, more clear. The previous rule may be debated when there are two simulatenous submissions racing each other. I made clear that this rule is for cases when there is a submission which has registered status already for the same token.
Voting
This proposal requires a simple majority.
Voting can be done here.