Glad to hear there’s significant interest in this proposal. Would like to shift the discussion to some of the specifics of how such a system would be implemented.
There are two high-level questions that need to be answered before we submit a proposal:
#1 — How will we execute the retroactive airdrop for excluded users, if approved?
#2 — How will we determine the set of users who have been excluded from the drop?
Re: #1 — I feel there is a fairly straightforward proposal here.
In approximately 7 hours, vesting of the community treasury UNI allocation will begin, with a 30 day cliff ending on ≈October 17th, 2020. At that point, 172,000,000 / 12 ≈ 14.3m UNI will become available to the community treasury.
Once we’ve aligned the community on a set of excluded users, we deploy a merkle drop contract akin to the one Uniswap used for the initial airdrop that commits too this user set and to the quantity to which they’re entitled.
We can then initiate a governance proposal that grants ERC20 transfer approval from the timelock contract (0x1a9C8182C09F50C8318d769245beA52c32BE35BC) to the merkle drop contract in the amount precisely equal to the quantity agreed upon for excluded users. This means we can vote to “confirm” the distribution to excluded users now, and the distributed UNI will be withdrawable in approximately 30 days — the merkle drop contract will be able to pull the UNI at that time and make the UNI claimable by users.
Re: #2 — This is where I suspect the locus of contention will be: how do we determine the excluded user set?
I will propose a few approaches for discussion (note that, for all of these approaches, we would de-dupe addresses that are already present in the current UNI distribution):
- Compile a list of all addresses (contracts or EOAs) that are in the call-chain of historical calls to Uniswap v1 / v2 before Sept 1. — i.e. if a Uniswap trade was triggered as EOA -> ContractA -> ContractB -> UniswapV2, all three addresses would be considered to be “users”. This is likely the most comprehensive, but I fear would be overly liberal in allocating UNI.. A rough analysis of on-chain data is required here.
- Compile the same list of addresses described in approach #1, but limit them to 1-hop proxies — i.e. we make a simplifying assumption that you are only a “user” of Uniswap if you either call Uniswap directly or call a contract that calls Uniswap directly. This would work well for Dharma and would likely narrow the set described in approach #1 significantly — but may exclude other interfaces / projects who use multiple-chained contracts
- Finally, we can do this much more “surgically” — i.e. Dharma pulls it’s list of affected users, Matcha pulls their list, Paraswap theirs, etc. etc. Though this would certainly limit the amount of UNI being distributed to a conservative number, it would also invite a lot of subjectivity into this process that may hamper its likelihood of passing as a proposal.
Would love to hear thoughts (in particular from other projects that have been affected) on what would be the maximally inclusive way of doing this that spends the least UNI from the community treasury