Dispute #537

Court Start Date Dispute Status Current Period Time remaining End Date
Non-Technical 2021-01-02 07:19 Already Ruled Execution Already Ruled 2021-01-22 01:45
Arbitrable Creator

Unique Votes in all the rounds

Yes No Refuse to arbitrate Pending
10 4 0 2

Round 0

Yes No Refuse to arbitrate Pending
2 1 0 0
Round 0 Vote Casting Date
Yes 2021-01-07 10:30
Yes 2021-01-07 15:21
No 2021-01-07 12:07

Round 1

Yes No Refuse to arbitrate Pending
4 2 0 1
Round 1 Vote Casting Date
Yes 2021-01-08 16:56
Yes 2021-01-08 16:56
No 2021-01-08 12:48
Yes 2021-01-08 23:35
No 2021-01-11 21:33
Yes 2021-01-10 17:54

Round 2

Yes No Refuse to arbitrate Pending
11 2 0 2
Round 2 Vote Casting Date
Yes 2021-01-14 20:02
Yes 2021-01-14 20:02
Yes 2021-01-14 19:56
Yes 2021-01-17 15:47
Yes 2021-01-17 15:47
Yes 2021-01-17 15:47
Yes 2021-01-14 19:50
Yes 2021-01-14 19:50
No 2021-01-14 22:16
Yes 2021-01-15 09:15
No 2021-01-15 20:37
Yes 2021-01-16 19:49
Yes 2021-01-15 21:13


Evidences provided by Vagarish

Evidence #1:

Argument Against Removal (NO) I'm not convinced on the requester and ~a3bdcef7 reasons of - lowering the quality of Kleros and usability of the list - First, a Uniswap user uses the contract address to search for token to swap. No duplicates. Second, an Aave user knows two tokens of same name/ticker and would rather do the needful - search for contract address - than name. Evidently, previous tokens will be replaced soon as presented, and given the fact that it shares the SAME NAME with the newer version, what's the point of re-submitting it with 'v1' or 'old' and adding v2 for new ones? (as argued by Requester) when "v1 will fade away soon"? WHY REMOVE TO RESUBMIT TO REMOVE? Isn't T2CR more useful without 'unlist' days of active tokens? Isn't it more efficient to retain these until the new completely replaced the old?

Evidence #2:

Final say “Yep we probably freeze all reserve soon” – Marc ***“V1 deprecation would be up to a vote, so you’d have plenty of warning. Won’t be any time soon either way. – BigMike*** “Yes, V1 will still work. I don’t expect V1 to be down any time but this might be a topic discussed by the governance “ – Pablo Candela Won’t DM you first ****All these support my position – SOON there’s a need to remove/update version 1 listings BUT AS OF NOW, as these tokens are being actively traded and follow everything in the T2CR policy – it must remain as is. We may not agree with all the rulings in this court, but we all are bounded by the policy. We’ve had trivial disputes such as perfect centering, space taken etc that doesn’t comply with the 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." --- and these were won by ‘technicality’. Did it add credibility to the T2CR? These cases (536,537,538,539) however aren’t trivial and worth the time discussing since version upgrades are common– we can view it as a way to further define the policy or maybe there’s no need – but then nobody’s stopping anyone from proposing. I thought the last evidence is sufficient enough to close the argument, but with regard to the ‘usefulness’ of the T2CR, there have been several removals that go against the goal of ‘usefulness’. With hundreds of other actively traded tokens listed in the registry including popular ones, how can T2CR be no longer useful just because Aave’s new tokens are not listed... YET?

Evidence #3:

Argument Pro Removal (YES) Regarding cases 536, 537, 538, 539 After lurking for a long time, I have decided to share my opinion, because I recognize that this case has high polarization, inefficiency, and more funds at stake than it’s worth. The problem at hand is that one group believes during token swaps/upgrades, the earlier version of the token shouldn’t be removed. The other group believes this should be removed to benefit the quality of the T2CR and protect (third party) users of the list from confusion and potential financial loss. This has caused an opportunity for people to clash in highly polarized cases. The contra-removal group insists that the policy should be updated to include a specific procedure for how we should handle these – and doesn’t budge until it happens – actually lowering the quality of Kleros products and the usability of the list. The pro-removal group believes this action is perfectly valid and in good faith. They claim there is currently no way to upgrade a token to its new form without removing the previous one. (Simply uploading the second version first would cause a duplicate in name + ticker to exist in the T2CR – clashing with policy). I believe there is no reason to challenge the removal of the v1 aTokens, since the list would benefit from a proper upgrade to v2. The old tokens can, but should not be reuploaded with an [OLD] or “v1” addition. I say ‘can but shouldn’t" because Marc Zeller of Aave has confirmed in Telegram that the v1 tokens will become frozen and fade away soon => Only official tokens are the V2 now (see Evidence) If you are a juror who cares about the quality of Kleros and wants to win the last round of this case, I believe you should vote “Yes, remove”. Only the outcome of the last round matters, and you will receive all locked tokens from incoherent jurors. Involved policies for voting YES: ➤ Contract addresses are an attack vector and should be checked carefully. (> danger for users trading wrong asset) ➤ In case of duplicates, only the first submission should be accepted. The most recent submissions appear highest in the list. (>no way to upload duplicate names without removing v1) ➤Requests are not to be denied listing based on token creation date, token swap status (with non-ethereum chains), use case or token activity (> Listing can be denied for token swaps on Ethereum)

Evidence #4:

bulleted arguments and rebuttal attached FACT: A lot of cases had been ruled in accordance to the policy that governs this database. Even the imperfect centeredness was removed, because the requester strongly advocated for --It should be centered and take most of the space available in the image--- to the point that ‘most space available’ became ‘must take all space available’ and that zoomed logo became the norm to reject listings. Strict implementation of the policy has both good and bad results, but strict implementation shouldn’t adjust on one’s position or whenever it suits your stake. Sure it gets subjective at times, but the policy in place makes all the subjective interpretations in order in the long run. What is right for the T2CR is to comply with the policy in place, so as for this case not to become another ‘strong precedent’ for a future case where nothing in the policy has ‘black and white’ rules for. Lastly, which line in the policy supports the token removal? Let’s vote for what is right.

Evidence #5:

Vote for what is right for the T2CR Ask yourself: should we allow duplicates into the T2CR (same name, ticker, AND logo). That way, Aave REN (v1) and Aave REN (v2) will be indistuinguishable for users of the Kleros tokenlist. The only difference would then be the contract address, which would be very confusing for T2CR users. There needs to be a difference between the data of old and new/migrated tokens, so at least one of the following: 1. Different name; 2. Different ticker; 3. Different logo. In the T2CR, there are 0 instances of submissions with the same name, ticker, and logo. Couple of months ago, when all the removals of migrated tokens got challenged, note that only those were challenged, where there was a difference in name, ticker, or logo. That is because having two submissions in the T2CR with the same name, ticker, and logo, will be confusing for T2CR users, but also for Kleros tokenlist users. A difference in either the name, ticker, or logo can be seen at for instance the following tokens: 1. Augur: Ticker (REP and REPv2); 2. Aeron: Ticker (ARN and ARNX); 3. Autonio Ticker (NIO and NIOX); 4. UniCrypt: Logo; 5. Eidoo: Name and Ticker (EDO and PNT); (note that some old tokens still got removed from the T2CR, for instance REP, but that reason was because of incorrect centering of the logo, so unrelated to this case). In conclusion, we should NOT allow duplicates (same name, ticker, and logo) into the T2CR. In order to update the T2CR, we need to submit the new Aave tokens, as the old ones will be used less and less, and the new ones more and more. Someday soon the v1 tokens will be depreciated, and the v2 will be the only active Aave token. I am not saying we can't have the v1 tokens in the T2CR, they just ought to have a different name, ticker, or logo, from the new v2 tokens. We can debate about the correct naming convention we should follow in the juror chit-chat on Telegram. We need to re-submit all the v1 tokens to the T2CR, but with a different name. I would vouch for using v1 behind the name, I think that's more slick than (OLD), which aggregators seem to prefer. What is certain, however, is that the last 4 remaining Aave v1 tokens need to be removed from the T2CR, so that we can start adding the v2 tokens to the T2CR, using the correct name. Lastly, I want to react to the following fallacy: Challenger: "If not for one address that was drawn twice, results would have been different." Me: "All the Spanish guys are acting like a mob. If there is something which had an influence on all these cases, it's the fact that the Spanish community is all voting the same way, in a group."

Evidence #6:

Please see attached evidence 3 Cases 536, 537,538 are close and tied. If not for one address that was drawn twice, results would have been different. But the point being is, there’s no consensus in removal unlike the parallel case 539 where it is in agreement that version 1 Aave KNC should be retained. There’s no lies in the evidence presented as the requester was claiming. The previous submissions were due to logo, not duplication. S/he just didn’t understand. A duplicate is exactly the same, how can it be a duplicate when the token contract address is different? .And as shown in evidence 2, deprecation of version 1 tokens won’t be anytime sooner. Why would the requester insist that it has to be removed due to pending deprecation that hasn’t even been a topic for governance? Also from a previous dispute https://tokens.kleros.io/token/0xfa437de067bb335b6861c3adaf6a3075e22344594400c99008ae08f8a2 c7b55f where the requester is the challenger, his reasoning supports that there’s NO NEED TO RENAME version 2 tokens which also implies no reason to re-submit as Aave YFIv1 and Aave YFIv2 as it’s not commonly used – ➤ The name should be the most commonly used name to refer to the asset

Evidence #7:

Go to Uniswap 'suggestions' are not part of the listing policy. Kleros list in Uniswap doesn't show the full name of the token, just the tickers. Unlike Aave and Dharma list that have tags. Can you cite an exact match of Aave YFI version 1 listed as "Aave YFIv1?" etc. Can you cite a line in the policy that supports the removal? Clearly, the removal of previous version 1 tokens don't go by the T2CR rule and therefore not a basis to continue removing what's left. The challenger presented evidence as is and you should take a look at it

Evidence #8:

Remaining Aave v1 tokens need to be removed and re-submitted Let me start by saying that I am not a juror in this case, as the challenger is falsely claiming. As the old v1 tokens will be depreciated soon, the v2 tokens need to be also added to the T2CR. The v2 tokens need to use the correct name, so in this case, Aave REN (aREN). Once these last 4 v1 tokens are removed, they can re re-submitted again with a - non-duplicate - name. If I would have added the v2 token of Aave REN to the T2CR before removing the old one, the challenger would have challenged me too, but then for submitting a duplicate. He is just trying to find something to challenge me on, although I would understand if he would have challenged for duplicates. Because, we shouldn't want to have duplicates (same name, ticker, and logo) in the T2CR, as that would only cause confusion among users of the Kleros tokenlist. There needs to be a distinction between the old v1 - depreciating - tokens and the new - staying - v2 tokens. As the v2 tokens will remain, they need to use the correct names, so Aave REN in this case. The challenger is lying about the reason for the rejections of Marc's submissions, which was not, as the challenger is incorrectly saying, only because of the logo quality. All his submissions were also challenged for being duplicates, you can see that in the cases yourself. Lets keep the T2CR a usefull list of curated tokens, which users can use to trade on Uniswap, and for more. We can't allow duplicates in this list, which is also against the policy of course. Just like all the other Aave v1 tokens which were already removed, these last 4 need to be removed as well, in order to be able to add the v2 tokens to the T2CR. Lets not make this too much of a hassle, as it's certainly necessary to remove these last 4 tokens. PS. CoinGecko and CoinMarketCap are simply not up to date, as they still have the old tokens listed only. They are no valid source in this case, as they are outdated. As can be seen with other projects, they usually list the new tokens, and use (old) behind the names of the old tokens. In the case of Aave, I would suggest to use "v1" behind the names when re-submitting them to the T2CR.

Evidence #9:

Check attached full evidence It’s necessary to appeal the ruling since the requester is also a juror in the case 536. Aside from that, there is a strong evidence that these listings must remain and no need to resubmit using naming convention suggested by the requester since it’s just his OWN bias. More so, the removal is not within the T2CR policy -https://ipfs.kleros.io/ipfs/QmbqgkZoGu7jJ8nTqee4NypEhK7YVBEJJmPJbJxz8Bx8nY/t2cr-primary-doc.pdf which is what governs the database.

Evidence #10:

Removal is required to re-submit v1 tokens using another name. These v1 tokens simply need to be removed from the T2CR in order to re-submit them using "v1" behind the names. The v2 tokens can then be added using the usual name.

Evidence #11:

You got it wrong 3 reasons were enumerated to support the challenge yet you call it baseless. If you remove these tokens, how would you re-submit it then? Remember the rule, 'most commonly used name' and 'Aave YFI' is still the most commonly used name at CURRENT. If you submit version 2 tokens, how would you name it then when there's no 'commonality' from outside Aave listing yet? version 2 tokens are named the same, so far. Other version1 Aave tokens were removed because it weren't challenged to be removed, not because it was 'jurored' to be so. Marc of Aave V2 submissions were unsuccessful due to logo, not due to name nor contract address. See also attached file

Evidence #12:

Baseless challenge The v2 tokens need to be added using the correct name, so the old Aave tokens need to be removed in order to not have duplicates in the T2CR. The old ones can be re-submitted using "old" behind the token names, or something like that. All Aave tokens, except these four, have already been removed earlier. On top of that, when Marc tried to add all the new v2 tokens to the T2CR, he lost all his deposits due to them being duplicates, thus, this set a strong precedent that the old ones need to be removed, in order to add the new ones. End note: I really don't understand why you challenged all my removal requests, as these challenges are baseless.

Evidence #13:

Token challenge Three reasons to not remove this listing: 1) v2 (or V2) tokens are in ‘essentially another market” from Aave Medium post https://medium.com/aave/aave-v2-design-upgrade-818f0bd14ccf 2) v1 contract addresses are still being used – “deprecation (of v1 tokens) would be up to a vote ...which won’t be anytime soon either” – BigMike (Aave member) 3) If the requester is removing due to ‘name’, there isn’t any official change as of yet, and putting a distinction on the name by adding 1 or 2 is arbitrary at this point
Check this Case on Kleros Resolve