Wow, OK — this discussion is spiraling in a variety of directions.
Let me try to focus things here:
In contradiction to what I said above, though, I have heard several anecdotes in private discussions indicating that expanding the UNI distribution to the “maximally inclusive / non-discretionary” options I listed above may abusively advantage arbitrageurs. Allegedly, an oft-used infrastructural setup for such users is to have a single proxy contract with a large number of (circa 1000s) EOAs attached, and, unfortunately, the clever design suggested previously by @AgentSmith could succumb to this if it purely lived at the protocol layer.
This isn’t to say that the initial allocation was maximally sybil-resistant or “fair” – but, in a sense, we’re better-positioned to not repeat or exacerbate drawbacks in a “programmatically-objective” distribution strategy now that we have governance.
My revised proposal then would be as follows — establish clear “inclusion criteria” for wallets, interfaces, and aggregators whose users have been excluded from the distribution, collect a list of addresses from said wallets, and then use that list to create the initial merkle root for the allocation.
The goal here will be to keep the allocation minimally surgical.
In more detail:
Inclusion Criteria
We define “projects” as being any entity whose users were excluded from the retroactive UNI allocation due to the proxy contract issue identified above.
In order to be eligible for inclusion in this distribution, a “project” must meet the following criteria:
-
Prior to September 1st, they exposed a publicly-available user interface either on web or in an integrated mobile application that allowed users to make trades on Uniswap in some capacity. We include DEX aggregators in this definition — UNI holders ultimately get their paycheck from market takers, not makers. Aggregators are fundamentally in the interest of Uniswap’s success.
-
It must be clearly verifiable that said interface / application was available to users prior to September 1st (e.g. if this is not immediately obvious that this is the case, the burden of proof is on the project for demonstrating, for instance, that an interface can be loaded on Wayback Machine, etc.)
-
It must be clearly verifiable that said interface / application at the time hooked into a proxy contract calling into Uniswap. Again — if this is not immediately obvious or verifiable, the burden of proof is on the project to demonstrate this.
-
Finally, the project should provide a list of addresses of affected users. It must be clearly verifiable that those addresses are associated with the proxy contract system previously identified to be associated with the project. Once again, if this is not immediately obvious, the burden of proof lays with the project.
All provided addresses will be verified against historical Uniswap v1 and v2 calls to exclude any addresses that were not in the call-chain of a Uniswap transaction (successful or failed). Open-source code to verify that this is indeed the case will be published for independent review. All addresses will be verified for not having been in the initial retroactive UNI allocation.
Discussion Period
We set aside the following 24 hours for discussion & debate of the above criteria. Once the 24 hours elapse, we move into the Application Period
Application Period
A thread will be posted in the governance forum where projects will be asked to submit short, public applications on behalf of their users. This will be a handful of questions we will post into a template in the thread’s OP. We will reserve 48 hours for submission and inline discussion / debate.
Submission
Once a set of projects is decided upon, said projects will be asked to submit a list of affected user addresses in a public thread.
Those addresses will be verified against the aforementioned criteria using publicly available code we will publish.
We will then compile a merkle root for the distribution, deploy a merkle drop contract referencing that root, and will initiate a governance proposal to grant approval to said contract, with triggering scheduled for October 17th, 2020.
To correct some misconceptions that appear to be circulating above — this allocation will be no more dilutive than the normal state of affairs; it will come out of the community treasury in which UNI is continuously vesting. Moreover, our intention is to be as surgical as possible — our hope is to limit the expanded allocation to the single-digit thousands. We are open to employing a methodology akin to the one previously suggested by @AgentSmith (i.e. users must claim their distribution on-chain prior to October 17th, so only a strictly claim'd amount is transferred to the merkle drop contracgt), though the end-result numbers may militate towards this approach being overkill.