Retroactive Airdrop Excludes Proxy Contract Users (e.g. Dharma, Matcha, etc.)

[haydenadams]

@nadav_dharma

1. 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.

2. 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

3. 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.

One consideration with 1. and 2. is there are likely arbitrageurs / bots / relayers with thousands or tens of thousands of addresses that trade through custom smart contract proxies that would receive hundreds of thousands of UNI from this proposal.

Maximally inclusive sounds nice but I imagine will result in sending UNI to over >100,000 addresses (only <2% of which would be Dharma users)

its worth noting governance can always vote to allocate more UNI in the future, but can’t ever get back UNI it unnecessarily wasted.