[Proposal] Excluded Proxy Contract Airdrop — Phase 1



  • We have compiled sets of users excluded from the retrospective airdrop due to the proxy contract issue from projects integrated into Uniswap, and validated programmatically that their submitted users were indeed unfairly excluded due to technincal oversight.
  • In summary, there are two rough cohorts of project-types who are affected: application integrations, and DEX aggregators. Given that these two cohorts have very different sizes and vey different end-user characteristics, we are separating our proposal into two sequential phases — first for the application integrations, second for the DEX aggregators
  • We divide these cohorts on the basis of how easy it is to programmatically hook a trading bot into them, as this is a proxy for what portion of these cohorts risk representing multiple addresses per end-user. If an application is clearly tailored towards programmatic usage (i.e. it exposes an API on its landing page), it falls in the DEX aggregator camp. If it does not, it falls in the application integrations camp.
  • Our personal opinion is that both cohorts were likely unintentionally excluded and ought to be compensated by this proposal; however, we recognize that the two cohorts engender very different debates around whether or not they ought to be compensated, with quite different magnitudes of impact on UNI holders. We do not want to conflate the two into a singular vote, and risk jeopardizing both on account of the other.


PHASE ONE: Application Integrations — 12,600 accounts

Project      	Accounts
Argent      	3418  (27.13%)
DeFi Saver  	890   (7.06%)
Dharma      	2833  (22.48%)
eidoo       	301   (2.39%)
FURUCOMBO   	57    (0.45%)
MEW         	4278  (33.95%)
Nuo         	740   (5.87%)
Opyn        	79    (0.63%)
rebalance   	4     (0.03%)

PHASE TWO: DEX Aggregators — 26,598 accounts

Project      	Accounts (overlapping %'s)
0x          	1772  (6.66%)
1inch       	4924  (18.51%)
DEXAG       	465   (1.75%)
Kyber       	23933 (89.98%)
Totle       	718   (2.70%)

What Happens Now

* targets:  `[ "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F9841" ]`  (UNI)
* values:  `[ 0 ]`
* signatures:  `[ "approve(address,uint256)" ]`
* calldatas:  `[0x0000000000000000000000006a9929D29b7488517D383358a847c95a5D1d6d76000000000000000000000000000000000000000000042b42f28d278eee000000]`  (address:  `0x6a9929D29b7488517D383358a847c95a5D1d6d76`  (phase one merkle dropper, amount: 5.04M UNI)
  • In summary, it would be granting 5.04m UNI approval from the community treasury to the MerkleDistributor contract for Phase 1.
  • If this proposal passes (and no subsequent proposal nullifies it), on October 17th any third party will be able to transfer 5.04m UNI into the MerkleDistributor contract. At this point, users in the Phase 1 cohort will be able to withdraw 400 UNI each from the MerkleDistributor contract.

We now need to amass at least 10M UNI delegated to an address in order to submit a proposal to vote. There are two ways we can make this happen:

  • Delegate to Dharma at 0x7e4A8391C728fEd9069B2962699AB416628B19Fa. We are very active participants in Compound’s governance, have sufficient technical acumen and resources to develop proposals securely, and have basically our entire business on the line as “skin in the game”. We think we’re a great party to delegate to :nerd_face:
  • Perhaps most efficient & quick would be if supportive UNI holders delegate to the Univalent delegation (yuni.finance), and request they put the proposal to a vote. I would not recommend users do this until we receive assurance that the Univalent delegation would be interested in putting the proposal up for a vote. Note that proposing != voting for — Univalent could kindly help us get this proposal live and vote against it if they so pleased! Can folks please help get in touch with Andre, Tarun, Kain, and Stani to see if they’re interested?. We can likely help push them over the 10M line.

I expect aspects of this proposal to be contentious, so I’ll leave the community with a last note, copy-pasta’d from the original post I shared in this forum:

I will note to the community that this vote sets a cultural precedent as to how the protocol treats not only its direct users but also developers who take entrepreneurial bets building on Uniswap. The status quo has unfortunately punished our users and eroded our reputation with them — future builders will heed the signal and precedent set by how the Uniswap community addresses this.

Let the discussion begin!



Just want to point out that Argent wallet users were able to get their airdrop, isn’t that right?

It might have been convoluted but they had a page about it.

Let me know if I’m on the wrong page here, it’s definitely unfortunate that so many people were excluded.

Paraswap indicated they were submitting a list (https://twitter.com/paraswap/status/1309169251652177933) but I don’t see them here. Did they fail to submit before the cutoff date?


Could you include paraswap, please? :pray:

The page talks specifically (only) about users who have provided liquidity to Uniswap through Argent.

This proposal include other Argent users who have swapped tokens through Uniswap.


How many votes does Dharma currently have?

I’ll gladly delegate my vote to the team.

I’m not 100% sure but I believe that yuni.finance just hit 10mil votes.



I have a question about the Phase_Two. when will Phase_Two be started?

many thanks.

If I send 0x7e4A8391C728fEd9069B2962699AB416628B19Fa to the balanceOf of the contract https://etherscan.io/address/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract I get:

uint256 : 1000403434097477213

Then again, I might be an idiot (how many decimals is that… 18?).

Yes the uni token is 18 decimal places you can usually find details like those on Etherscan

Each of these still have to go through the proposal stage and have enough UNI holders agree to another distribution thus why the OG mentioned

So it could still go to proposal and face rejection in which case none of these people would be compensated or it could go to proposal and pass meaning they would receive tokens from the Community Treasury

1 Like

Thanks! The “I might be an idiot”-part came from trying to find the number of delegates. Seems balanceOf just gives the number of held UNI, which didn’t help @Giratina very much.


Uniguy772 thank you so much

I hope Phase_Two’s distribution will begin soon)

1 Like

Here’s the merkle root, token total, and claims (account, index, amount, and proof) for all 12,600 accounts in phase one (400 UNI each, 5,040,000 UNI total) — phase two needs to be regenerated to include Paraswap (thanks for pointing out the omission, @MrDost… PR has been merged!)


@TragedyStruck balanceOf gives the UNI balance of an account, not the delegated votes — to get those, you want getCurrentVotes!

1 Like

Cant confirm why but Paraswap would have probably been excluded for a reason. Dharma made a forum post a while back and asked affected exchanges to reach out with proof and verified figures along with contract addresses that interactedwith Uniswap… a lot of exchanges that submitted were vetted and weren’t included on the final list I’m sure for good reasons.

I’m sure if a verified team member from Paraswap reached out to Dharma on here a discussion could be had but I would think it’s unlikely they’ll be included as it would be unfair to exchanges who met the deadlines

While the focus of this proposal is on Phase One, i.e. application integrations, here is the updated information on Phase Two, i.e. DEX aggregators (including ParaSwap):

PHASE TWO: 26,986 accounts — 10,794,400 UNI @ 400 UNI per unique account
Project      	Accounts (overlapping %'s)
0x          	1772  (6.57%)
1inch       	4924  (18.25%)
DEXAG       	465   (1.72%)
Kyber       	23933 (88.69%)
ParaSwap    	486   (1.80%)
Totle       	718   (2.66%)

Link to merkle root and claims


0age big thanks

please keep us informed about the Phase_Two!


Hi, Fulvia from 0x Labs. We applied on behalf of the 0x API integrators to facilitate things for them. We can demonstrate that the affected addresses we reported originated transactions through user-facing applications like Matcha, Zerion and DeFi saver — which is included in the first group. If we provide the split would they be included in the first group?


John from Matcha here, just wanted to echo Fulvia’s message.

Given the switch up on grouping and cohorts, Matcha should be submitted with the first cohort as it is a customer-facing application. Per the grouping criteria, Matcha provides no API integration for programatic usage thus falling squarely into an ‘application integration’ criteria. (e.g. No trading bots can be used on Matcha)

We can provide a breakdown for Matcha users specifically. Can you confirm @0age


Check the yuni site, they have 2 goals, it looks like goal 1 was met.

Also to check delegates I believe you have to use the “read current votes” function. Or #9 on etherscan under the read tab.