Setup cCOMP voting

Similar to the proposal on setting up cUNI voting, it’d be interesting to get the community’s take on enabling a multi-sig setup for enabling COMP lenders to vote on governance proposals.

One of the things that we’d always like to see is an enhanced representation of different voting interests for topics under deliberation for Compound; but one of the segments that we seem to be cutting out is the community of COMP holders who are actively lending out their COMP to the protocol. As it is structured, COMP is meant to be a token representing governance - and not something that (yet) is representative of value/claims on the underlying reserves. The market liquidity of COMP is about 2.2% of the circulating supply - which is not insignificant in terms of the weight it could add to votes. To this extent, shouldn’t we be enabling such lenders the capability to also add their voice to discussions and their vote towards the same?

Similar to what @arr00 proposed, it could be good to delegate the weight of these votes to the community multi-sig, which could potentially monitor the net COMP in the protocol (lent - borrowed) + the reserves for a period of a week prior to the vote & combine that to a net representation of ayes and nays from voters (weighted by the amount of cCOMP in wallets). Might even be possible to add a discount factor to the resulting vote given that ownership of underlying COMP assets is somewhat dissociated from the owners - but that is something I’d love to hear people’s feedback on as well.

Would also be grateful to hear how hard this might be implement from a technical standpoint.

Any thoughts/comments?

5 Likes

I totally agree with this opinion. Would you like to discuss this idea together?

Per this post, the multisig is responsible for invalidating vote results that are manipulated. This presents minimal governance risk for cUNI, but I think this might be less viable for cCOMP. As a general safety principle, multisigs that receive power delegated from governance shouldn’t control execution of pooled votes for that same governance.

2 Likes

Why not account for a similar invalidation as suggested in the post? Maybe this could be combined this with a pro-rata weighting of the remaining supply + also weighted with a discount factor (say 50%) to reduce the weight placed on this vote? The idea again is pretty simple - if you want to exercise the full weight of your votes, you had better own the COMP in your own account; but it would be nice to enable people who deposit COMP (and this is important for COMP to function as a market and build reserves) to have a small say in governance. What would be the considerations to having a separate MS setup for this?

This makes perfect sense to me. COMP lenders, who presumably plan on holding for lengths of time (and therefore have a vested long term interest in the protocol), should have the ability to participate in governance, even if there is a discount factor.

2 Likes

I think it makes sense to let cCOMP holders have a vote. Currently, there are 229K COMP in the cCOMP contract. @arr00 would it be possible to integrate cCOMP voting into the governance bravo update where cCOMP holders could vote with the un-utilized COMP natively (w/out Snapshot & another multisig)?

Development for the initial Governor Bravo deployment is frozen and auditing is almost complete. In future upgrades to Bravo, it could theoretically be possible, but I’m not sure its the correct way to go. Definitely requires further discussion.

2 Likes

Is there a cap supply on the COMP market? Without a cap supply allowing cCOMP holders to vote is unfeasible. I think the reason for this is the currently centralized allocation of COMP tokens. What would prevent big COMP holders from using this feature and increase the gap between users and early investors?
Am I miss something?
I have earned few COMP tokens so far, and currently as a “dusty” holder my best option is capitalization.
Although enabling the “dual utility” option (capitalization + governance) contributes to me as a “dusty” user in theory, in practice it is only an illusion. (We can see that illusion on etherscan - holders)
I think the problem of protocol decentralization needs to be addressed first.
Have any other options been considered?