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

[Yieldcrypto]

I am in support of this proposal.

What uni swap did was not in favour of people supporting the newly emerging tech like Dharma.

Dharma is building add-on for customer experience for users who can’t use uniswap.

I urge uniswap to do the right thing and airdrop the required tokens to proxy contract users.

Thanks Uniswap for all that you did.

Please support Dharma.

[aasinghal]

Uniswap has been a great platform. But it’s not possible to be in front of laptop all the time. Dharma has been a great alternative to do trnx on uniswap on the go (on mobile). It would be great if mobile (dharma) users of uniswap are not left out of retrospective rewards.

[Jay-Prime]

Hey all, Nikola from DeFi Saver here.

Our users are in a similar boat, though the architecture is a tad more complex (user calls the transaction for actions on their dsproxy (which holds their MakerDAO CDP/Vault, Compound or Aave position etc) and then a UniswapWrapper contract of ours initiates the actual trade further down within the transaction).

This is in regards to our Boost, Repay and other transactions that involve swaps which are often handled by Uniswap.

If there’s a possibility of these accounts being considered for UNI airdrops, that would be absolutely amazing.

We’ll be following this thread and we will gladly provide any more information needed.

[ValCrytoast]

I support this proposal and I am delighted that it is only an oversight.
I hope that it will be rectified as soon as possible by the community.
not taking part in the biggest airdrops in history with these UNIs is frustrating. especially as we interact a lot with the protocol. thank you

[monet-supply]

I’m generally in favor 100% . My only concerns:

Is there any way that supporting distribution to delegateCall interactions would skew distribution towards whales or bots? Or any other gaming issues to be considered?

My general assumption is NO this shouldn’t be a problem if we use the same retrospective snapshot date, but it’s worth considering.

[Direwolf]

Startups like Dharma, offer great opportunities to enter the Dex world on mobile devices. Such initiatives and the users who support it, deserve to be as cared for as the others.

XXX

[nadav_dharma]

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):

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.

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

[monet-supply]

@nadav_dharma

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

I would love to hear other impacted interfaces / contract wallets speak up on this point.

[ryanc414]

@monet-supply

@nadav_dharma

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

I would love to hear other impacted interfaces / contract wallets speak up on this point.

I don’t think that would work for Paraswap users, and by extension it wouldn’t work for Monolith users either since Monolith uses Paraswap for in-app swaps. Paraswap seems to have multiple hops between the initiating user address and the uniswap contract, for example: https://etherscan.io/tx/0x9aa38d9a86654e80e689f424cdda570ae33dbe48112dd860720d62f44968c7aa

[Jay-Prime]

@monet-supply

@nadav_dharma

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

I would love to hear other impacted interfaces / contract wallets speak up on this point.

Yeah, pretty sure this wouldn’t work for DeFi Saver users either. (User account - DSProxy - UniswapWrapper<>Uniswap)

The user account initiating the transaction should be the one to receive the UNI in our case.

Is there a reason not to just stick with EOA, the addresses initiating whichever transaction including a Uniswap swap? Guessing there’s a pretty obvious one that I’m not realizing, but just sounds like the simplest potential solution.

[nadav_dharma]

Sounds like the 1-hop approach would have exclusionary implications. I think the next step here is to pull some empirical data to get some rough heuristics on the scale of each approach. I will circle back with more information (or, if anyone else wants to pull this thread, your contribution would be helpful).

[nadav_dharma]

@Jay-Prime

Is there a reason not to just stick with EOA, the addresses initiating whichever transaction including a Uniswap swap? Guessing there’s a pretty obvious one that I’m not realizing, but just sounds like the simplest potential solution.

For smart wallets like Dharma, the EOAs are simply the keys we use to submit transactions for our users. The user’s “address” is their smart wallet contract.

[AgentSmith]

If feasible, I propose adding a “claim” button to each excluded platform for active users to participate in a roll call. All possible methods of communication should be used to promote this.

Then, use that list of addresses to check for TXs within the eligibility window and distribute UNI accordingly.

I believe the tradeoff of inclusivity for equitability and efficiency is justified in this scenario.

[Jay-Prime]

Yup, that’s definitely an obvious issue, thanks for clarifying

[mds1]

If that’s the only reason not to simply use the EOA that initialized the transaction, can’t we work around that by modifying the claim function? Adding a function argument that lets the UNI be transferred to a specified recipient and supporting meta-transactions should be the only required changes. Then in Dharma’s case you’d specify the user’s contract wallet as the recipient, sign the claim transaction with the EOA, and send the meta-transaction.

[Keeeeeeeks]

ELI5 where did the coins go? Aren’t they in the proxy contracts that interacted with users? Or is the idea that all of Dharma users got a 400 UNI allocation, and not 400UNI * [number of proxy contract users]

[onlinedollars]

It is worthy to appreciate the team for taking responsibility and are willing to make amends for any oversight.

[monet-supply]

There were never coins allocated to these users. They interacted with Uniswap contracts via delegate call, instead of calling the contracts directly. Only those who directly called the contracts had UNI allocated to their address. So in the case of delegate call users, neither their wallet, nor the contract received UNI.

[brendan_dharma]

Services that used a proxy architecture (in which a proxy contract performs the Uniswap smart contract calls on behalf of users), were not included in the initial UNI distribution. Only addresses that had called Uniswap functions themselves were included.

We think this was an innocent oversight, and that the spirit of the distribution was to include these addresses. So we are working to try to get them included in a new UNI distribution.

[MrDost]

Paraswap and Uniswap are
We, DeFi users, appreciate DeFi movement and swapping plalforms. Uniswap is the one of those platforms! I mean, I dont think we need to use Uniswap directly to show our love and support, any transaction, passed throught Uniswap deserves our attention and thankfulness!