Dispute #536

Court Start Date Dispute Status Current Period Time remaining End Date
Non-Technical 2021-01-02 07:12 Already Ruled Execution Already Ruled 2021-01-26 15:14
Arbitrable Creator
Tokens 0x5dce...025c

Unique Votes in all the rounds

Yes No Refuse to arbitrate Pending
16 7 0 0

Round 0

Yes No Refuse to arbitrate Pending
3 0 0 0
Round 0 Vote Casting Date
0x4a2c5a0af8b29cd5fd8eb1d02a83150a3ee10488 Yes 2021-01-05 12:57
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-07 15:23
0xd9d37ade3131fd7ac02e80883fbc0c4570b65e47 Yes 2021-01-07 17:57

Round 1

Yes No Refuse to arbitrate Pending
4 3 0 0
Round 1 Vote Casting Date
0x6f5f5d2a7d9b6ea028b8efceab2ff221a27ab6e3 Yes 2021-01-11 23:16
0x945674691713d1e8d02832d20777b933036e49e1 Yes 2021-01-11 09:43
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-08 11:46
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-08 11:46
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a No 2021-01-08 12:36
0xf035561dce033ded865e15e69db06cffc88d9213 No 2021-01-11 11:35
0xf83f70e148bc6ff29bb627f97eb691f30268c7e3 No 2021-01-10 18:19

Round 2

Yes No Refuse to arbitrate Pending
7 8 0 0
Round 2 Vote Casting Date
0x50c3ead85c299d7c2b78ee9646880d0ffed9d2a8 No 2021-01-14 20:12
0x8dca414776ae8478c5e2141ecdd21f716a9010d9 Yes 2021-01-14 19:54
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-16 17:36
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-16 17:36
0x9bfda54a453f503d487f2f32554de73f03e24853 Yes 2021-01-16 14:19
0x9bfda54a453f503d487f2f32554de73f03e24853 Yes 2021-01-16 14:19
0x9f1175193abcc1060e3c7f940484d033a3bdcef7 Yes 2021-01-14 19:49
0x9f1175193abcc1060e3c7f940484d033a3bdcef7 Yes 2021-01-14 19:49
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a No 2021-01-14 18:54
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a No 2021-01-14 18:54
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a No 2021-01-14 18:54
0xa64a17a51482f96a794c08fa3e61bb6260eeb2ca No 2021-01-14 20:02
0xc261717ecfc14943595570ed34d11aa85c9d2364 No 2021-01-14 20:07
0xe4230c0e536b704f82cb435876b4907cb1f66c13 No 2021-01-14 19:53
0xe4230c0e536b704f82cb435876b4907cb1f66c13 No 2021-01-14 19:53

Round 3

Yes No Refuse to arbitrate Pending
31 0 0 0
Round 3 Vote Casting Date
0x12fa14c9f49cee96c4f6ba8c7497f7ef825cae37 Yes 2021-01-21 01:04
0x4a9a2f31e2009045950df5aab36950609de93c78 Yes 2021-01-21 20:49
0x6f5f5d2a7d9b6ea028b8efceab2ff221a27ab6e3 Yes 2021-01-20 22:21
0x6f5f5d2a7d9b6ea028b8efceab2ff221a27ab6e3 Yes 2021-01-20 22:21
0x6f5f5d2a7d9b6ea028b8efceab2ff221a27ab6e3 Yes 2021-01-20 22:21
0x6f5f5d2a7d9b6ea028b8efceab2ff221a27ab6e3 Yes 2021-01-20 22:21
0x837c5f6d0e57be3af742570111852a96f2998394 Yes 2021-01-22 10:26
0x837c5f6d0e57be3af742570111852a96f2998394 Yes 2021-01-22 10:26
0x945674691713d1e8d02832d20777b933036e49e1 Yes 2021-01-19 21:10
0x945674691713d1e8d02832d20777b933036e49e1 Yes 2021-01-19 21:10
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-19 14:45
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-19 14:45
0x982f5698febb2b8d1b9a560228abbceafbb11568 Yes 2021-01-19 14:45
0x9bfda54a453f503d487f2f32554de73f03e24853 Yes 2021-01-22 06:08
0x9bfda54a453f503d487f2f32554de73f03e24853 Yes 2021-01-22 06:08
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a Yes 2021-01-23 01:14
0xa07f5ffd166ca3ff7567e96a0430f1496cdb470a Yes 2021-01-23 01:14
0xa64a17a51482f96a794c08fa3e61bb6260eeb2ca Yes 2021-01-23 02:59
0xaead6593710bf28bf4848b24f4ed1f130773d7e6 Yes 2021-01-22 10:29
0xaead6593710bf28bf4848b24f4ed1f130773d7e6 Yes 2021-01-22 10:29
0xb7e69971897d02972dacf002a0c22ff12e510fbc Yes 2021-01-20 10:37
0xc78eed7b6ef98ff11dd7f557c67ae0abdd69227b Yes 2021-01-20 01:58
0xe4230c0e536b704f82cb435876b4907cb1f66c13 Yes 2021-01-22 21:26
0xe4230c0e536b704f82cb435876b4907cb1f66c13 Yes 2021-01-22 21:26
0xe4230c0e536b704f82cb435876b4907cb1f66c13 Yes 2021-01-22 21:26
0xe4230c0e536b704f82cb435876b4907cb1f66c13 Yes 2021-01-22 21:26
0xe61cd5aa5ff1971f965865c4c57c77e15d258477 Yes 2021-01-20 04:29
0xf035561dce033ded865e15e69db06cffc88d9213 Yes 2021-01-19 21:44
0xf035561dce033ded865e15e69db06cffc88d9213 Yes 2021-01-19 21:44
0xf035561dce033ded865e15e69db06cffc88d9213 Yes 2021-01-19 21:44
0xf865067a5b9672f11af8514440d9111afd05d040 Yes 2021-01-22 17:21

Evidences

Evidences provided by Vagarish

Evidence #1:

At least one of violations in the policy merits rejection of a request. If we willingly permit deviation from the policy, then we’d have chaos in court as anything becomes permissible. Submitting evidence to support or disprove a claim becomes purposeless. To the ladies and gentlemen of the jury, kindly see the attached list of violations of the removal request in a better reading format.

Evidence #2:

“The Challenger cries out in pain as he strikes you.” I am still waiting for you to refute the substance of my arguments. Emotional appeals and condescension are not refutations.

Evidence #3:

Highfalutin words only served your ego and exposes your ignorance over a simple policy that you can't respect. Blame the creators, sure. Isn't that always the simplest way to get support? - complain. highlight the flaws, ignore what works. The results doesn't make you right. And oh, don't forget to propose in Aave and Kleros governance. Most of all don't forget courtesy.

Evidence #4:

I will take the challenger's obvious deflection and passive-aggressive sarcasm as a sign he is conceding the overall argument All those words and yet you really had nothing else to say. By all means feel free to refute my arguments if you can: I'm happy to debate any of the points I raised. I don't take such things personally. Since you bothered to post all that, I will at least do you the courtesy of answering each statement of yours seriously even though I suspect that was hardly your intention. First of all, if you are going to forgo the use of logical discourse and instead rely on smarmy retorts to sway onlookers towards your side, then at the very least make sure your comment isn’t composed primarily of run-on sentences and borderline indecipherable syntax. Brevity is the soul of wit after all. “Above contention implies or more so demeans Aave’s lack of vision to make a unique distinction to its token…” I did not imply it – I outright said it because it’s the truth, and I will unapologetically say it again once more for the record: Aave got cocky and/or sloppy, didn’t do their due diligence, and are now finding themselves “hoisted by their own petard” as the old saying goes. “that discreetly leads users to its detriment…” An inevitable consequence for the T2CR userbase if the Aave/anti-removal side has their way. Intentional or not this is what you are asking for. Either address the point and demonstrate how such an outcome is not detrimental or quit dismissing the concerns that have been raised. “Kleros T2CR team for not creating an all-encompassing policy” I mentioned the Kleros team because their policy as written is inherently susceptible to abuse by submitters like Aave as there is an (albeit frivolous) opening for litigants to use the ambiguity in the current language to weasel their way around meeting the T2CR submission requirements. Rather than endlessly litigating situations like this, I simply suggested the Kleros team might find it useful to update and clarify the language in the T2CR guidelines so that there is a more defined set of criteria for everyone to use for assessing whether a submission is a duplicate. A more clearly defined policy from the outset would have been to everyone’s benefit here, would it not? In any case, what the Kleros team decides to do with the T2CR going forward changes nothing as far as this case is concerned. In other words, you are still wrong. “including but not limited to cultural interpretation, language barrier and evolution, imagination, social injustice…” Even in context the rest of your statement makes little to no sense, but I will try my best with it anyway. It sounds like you are not only misrepresenting what I said but also adding claims I never made in the first place. Hardly fair to me, but then again you don’t even do a very good job of knocking down the strawman you created so it’s difficult for me to really get upset about it. Cultural Interpretation? Are you from a different culture? If you are claiming ignorance on these grounds well, that sounds like that would have been a great thing to double-check before submitting. Otherwise this is irrelevant. Language barrier? Do you not speak English? Gee that sounds like it would have been a great thing to double-check before submitting. Imagination? Of all the non sequiturs you could have desperately pulled out of thin air, this one might be the least helpful to bolstering your argument. It doesn’t take much imagination to envision the original intent of the T2CR “no duplicates” rule and it takes even less imagination to see how different tokens with identical names, logos, and tickers would cause problems for unaware users. Social Injustice? If you are still failing to understand the ethical considerations of the position you are advocating for then there is not much else I can do. I mean…I can explain it to you, but I can’t understand it for you. ”AND its court results based purely on luck and anomalous statistical selection thereby treating NO jurors without capabilities to think for themselves.” I brought up the juror selection anomalies in Case 539 because as I expected, when your side ran out of actual arguments to employ you then tried to cite the voting results in Case 539 as evidence that your side has already been judged by multiple rounds of jurors to be “right” and anyone looking for guidance on how others would vote could rely on that so as not to vote incoherently. All I did was demonstrate that claim was utter BS. I don’t see how you can accuse me of treating jurors like mindless sheep when I am the one that implored them to consider the facts – not the merely previous votes by fellow jurors - and think for themselves. Your side however tried to induce them into voting a certain way by implying that they would be risking their staked PNK if they voted contrary to previous rounds. Arguably, the only person here who is guilty of disregarding the individual agency of the jurors is you (or whoever it was on your side that cited Case 539). “You are a highborn of supreme intelligence” Your words not mine (not that I would ever describe myself in such a way). All in all, a rather petty way to round out your closing arguments if you ask me, but I am not the manners police so feel free to express yourself. “that can interpret policies beneath and beyond their plain meaning” This is more or less what your side (the anti-removal side that is) was hinging their entire strategy on across all four cases. The pro-removal side was demanding a narrower and less tortured reading of the rule in question. More projection on your part. “I am but a simple man…” I will take you at your word on that. “that follows and respects policies.” Debatable.

Evidence #5:

Here Above contention implies or more so demeans Aave’s lack of vision to make a unique distinction to its token that discreetly leads users to its detriment, and Kleros T2CR team for not creating an all-encompassing policy, including but not limited to cultural interpretation, language barrier and evolution, imagination, social injustice AND its court results based purely on luck and anomalous statistical selection thereby treating NO jurors without capabilities to think for themselves. You are a highborn of supreme intelligence that can interpret policies beneath and beyond their plain meaning. I am but a simple man that follows and respects policies.

Evidence #6:

Long overdue repsonse to challenger (last for now) For some reason I cannot attach documents to my posts so I am forced to copy the entirety of the text into the Description box. My apologies for the lengthiness as well as the lack of formatting, but I strongly feel it is necessary for everyone to read. This is my last evidence submission below (for now). Earlier in the case the challenger/anti-removal side claimed that Case 539 - due to being similar in terms of the issues at hand - provided guidance for jurors to vote in this case because there was overwhelming "consensus" due to the eventual vote totals. The following analysis will thoroughly dismantle this claim of theirs as little more than a red herring that is irrelevant to the strength of either side and not at all predicative of which side will prevail in later voting rounds: More evidence for Case 539 (post-appeal) As stated earlier by multiple parties and observers, Case 539 is not only similar to Cases 536, 537, 538, but they are all identical regarding the particular issue being debated. There is no divergence and the same arguments proving the validity of the pro-removal side equally apply for in all four cases. It has been argued here and elsewhere that Case 539 is different because there has been “consensus” reached by jurors in the previous rounds of voting that the challenge to the removal quest is the correct verdict, but a quick analysis of the vote record easily disproves this and highlights why an appeal to the previous rulings in favor of the challenger is in fact the incorrect one. Simply put, the “consensus” decisions by jurors in previous rounds is due almost entirely to lucky juror selection and vote weighing – perfectly valid under the rules of Kleros, but statistically anomalous and not indicative of a truly objective sample of independent jurors. All of the following information can easily be viewed by anyone here in the KlerosBoard Dispute Scanner and I encourage everyone to check and see for yourselves: (For the sake of brevity, I’m abbreviating the referenced juror ID’s to the last several digits/letters) For example, in Round 0 there were three juror ‘votes’, but only two different jurors: ‘5E47’ and ‘F66c13’. Due to court stake weighing, F66c13 got to vote twice in the same round while 5E47 got one vote. 5E47 voted “Yes” to the removal request while F66c13 voted ‘no’ and since he got to vote ‘no’ twice 5E47 and the ‘yes’ side lost the round two votes to one. In a normal jury this would result in a deadlock or more likely, the tiebreaking third juror vote would belong to an independent third individual, but this was not the case here. It gets worse. In the next round (Round 1), F66c13 got picked again while 5E47 did not. Once again, F66c13 got to re-cast his “no” vote in an appeal round that was essentially contesting the fairness of the outcome of the previous round, which was entirely decided by him and him alone. Now those claiming “consensus” will cite this round for proof arguing that all the other jurors voted unanimously with F66c13 and that fact should put the matter to rest. As we will see it is not that simple. Likely figuring that the true margin between yes/no votes when taking into account a larger sample size of the jury pool is probably much closer than the second round would indicate (as proven by the first round, the Requester appeals again and opts for a larger 15-vote jury pool in the next round. But once again, court stake weighting ends up burning him a third time. In the next round (Round 2 as labeled in the Kleros Dispute Scanner), four of the seven jurors from the previous round are also picked again to re-cast the same vote on the same case: F6613 (now his third consecutive time voting), 470a, EEB2Ca, and D2364. Furthermore, whereas the previous round had all seven jurors one cast one ‘vote’ each, in Round 3 the randomized weighing skews the voting even worse: F66c13 (who had two votes in Round 0 and had one vote in Round 1) now has three votes in Round 2. EEB2Ca (who did not vote in Round 0 and had one vote in Round 1) now has two votes in Round 2. D2364 (who did not vote in Round 0 and had one vote in Round 1) now has two votes in Round 2. 470a (who did not vote in Round 0 and had one vote in Round 1), once again has one vote in Round 2. Predictably, these four jurors cast the same vote (‘no’) as they did in the previous rounds. Assuming they are rational and would obviously never vote against themselves and lose staked PNK, anyone can predict with a reasonable degree of certainty beforehand how they are going to vote so they are incentivized to vote the same way as before. Altogether these four jurors controlled eight of the fifteen jury votes allocated for Round 2. By themselves, these four jurors constituted the majority of the votes for the latest appeal round and thus (much like in Round 0), the outcome was a foregone conclusion: Arguably, drawing other jurors for the latest appeal round wasn’t even necessary from a decision standpoint as the outcome was never in going to be in doubt. Even if every remaining (first time voting on this case) juror picked specifically for Round 2 unanimously voted the opposite way, it simply wouldn’t have mattered anyway because from the outset it was mathematically impossible for the Requester to win given the same jurors were basically being asked to review their own verdict. Given the economic incentives in place for these jurors to uphold their previous ruling, this represents an obvious conflict of interest in the Kleros appeals process. While no one is arguing that this unfortunate anomaly is against the rules or intentional, it certainly is cosmically unfair and arguably defeats the original purpose of having an appeals process – which is to ensure that appellants can have a new set of jurors (i.e. a fresh set of eyes/ears/perspectives) re-examine the facts of the case and either overturn an unfair verdict or return the original verdict with a higher degree of confidence and consensus. Any juror in the current appeal round who might be lending credence to the fallacious argument that jurors should consider that all previous votes went in favor of the challenger should review this publicly-available information and consider for themselves the following: 1) Are the results of the previous voting rounds necessarily indicative of a proper jury (i.e. one vote per unique juror) would vote if they had the opportunity? 2) Given the obvious skews in voter weights and subsequent conflicts of interest, are the results of the previous voting rounds indicative of how a new set of jurors (hopefully more balanced) would vote given the same presented evidence/arguments? 3) Are you willing to risk your PNK/stake betting that this pool of jurors that you currently sit in will be as biased and as poorly sampled as the previous three in a row? All I am asking of jurors in this latest round is for them to simply base his/her vote on the facts of the case and arguments presented herein and only those facts/arguments. For those who may be nervous and tempted to vote to uphold previous rulings based on the false appearance of consensus, it would be wise to disregard those results since they are indicative of absolutely nothing other than statistical noise – certainly not of the strength of the individual case arguments and certainly not how another jury is likely to vote afterward. Any claim to the contrary is a fallacious attempt on their part to bluff/scare you into voting a certain way rather than articulating an actual defense of their position based on the facts of the case.

Evidence #7:

Long overdue response to challenger (post 2 of ?) Below is a copy of the justification a juror provided for his vote to remove the token in Case 538 - which definitely applies in this case as they are fundamentally identical situations. "I sincerely hope the Kleros team is paying attention and sees this because I believe the crux of the matter being disputed in this case is largely derived from a glaring ambiguity in the official T2CR Token Curated List Policies. This is also an example of previous case law being unhelpful for providing a firm precedent or even basic guidance as similar cases have feature coherent rulings that are inherently contradictory. The T2CR policies state that no 'duplicates' are to be accepted and yet it does not go on to explain in detail the following criteria which may be helpful in ascertaining whether a token submission qualifies: Does the term 'duplicate', in essence, refer to a separate repeat instance of the same token being submitted? (obviously such an example would qualify under the term). Or does the definition of 'duplicate' also include different tokens that share 'duplicate' (i.e. identical) names/tickers/logos/etc.? Under the former definition, one could argue that the submission should not be removed as it is obviously a distinct token (version) with a unique contract address. Under the latter definition however, it could easily be argued that due to sharing the same ticker name and logo that for the purposes of being listed in the database that it is a duplicate and that this violates the spirit of the "no duplicates" policy in the document outlining the T2CR rules. There is also no clarification as to which set of criteria (contract address vs. naming conventions/logo) is to take precedence in determining whether a submission is a duplicate in the event that a token meets one set of criteria, but fails to meet another, as is clearly the situation here. Frankly, the fact that the original submitter behind both the Aave v1 and v2 tokens opted to use the same naming conventions and logo between what were obviously two different tokens irks me because this whole dispute could have been avoided by simply not reusing the same nomenclature for both versions. Given that part of the submitted evidence on behalf of are statements from Marc Zeller indicating that 1) the two tokens/versions are intended to be distinct from each other and 2) in the near future, updated naming conventions for each version of the token clarifying this clear distinction are not only to be expected, but actually are likely to be a necessity. Taking this statement at face value it would seem that the original submitter of the v1 and v2 Aave ENJ token is obviously aware of the possible confusion that could be caused by having two separate tokens (with different contract addresses) share the same ticker, logo, and name, but simply doesn't care because he is relying on a very narrow interpretation of the T2CR requirements to argue that because they are not actually duplicate tokens in practice, every other piece of required information describing the two tokens may be duplicative between the two. If this were the case, then why bother having strict requirements for the names, logos, and tickers of submitted tokens to begin with? Per his own words, the submitter is aware of the inherently duplicative nature of the aforementioned details, and yet is pretending to play dumb and not understanding the obvious potential for confusion by focusing exclusively on the fact that at the moment the contract addresses (and only the addresses mind you) between the two tokens are different as sufficient proof they are not duplicates as far as the T2CR is concerned; all while conveniently pretending as if the other variables simply don't exist or don't matter. If a unique contract address was the only piece of identifying information required for determining whether a submission is a duplicate, then surely the T2CR policies would have said so in more specificity would they not? Considering that no such language exists in the T2CR Guidelines, one should not assume that there is a reasonable basis for interpreting the requirements in such a manner. By the same logic, we can also infer that since token name, ticker, and logo are specifically referenced in the context of submission requirements and since past cases have used these factors to judge whether token submissions are duplicative, we cannot simply disregard them now even if a particular novel reading of the established rules makes a plausible argument that they don't matter and never did matter as far as the true definition of "duplicate" is concerned. Furthermore, however flawed or incomplete the T2CR's language may be when examined with stricter scrutiny, the overall "spirit of the law" in having such submission requirements in the first place (to prevent duplicates), is to ultimately serve the end user's and/or community's best interests by ensuring minimal confusion and accuracy of information regarding the tokens are that are ultimately allowed into the registry. Reinterpreting the guidelines in such a way that grants token submitters excessive leeway to submit different tokens with otherwise identical nomenclature and visual appearance (especially when doing so could easily cause confusion and avoidable user errors) arguably inverts the original objective of the T2CR policy so that it is primarily serving token creators first and consumers/the wider public a distant second. The T2CR does not -and should not - operate primarily to benefit token submitters at the inevitable detriment of end users. Especially when the entire issue could have been mitigated by the token submitter/developer themselves if they had simply taken the time and effort to properly differentiate between their multiple tokens at the beforehand and given them unique indentifying qualities before trying to submit them to the registry. The fact of the matter is that the token creators painted themselves into a corner by reusing the same name, ticker, and logo for both versions. And, rather than go back and properly differentiate them before proper resubmission, they opted to submit what they had "as-is" and try their luck anyway by claiming that the obviously duplicative aspects between tokens are not actually duplicative (and thus not disqualifying) because those aspects don't really matter anyway. Such reasoning on the part of the submitter (and by extension the challenger arguing on their behalf): 1) clearly runs contrary to the logic implied by the language in the T2CR submission rules, as well as spirit of the rules themselves 2) requires a significant and unjustifiable reinterpretation of the submission rules as they are commonly understood 3) disregards prior case rulings that have upheld using the all aforementioned criteria for determining whether or not a submission is a "duplicate" For these reasons, I am thus obligated to vote "Yes, Remove the token from the registry" "

Evidence #8:

Long overdue response to challenger's side (part 1 of ?) This first post (of perhaps several) is in response to the Challenger’s most recent comments: I have been following all four Aave token cases (536, 537, 538, and 539) as well as your challenges to the token removal requests from the very beginning. You can wave your money around and arrogantly demean and threaten people all you want, but that does not make your claims any more legitimate or believable. Plenty of jurors and third parties across all four cases have articulated why your position is fundamentally flawed and borderline dishonest and provided much more comprehensive counterarguments than you have to demonstrate support for their side. Rather than address those counter-arguments point by point and refute them (because you can’t), you casually and hubristically ignore them altogether and instead copy/paste the same comments over and over again hoping that enough people here are not engaged enough to notice what you are trying to pull. The “evidences” that you have submitted on your own behalf not only do not sufficiently prove what you are ultimately trying to claim, but upon close examination actually undermine the very claims you are trying to make. Anybody who takes the time and effort to carefully cross-reference and examine all the submitted evidence will see that your entire position relies on poor reasoning, selfishness, and a deliberate disregard for common sense. I will post more refutations to previous comments soon, but in the meantime I encourage all jurors to read the lengthy justification statements previous jurors on the pro-removal side have provided for their votes in Cases 537, 538, and 539. There have been attempts to enter those arguments into the evidence record for prior to voting for everyone to consider but thus far, such efforts have been stymied by the limitations of the Kleros court system interface. In any case, I have copied these arguments (which quite thoroughly destroy the comparatively shallow points made the anti-removal side) and attached them to this comment so that if others are unable to view them in court.kleros.io, they can download the file and read them for themselves. Line by line response to the post “Argument Against Removal (NO)” "First, a Uniswap user uses the contract address to search for the token to swap" Arguably false, as anyone who opens up the Uniswap app can see that the search menu states "Search name or paste address" Considering that the name (and not the specific contract address) is first and foremost what people will likely use when searching for the token (as it is shorter, easier to remember, and more publicly known hence the reason for having names for contract addresses in the first place), two different addresses with the same name/ticker is both duplicative and confusing. The presumption that Uniswap users automatically "know" what to do is a silly and unjustifiable stretch of the imagination. How would an Aave user automatically know which contract address is the one they are supposedly looking for? Where do they find this information if not in the registries and apps (like T2CR) where these tokens are listed? This is akin to expecting users who are not as intimately familiar with these projects as the developers are to be able to either read minds or do burdensome levels of research and verification before utilizing token registries which of course, negates the point of having curated registries in the first place. "Evidently, previous token will be replaced as soon as presented," This statement is directly contradicted by the screenshot of the statements of BigMike and Pablo Candela (already submitted into evidence), which indicates both tokens will be active alongside each other for an indeterminate amount of time. Thus, one is not merely replacing the other outright: there will be TWO tokens listed for people to see. How would having them appear in the lists with identical names/tickers/logos NOT duplicative and therefore potentially confusing for people who don't know which one is which? "and given the fact that it shares the SAME NAME with the newer version" As I will explain in further detail below, this is a completely irrelevant consideration. "what's the point of resubmitting it with 'v1' or 'old' and adding v2 for new ones....when v1 will fade away soon?" As proven earlier, according to the team behind the tokens v1 will NOT be "fading away soon." The point of resubmitting with different names is to avoid duplicate token listings so that users are not tricked into accidentally buying incorrect or illiquid assets. A possible scenario which is acknowledged by the screenshot of the text conversation between Marc Zeller and Santiago Koki (already submitted into evidence). Avoiding such calamity for users is the entire point of having a "no duplicates" rule for the T2CR to begin with. "WHY REMOVE TO RESUBMIT TO REMOVE" Because this is the only way to ensure you are following the submission rules of the T2CR while maintaining the existing nomenclature of the tokens given by the token developers. If they had been given different names/logos/tickers to reflect the fact that they are in fact different, this wouldn't even be an issue "Isn't T2CR more useful without "unlist" days of active tokens?" Useful for whom? Token creators who got themselves in a jam and now don't want to do the extra work required to make sure their tokens meet the submission standards? It's certainly not more useful for the end users of the registry who would be at increased risk for being swindled due to duplicate and confusing token listings. This statement of your shows an alarming and almost reckless disregard for the people who would ostensibly be buying your products. Unlisted tokens can always be relisted, but customers who are scammed due to misleading information cannot get their money back. "Isn't it more efficient to retain these until the new completely replaced the old?" Re-read your own submitted evidence and answer me this: are they two completely different valid token assets or is one totally replacing the other and taking its place? Your side has played dumb and claimed both at the same time to try and worm around the fact that each position ultimately fails the requirements for inclusion into the T2CR in its own way. You are trying to argue each angle in a vacuum hoping no one else notices, but I do. Pick one position and stick with it because you can't have it both ways. Response to the post “bulleted arguments and rebuttal attached” You asked the question “Lastly, which line in the policy supports the token removal?”: I know you meant for this to be a rhetorical question, but the actual correct answer to the question “which line in the policy supports the token removal?” can be found in Bulletpoint #6 the official T2CR policy document where it states “In the case of duplicates, only the first submission should be accepted.” The two token versions are identical in all relevant aspects other than contract address, thus arguably making them duplicates – which would then necessitate removal under the policy line stated above. The Challenger also cites previous cases where tokens were rejected due to (allegedly) relatively minor incongruities in the visual format of token logos as a basis for not wanting to create bad precedents based entirely around arguing over increasingly granular technicalities. Aside from the ironic fact that the challenger is essentially employing the same sort of flawed reasoning he is deriding here to advocate for his own position, these cases are irrelevant to the current issue at hand because those cases revolved around token logo compliance in accordance with the specified formatting rules in the T2CR policy (in other words, comparing the submission itself against the policy). This case however is not focused on that – it is different and much more abstract. Cases 536, 537, 538, and 539 are about comparing a submission against another submission and then subsequently determining whether that comparison sufficiently violates the “no duplicates” policy in the T2CR guidelines. I believe there is no argument to be made that it does not, because the token submitter and those on the anti-removal side have already conceded that the name, logo, and ticker ARE duplicative of an earlier submission (the version 1 token), but that it really shouldn’t matter because if you examine closely enough, one can see that the contract addresses are in fact different. In summary, the previous rulings in cases do not apply here since they were in essence about completely different issues. Furthermore, the main argument of original submitter of the version 2 tokens, as well as those in the anti-removal camp, is just a thinly veiled attempt at sympathy rather than an argument that is based on anything substantive. Reading between the lines and paraphrasing, I am seeing a lot of this on the part of the anti-removal side: “We’re just following the rules as they’re written! The proper and commonly used names happen to be the same!” “The guidelines state no duplicates, but we can’t help that our version 1 and version 2 tokens (by admission two completely different tokens with unique addresses) are identical in every other aspect! Yes, it is potentially confusing, and we admit that, but if you made us follow the rules like everybody else our token wouldn’t be eligible! It’s not fair to us! We might even have to remove and re-submit our old tokens! Think of all the extra work might have to do to make sure consumers aren’t hoodwinked!” Spare me. Never mind the fact that their own conversations (submitted by their own side as evidence) contradict the notion that they have no idea why there would be now be controversy over the name and appearance of both token versions as they are currently labeled. As stated earlier, they are instead pretending to be oblivious and/or innocently dumb about what the dispute is inherently about and choosing to blame the challengers and the authors of the T2CR guidelines for what is in reality the token submitter’s own failure to do their due diligence and properly differentiate their obviously different tokens in accordance with the T2CR policies. Policies I might add were published in the public domain well beforehand and thus any claim to ignorance on the matter defies credulity. One could make the argument that the T2CR guidelines should be revised and clarified in the aftermath of this case so submitters have better idea of what constitutes a duplicate submission, but to argue that the submitters of the token are being held to an retroactively arbitrary and unfair interpretation of the “no duplicates” policy is quite frankly a bit insulting to everyone else’s intelligence; and taking such a claim at face value requires one to suspend disbelief and assume that Marc Zeller and his associates did not in fact believe what they were telling other people about the ongoing plans for both token versions at the time they were saying it. (These conversations have been submitted into evidence for cases 536, 537, 538, and 539 and can be viewed by everybody participating in the case. I encourage everyone here to do so and see the contradictions for themselves). It is not the fault of the T2CR policies, nor is it the fault of those on the pro-removal side that the developers/submitters foolishly chose identical common-use names, tickers, and logos for both token versions when 1) they knew they were not the same tokens, as evidenced by the unique contract addresses 2) would be used concurrently and never at any point be the same until the version 1 was eventually phased out and 3) would in fact necessitate further differentiation in name/logo/ticker in due time - which is largely what they pro-removal side in all of these cases is using as a (quite reasonable) basis for arguing why the two tokens/versions should appear differently in the registry to begin with. Phrased another way: it is not necessarily a failure of the T2CR guidelines that in order to comply properly with the “no duplicates” policy as it is written, the Version 2 token would have had to have been submitted with the commonly used name/logo/ticker which also happens to be the commonly used name/logo/ticker of another (and apparently entirely separate) token that was previously submitted and accepted. This is underlying basis for the sympathy angle the token submitters and anti-removal party is angling for (as if to imply that the submitter’s hands were unfortunately tied in the matter), but it doesn’t stand up to basic scrutiny. While on its surface, this may seem like an unfair catch-22 situation for the token submitters, in actuality it is not and such an argument on the part of the anti-removal party is (in my opinion) entirely disingenuous. I will explain further: The “no duplicates” policy has a clear intention and while perhaps not exhaustively specific, it is nevertheless clear enough that anyone with common sense and basic reading comprehension can understand it and tailor their token submissions accordingly to comply. If your tokens are, by your own design and implementation, going to be in violation of the stated T2CR policy from the very beginning; then simply put that is YOUR problem not the T2CR’s. No one is forcing you to submit your tokens, no one is changing the rules/standards after the fact, and no one is preventing your from asking pertinent questions of the Kleros T2CR team and getting confirmation of the policy’s nuances before you spend the time and money submitting them for evaluation. You may not like it. It may have been an honest mistake or oversight. You may think it is unfair. You may even think it highlights an obvious ambiguity in the T2CR guidelines that needs to be addressed (I for one agree that it does), but the bottom line is this entire clown show could have been avoided if those behind the original token submission planned their own projects and implementation schedules better. Now, instead of owning up to their error and re-doing things properly, they are hoping to convince enough people here to twist their own understanding of the definition of the word “duplicate” so that they may not only escape the negative consequences of their poor decision-making, but actually profit from it – regardless of the obvious negative effects this could have on the quality of the T2CR registry and the consumers who rely on it for accurate information. A sane and rational person would vote for removal of the token, as a vote to allow the token would forever enshrine the right of token creators going forward to recklessly create and submit tokens with haphazard, confusing, and even borderline deceptive nomenclature while still being in compliance with the T2CR policies. The result would mean more unnecessary risk and uncertainty being taken on by the end users who essentially will no longer be able to rely on the T2CR to vouch for the legitimacy of tokens (or information regarding the tokens) since users would be forced to consult multiple other sources to be reasonably sure of what they are seeing/buying. A vote to allow the token to remain constitutes a clear lack of enforcement on this matter and would signal to the entire community the T2CR guidelines and submission standards are a joke and are not intended to be taken seriously. Anything other than a vote to remove the tokens in question would ultimately cripple the T2CR’s legitimacy and usefulness as a registry. The risks to the people who use the registry in good faith far outweighs the immediate economic considerations of the token creators/submitters, who are in this entirely avoidable situation largely due to their own poor choices and lack of forward thinking. A vote to remove the token is only a temporary inconvenience to them and does not in any way prevent them from making the proper adjustments to their tokens and resubmitting them for future inclusion to the registry. A vote for inclusion, however, forever hurts the people/community that uses the T2CR and who have an enormous stake in the outcome of this case despite bearing no responsibility for the sequence of events that led us here.

Evidence #9:

Requester, Funders and Yes jurors, why another round? It’s clear from previous arguments that Requester doesn’t have a solid ground to remove these tokens. Evidence 1 https://ipfs.kleros.io/ipfs/QmYV3m79K9YEYAmcLnLgP4ng6jhb7voqQL1TEfnSgY9JDF/aave-evidence.pdf Evidence 2 https://ipfs.kleros.io/ipfs/QmW8ZSMQqhs8hYzuwLJy4jE5x5cVvmWVch6kr5Vcr94dG7/aave-evidence-2.pdf Evidence 3 https://ipfs.kleros.io/ipfs/QmRt5o3NRkRu774TCLvpWvR3GpGpXNt1z7y9xRS1dW4RtH/aave-evidence-3.pdf The only solid reason I see is the underlying incentive involved - not the usability nor credibility of T2CR you said you want to achieve. You can neither rebut the counter-arguments presented nor explain your position strongly and consistently. Accept the evidences and move on.

Evidence #10:

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 #11:

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 #12:

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 (> Listen can be denied for token swaps on Ethereum)

Evidence #13:

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 #14:

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 YFI (v1) and Aave YFI (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 #15:

Please check attached evidence 3 To make this simpler, can the requester answer which line in the policy supports the removal of Aave version 1 tokens? 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? Also from a previous dispute https://tokens.kleros.io/token/0xfa437de067bb335b6861c3adaf6a3075e22344594400c99008ae08f8a2c7b55f 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 since it’s not used anywhere.

Evidence #16:

no reason for removing There is no reason for removing this token, as the requester extensively argued about in previous cases, like 447, a decission supportend in many cases where himself acted as juror. Now that he wants to remove the token whose name, ticker, logo and contract are correct, he argues the opposite. If he wants to change rules in order to include this case, he first should request a change in the policy through governance. My vote is not positive.

Evidence #17:

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 Clearly, removal of previous version 1 tokens don't go by 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 #18:

Remaining Aave v1 tokens need to be removed and re-submitted 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 YFI (aYFI). 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 YFI 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 YFI in this case. The challenger is lying about the reason for the rejections of Marc's submissions, which was not, as the challenger is trying to pursway, 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 #19:

Check attached full evidence It’s necessary to appeal the ruling since the requester is also a juror in the case. 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 #20:

Removal is required to re-submit them 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 #21:

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 #22:

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 #23:

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