For the past few weeks, Blurr and I have been working on preparing a Governor Bravo implementation based on community feedback over the past few months. The start of the conversation from Governor Bravo began in this post and has inspired some of the changes we’ve made so far. I’ll summarize the changes made along with their inspiration, and include a tentative timeline. Any feedback or recommendations for changes are greatly appreciated!
Upgradable Implementation - Like the Comptroller, Governance will now be upgradable to allow for incremental changes without breaking infrastructure built around it. The implementation is governed by Compound Governance.
Abstain option on voting - This allows for users to abstain to votes on chain. It is a necessary feature for a future project involving COMP staking.
Voting reason string - Users are able to send a string along with their vote explaining their voting reasoning. This is stored along with the vote receipt.
Settable governance parameters (voting period, voting delay, proposal threshold) - Having these fields be settable by governance allows for changes to the governance process without the requiring new contracts to be deployed.
Allowing proposer to cancel their own proposals - Currently, the only way for a proposal to be cancelled is for the proposer to lose delegations and fall below the proposal threshold. Allowing the proposer of the proposal to cancel their proposal at any point makes it possible for an erroneous proposal to be canceled if needed.
Removal of the Guardian - the guardian logic was used for the initial setup of Governance but is no longer needed. The logic around it has been removed.
Continuous Proposal Id Count - I have added logic to GovernorBravo which will set the initial proposal ID to the number after the final GovernorAlpha proposal ID.
Admin Logic - the settable parameters and implementation are governed by the admin, which will be set to the compound timelock.
We are approaching completion of the GovernorBravo implementation with the above features. Over the next few days we hope to complete testing and refactoring the code. After, we get the code audited which may take a while due to the current crypto environment. Shortly after the audit comes back, assuming all is well, we will post an autonomous proposal with the changes.
You can follow along with the development effort here.
Nice work arr00, these seem like excellent changes. After your external audit, would you mind starting an open bug bounty here for seven days before posting your autonomous proposal? It could help start the precedent that the Compound community itself has an incentivized opportunity to find bugs before all major code changes are put up for a vote.
Sure. COMP staking which allows for you to maintain your voting rights. COMP is distributed to stakers and you are only eligible for rewards if you participate in governance. I think an on-chain abstain should count as participation, but that can be debated later on. I just want the infrastructure to be in place.
There are many intricacies involved in the COMP staking project, but I’d prefer to leave those to another post when we are closer to completing the project.
Thanks for opening great topic. I think that it would be very flexible governance structure if it has been implemented these factors.
But I’m not sure yet how to operate eth based Compound protocol after launching Compound Chain.
if it needs to operate them separately, is it possible to identify Compound Chain specific proposal in Governor Bravo design?
Compound Chain is definitely a task for later down the road. Governor Bravo has an upgradable implementation which allows for future updates to be made easily.
Hi @arr00 and Blurr. This is tremendous! I am very excited that you have taken the initiative to improve the existing protocol. I have an idea that might make governance participation a bit easier.
Before I say it, I want to express that this is something that can come at a later date, in a separate iteration of Governor contract changes. I think it is important to make protocol changes in small increments; a best practice if you will.
My idea is to enable governance voting for individuals that hold cCOMP in addition to COMP delegates. There are probably several ways to implement this. Perhaps changes would need to be made to cCOMP as well to make it possible? I’m not certain. To everyone reading this, not just Ar00, what are your thoughts on enabling voting with cCOMP?
My take on it was to enable fractional voting, i.e. voting with less than the total amount of votes that an account has. This would make it possible for the accounts that hold the underlying COMP to vote accordingly to the ratio that cCOMP votes on. Also read Arr00’s reply in the PR - changing cCOMP to be delegateable would be another way to do this.
Sorry for the late reply. I think something like this can come in the future, but I am not necessarily a fan of the idea. Throughout all other Compound markets, you generally sacrifice the utility of your asset for the economic aspect of being able to borrow on it. If you are do not lose anything when lending to cCOMP, then I don’t really see it as lending and neither will the market. I think it is ideal for COMP to have a functioning market and incentives COMP holding through other means.
Governor Bravo development and auditing is finally complete! You can view the finalized PR here, and the audit will be published by Open Zeppelin in a few days.
While I am quite confident that the code is sound, I will be hosting a community wide bug bounty for the next week in order to encourage community review prior to the proposal. Please reply to this post with any findings and if they are legitimate, you will be rewarded in COMP.
I understand and consider logical certain arguments for “utility trade-of” (i.e. COMP will become cCOMP - if holders will play with rationality). However, I feel that the current utility of the COMP token is underutilized. I am in favor of creating a COMP staking pool with a staking rewards less than 5%, COMP staked in that pool has a full voting right but with a timelock period between 1 - 3 months.
With timelock option we will be able to filter real long-term believers and be able to predict moving “native” funds inside protocol
The governance system would be separated from the COMP market (long-term users who believe and want to work on the project would be separated from recursive farmers)
It would be clearer if the project is moving towards decentralized management (difficult to predict in the current situation) - it would be easier to control the evolution into a truly decentralized system
I’m not for fractional voting because I don’t think we would get clear metrics that show protocol health (share of particular interest groups on protocol, reactions after prop implementation, recursive farming discovery etc.).
I would say utility of COMP token is intentionally crippled. Currently there are basically 2 things you can do with COMP tokens:
vote with it (which realistically just for fun and not impact anything unless your holdings count in thousands. And even then it’s not really impactful on results of voting)
You can use it as collateral. Which would really be enough as a major usecase unless it wouldn’t be kind of messed also:
a) By putting it as collateral you, for some weird reason, loosing your voting power, even if relatively small one.
b) You are forced to accept that your tokens might be lend, which you might not be fan of at all. And then you get arguments that: hey, they wanted to get some interest, so that’s a trade-off. Except there was no other choice to use it for collateral in other way.
Guess what, i’d say pretty much nobody with COMP holding in hundreds give a slightest care about that 5% or so of interest you might get at cCOMP market, because you can very well borrow some USDC or DAI and get interest in 20-30% APY on that relatively easily.
I’m not sure there is that need of COMP borrowing market at all, as i read so many times concerns that “somebody could borrow COMP and somehow manipulate governance” Realistically i believe there are 2 major usecases for current COMP market:
recursive farming (if you were lucky to fit your borrow under CAP)
shorting COMP . If you are COMP stable coin farmer, that’s a great idea to sell your future distributions of COMP at high price (when it’s high) and repay it back with future distributions.
But again we can leave gimped cCOMP market as it is. Solution is actually quite simple, and don’t even require some impressive coding skills and just goes down to creating another cCOMP token. We can call it cCOMP2, or gCOMP (governance COMP) or wCOMP (wrapped COMP) or whatever else to separate it. And implement it with borrowing side disabled completely. Than we can have all the collateral usage, no borrowing side risks, no governance manipulation risks with borrowed tokens. And it can actually allow user to fully retain his voting power (that might need some coding though) as all tokens stay there in pool unless redeemed back. It even could be non-transferrable, like only be able to redeem it back for COMP, but not transfer from one address to another. That could very well be a defalt way of storing COMP tokens rather than quite costly one by keeping it in your address. (the cost here is opportunity cost, you lock away your capital in holding token which otherwise could be used in generating profits.)
And yeagh, i get it, COMP token is governance token, have no value. Except it’s not the case, it certanly DO have a market value.
Actually, i have opportunity cost now in situation where I need to choose which utility to use. With given gas cost (waiting to accumulate amount of COMP) and voting significance ( illusion ) average user has nothing.
What the difference between staking and gComp pool?
And for lock away COMP vs generating profits - depend of user preference - so it’s subjective perspective.
I just want to say that maybe will be better have more choices when come to COMP utility. If you think that 5% is low then go to dapp interface and watch. I was just bring average staking number, read xy%.
Staking usually bring zero value. Like you just send it to contract, contract lock it away and this is it. It’s a bit different, for example when you stake LP tokens, as then you providing liquidity and getting fees from pool.
Making another pool without borrowing is different, because you are actually using it as collateral. It is true for cCOMP pool also, but in cCOMP pool you lose control over your voting power, which is main purpose of having COMP to begin with. And you can’t really preserve your voting power in cCOMP pool for a reason it have borrowing side, thus amount of COMP in pool is able to fluctuate. But thing is, it came with a “packaged deal”, nobody asked Supplier if he want his COMP tokens be lend at all. Maybe his only interest was to use it as collateral (which is big deal by itself, given current valuation). That’s my point.
Surely, there are some users who want to lend their COMP. But i’m talking about much bigger userbase, who not interested in doing it at all. Quite opposite. They intend to hold it for extended period of time, and they want to use it for voting, and they want to use it as collateral. Pretty basic usecase imho.
When you use your assets as a collateral in a bank, you don’t expect or allow bank to lend it. And you don’t expect to lose your voting power either, in case if your assets are shares in some company. Why it’s different for COMP i have no idea.
So, Compound does not provide a very basic tool for COMP holders, yet so many complains are there that COMP have not much use case. And concerns about governance manipulation via borrowed COMP.
@arr00 fantastic work, and congrats on the audit results. The Governor Alpha contract has become a standard in the Ethereum community, and Bravo will continue the trend
@dabar90@Sirokko these are great points, and an interesting conversation, but aren’t related to the development of this new voting contract. Let’s try to keep the conversation focused on the Bravo contract.
