Should Compound Retroactively Airdrop Tokens to Early Users?

Thanks everyone for your input! I want to start this update by harkening all the way back to the beginning of the forum thread:

As my earlier posts show, I found significantly more early users than estimated by @alive; my analysis gives ~30000 direct users, not including interactions mediated by contracts. So,

  • either we adopt @blck’s rationale to increase the available pool of COMP tokens to reach 100 COMP per eligible address;
  • or we maintain the initially suggested 500,000 COMP pool, which yields fewer than 20 COMP per eligible address.

I anticipate it will be much harder to pass 100 COMP per early user through full governance if it means sextupling the early-user allocation beyond what was initially envisioned. So the proposal I share below is based on the 500,000 COMP pool originally envisioned, inflated only slightly (by about 9%) to bring the minimum COMP distribution from 18.305842454139047 COMP to an even 20 COMP.

Proposed distribution list
Having now sliced the data several ways (socialized, capital-weighted, sqrt-cap-weighted, log-cap-weighted…), the approach that strikes me as the most fair is a “95% socialized, 5% capital-weighted” distribution.

:comp: :comp: :comp: Here is the list :comp: :comp: :comp:
(updated 12 Apr '21 to exclude addresses associated with Sybil attack on early governance)

How does this specific proposal balance fairness and simplicity?

  • There are compelling arguments for both socialized and capital-weighted distributions. Including both strategies in the formula is a way to reach a compromise on this question.
  • It is sensible to reward users who supplied and borrowed more capital to the protocol, but even a 50-50 split between socialized and cap-weight distributions is so heavily whale-dominated that it fails to achieve the goal of empowering the early user community with a meaningful shot at a role in governance.
  • A 95-5 split grants the largest whale (who has outed themselves already in this forum, @borovan) roughly ~100x the smallest grantee.
  • More than 9 out of 10 early users would receive between 20 and 21 COMP under this proposal; 45 users would receive > 100 COMP; 4 users would receive > 1000 COMP.

Finally, to align this distribution with the goal of broadening early user participation in governance, I suggest we develop a separate proposal to lower the minimum COMP required to submit a CAP to 20 COMP.

What about contract-mediated interactions?
The elephant in the room with early-user distributions is contract-driven interactions with the Compound protocol.

Context: Uniswap’s genesis UNI airdrop excluded contract interactions, spurring an initiative from application integration and DEX aggregator projects to propose an airdrop for users who interacted with Uniswap via proxy. The proposers took the position that this exclusion was accidental, and while the proposal received enough support to go to a vote, it ultimately did not pass.

Now that I’ve attempted to account for proxy interactions with Compound through on-chain data myself (thanks to @grasponcrypto for running part of the analysis!), I’ve come to a different conclusion about the Uniswap team’s motivations for excluding contract interactions: it’s simply way more labor-intensive to unwind these proxy interactions and find the initiating user on-chain – like, by orders of magnitude. And that’s just for projects that drop cTokens in the user’s self-custodied wallet. If a project uses Compound in a less user-direct way, e.g. holding everyone’s cTokens in a contract and periodically distributing interest in the underlying token, then it would not be possible to determine users’ distributions without additional knowledge about the project’s contract structure.

Application integration projects are welcome to develop separate proposal(s) for their users who interacted with Compound. Most of those projects have the skills in-house to do this kind of analysis much more efficiently than me, and they’ve had a few months to take the initiative. I am just a user/fan of the protocol, not representing any company in the space, so I choose to focus on early users who interacted directly with the protocol.

Next steps

  • Give folks a few days to review the code behind this analysis and make the case for any revisions.
  • Develop a CAP: Here, I think we can borrow @arr00’s merkle-distributor code originally developed for Proposal 32 to address the DAI liquidation event. This is venturing even further out of my coding comfort zone, so I would love it if someone with experience submitting a CAP were willing to step in here and use this list to produce the merkle tree and contracts required to submit a CAP (or at least help walk me through it!)
  • Persuade one of the ~400 community members holding > 100 COMP to submit the CAP.
17 Likes