How is 30 comp calculated ? I thought we have total of 50k addresses and 500k comp that puts about 10 comp per user ? Isn’t that true ? Thanks
I agree with you
My understanding (correct me if I’m wrong) is that it is based on @gabrocheleau copy of airdrop sheet, where his use of 30 COMP works out to around 500 000 COMP airdrop. It is around 32 560 addresses, but with his specific use, many of them get 0 COMP, and then there’s several values in between (under and over).
Makes sense. So we have the users who are eligible and emulator in place to play around and just a week span to prevent the grant expire. So what’s preventing someone to start a proposal and take this idea into fruition ? Thanks
First off, I’m guessing “whats the holdup” is just that I don’t think there’s reasonable consensus around the actual numbers. I mean, @gabrocheleau had some reasonable numbers, but I’m not sure it has matured enough yet.
Second, you’re talking about the grant expire. I’m not sure I see the issue here. The grant as I see it was to provide the data. The data is here. There’s no real urgency about it. Obviously this thread has been going on forever, but as long as there is progress I think there is no short term urgency.
Just my 2 wei.
I’ll be listening in.
Yes. I see no agenda item for this topic though…?
@TradegyStruck is correct. I really appreciate @cryptobuddy_1712 's enthusiasm, but the grant expiry concern is a bit of a misunderstanding of how the grant is related to this broader initiative. The grant supported the early user interest analysis, and that work is complete; I will do my best to be responsive to any questions or concerns about it. This broader initiative continues beyond the expiration of that grant.
The only difference before v. after the grant is that until the grant is officially closed out, I won’t be weighing in on the present discussion of translating the data into a distribution. If this discussion seems to be converging on a consensus recommendation before that happens, that’s awesome; otherwise I might add my two cents to the discussion after the grant’s closed.
It looks like a pretty full agenda, but it would be great to have someone involved in this discussion briefly jump in to update the dev community about the current state of the discussion, so that it can incorporate any questions or concerns from the broader dev community. I am not sure if I will be able to make it; if I can, I’m happy to bring it up, otherwise anyone else here is welcome to do so. I’ll post a note to this effect in the forum thread for the dev call agenda.
Oh I see. Thanks for clarification on the grant. Just wanted to make sure all great efforts are not in vain. As some one pointed out as long as the progress is made probably we are good .
just do same amount for all eligible address, uniswap done with 400 each address, why not compound? much easy and take no more than week to completed
That’s not how Uniswap worked. Uniswap had a capital weighting mechnasim based on amount and duration an address provided liquidity. What’s being discussed here is actually pretty similar to how the Uniswap airdrop was structured.
It is really besides the point of how Uniswap or any other project decided on how to do the airdrop. Those projects aren’t Compound. Those projects may or may not have had the huge difference in users, or the multitude of users who interacted in such a way to not really be users (Sybil attack/smart contracts designed to spread cTokens to make it look like there were more users/etc/etc). Over 50% or +20,000 “early users” had earned $0.00 interest.
I totally agree with you. Just pointing out a blatantly false claim.
Update re: today’s dev call. I summarized our progress and solicited input from the dev community. It’s important that we get this input periodically as plenty of key community members have limited bandwidth to follow this thread.
My sense is that the concerns about a distribution raised in the dev call – which are inclusive but not necessarily representative of the developer community as a whole – center on:
- Size of the distribution, both in terms of monetary value and in terms of COMP available to the comptroller for distribution
- Opportunity cost of distributing COMP to early users that could have been deployed for additional grants or other yet-to-be-determined incentives for driving adoption, hardening the safety and reliability of the protocol, etc.
I hope we can continue to work hard toward incorporating these concerns in this discussion. We may be tempted to defend this initiative by going on offense against constructive criticism; but my hope is that any proposal that emerges will be responsive to the various concerns raised across the full spectrum of protocol users and COMP holders.
One suggestion raised was the idea of submitting an initial on-chain proposal that simply asks governance whether there is support for pursuing some flavor of early user distribution.
I appreciate the suggestion and the accompanying good intention of avoiding unnecessary development work. I also recognize that there is an appetite in this forum for timely action toward an on-chain proposal. That said, I would advise against submitting a preliminary or temperature-check proposal through governance:
- Every prior governance action has involved an on-chain task(s) for the protocol to execute. A proposal that just asks COMP holders whether to eventually hold a vote on this idea would deviate from that standard, treating this proposal initiative – which is probably at this point the most distributed, in terms of community participation and development, in Compound’s history – differently from initiatives coming from Compound Labs, its backers, and a small handful of all-star devs in our ranks (no shade intended, y’all are amazing!)
- Without a specific distribution or mechanism laid out, never mind coded up, the proposal will be inherently more ambiguous than any prior governance action. Given the conservative approach governance has taken to protocol changes, the ambiguity of a temperature-check proposal makes it likely to fail irrespective of the merits or deficiencies of this initiative because a “yes” vote carries greater yet harder-to-measure uncertainty/risk than a “no” vote.
In short, I think the intent of the suggestion is in the right place, but for this idea to really get a fair shake, it should be presented to governance in a polished, well-reasoned, and executable format.
The discussion did not get that quantitative, so I don’t have a clear answer for you on that one. (@CryptoCraig was there fwiw, just a mic issue I think)
Yeah, mic issues. Was using my mining rig, since the usual PC wouldn’t have been able to keep up with the other stuff I am working on currently.
Will also be voting no to this proposal. Like many have mentioned, many alternative more productive ways to utilize reserve funds.
What you’d be creating is a possible divide between users going forward.
Maintaining comp distribution to the existing small group of comp holders creates financial and regulatory risk outlined in the SEC’s token safe harbor proposal.
If we don’t make a real and quantitative effort to decentralize governance we pose the risk of COMP being defined as a security and the protocol could become legally susceptible to laws under the security exchange act.
Noting specific concerns to how network maturity is defined, quantitative measures and related persons.