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!”
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.