At DoDAO, we have worked on a few initiatives in Compound, and had been looking at improving governance tooling.
One of the biggest challenges the community faces on the governance side involves the additional overhead required for updating market parameters.
A governance proposal is undoubtedly necessary when adding a new market or a new asset to an existing market. However, updating the market parameters through the full governance process adds significant overhead. Considering the effort cost of Delegates (time of each delegate), coordination efforts, and on-chain voting costs, the gross cost could exceed $2000 for each proposal.
Additionally, by having market proposals go through the same lifecycle or governance workflow, we detract from focusing on more significant proposals, such as new partnerships, new markets etc.
We propose a parallel process specifically for market updates that can bypass the normal governance lifecycle. This would allow us, as a Compound community, to move faster and focus on the most critical decisions.
Approaches
There are multiple ways to enable a bypass of governance for market updates:
Update Configurator: The Configurator Contract is straightforward and currently does not contain much logic. We could add a new role/modifier “onlyMarketUpdateAdmin” that checks for a whitelisted address and applies the market update. This modifier would only be added to the functions that allow the updating of market parameters.
To create this modifier, we could either use a custom role/ACL design, utilize OpenZeppelin’s Access Control, or keep it minimal with a direct address check.
These updates could be applied by a multisig arrangement, such as 2-of-2 (Gauntlet and OpenZeppelin) or 3-of-3 (Gauntlet, OZ, and DoDAO). This approach has also been adopted by AAVE due to similar challenges.
Optimistic Governance: In this workflow, we could establish two parallel governance tracks. One track would be set for optimistic governance, where a preconfigured whitelisted address could veto proposals. If any of the preconfigured delegates or addresses reject the proposal, it would then proceed through the normal cycle. This change would require updates to the Governor and Timelock contracts.
Due to its smaller scope and lesser impact, we propose working on the first option.
Hi @DoDAO - Thanks for proposing. Given the number of markets now managed by Compound and the large overhead of passing proposals, it’s highly worth considering solutions that add efficiency to the process. I’ve personally been supportive of past discussions of this idea going back to 2022.
I’ll set aside the larger community question of whether governance would be comfortable making this change for others to discuss. I’ll instead explore the implications of implementing both approaches.
Approach #1 - Update Configurator
As you indicate, this would be an upgrade on the Configurator contract that would introduce a new role with the power of updating market parameters. The Configurator contract is fairly small (348 LOC) and can be upgraded separately from the main Comet contract. There is a Configurator contract for every chain that would each need to be upgraded (currently 6 instances, not counting testnets) but each of them should follow the same code version.
I am personally a fan of using OpenZeppelin Role-based Access Control (RBAC) wherever possible. However, Comet currently uses its own Configuration Interface to set roles such as the governor and pauseGuardian which then implements revert checks inside each configuration setting function. Unless there was appetite to fully refactor Comet to use RBAC, it makes sense to simply add a new role to the Configurator that aligns with the existing approach.
The account that would be assigned this Market Admin role could be a Safe multi-sig to mitigate the risk of a key compromise. However, this means that a seperate Safe instance would need to be created on all 6 networks as well. Gauntlet is the obvious choice for assuming these responsibilities given that it replaces the need for them to submit governance proposals but I’m not sure if it other parties mentioned in the post would be comfortable assuming those responsibilities on a multi-sig as well.
Another alternative is for the Market Admin to be set to a Timelock contract which will delay any market configurations by a specific time period, say 2-3 days. This would allow Gauntlet to maintain a single EOA address that could then be used across all 6 networks. If the key was ever compromised or Gauntlet proposed a market change without community support, a seperate multi-sig could be given powers to cancel the pending change. However, this does require the multi-sig to assume an active role in representing the interests of the protocol in market parameter changes since governance itself would have no direct oversight. The Pause Guardian is an existing multi-sig already present on each chain but this would be a new responsibility that currently falls outside of its scope of emergency response.
Approach #2 - Optimistic Governance
This approach would require more considerable refactors to the overall governance system. It does allow governance to maintain more direct involvement in the setting of market parameters while still making the process more efficient.
Current governance proposals go through the Mainnet Timelock for two days and cross-chains proposals go through an additional Timelock (Polygon for example) on the destination chain. This means modifications to several stages of the governance process and multiple different contracts will be required for the time delay to be fully reduced, although perhaps this is not a major concern if voting overheard is the main issue being addressed, not time delay.
If we attempted this approach, I would specifically propose that a Market Admin role be given to the Gauntlet team that allows them to propose market parameter changes. These proposals will be given a shorter review/voting timeline during which delegates may vote in opposition with a low threshold. If there is no significant opposition, the proposal immediately goes into the Timelock for eventual execution without any quorum requirements. If there is significant opposition, it goes through the normal governance process for a three-day vote to determine the final decision of the community.
There are existing optimistic governance solutions out there that could be utilized here including one that uses a combination of UMA’s Optimistic Oracle and the Safe Zodiac framework which OpenZeppelin has previously audited. It’s also possible to extend Governor Bravo directly to integrate a more native Optimistic Governance process. This could be done more easily following an upgrade to use OpenZeppelin Governor, a successor framework to Compound Governor Bravo that is built to be more modular and extensible for new functionality, for which a proposal by the ScopeLift team has already been accepted by CGP.
Takeaways
Implementing approach #1 will be a lighter lift and easier to implement. The changes will need to be deployed to the Configurator on every network. Given the lack of direct governance oversight, the assignment of this role needs to be thought through carefully including pro/cons of using an EOA or Safe and whether a Timelock should also be utilized.
Implementing approach #2 is a greater lift and requires substantial changes to the Governor framework. However, it does allow governance a greater say in each market parameter change with the opportunity to challenge any proposals made by the Market Admin that can go up for a vote if there is serious opposition. A proposed upgrade to Compound Bravo by Scopelift is already being funded by CGP and could also incorporate new functionality for an Optimistic governance track.
I think the key question for the rest of the community is whether the trade-offs of an easier implementation with Approach #1 is worth the reduction in governance oversight that Approach #2 is able to avoid but comes with a greater implementation effort and security impact.
We appreciate @DoDAO for their proactivity here and @cylon’s guidance from the OpenZeppelin team.
At Gauntlet, we agree that a more efficient process to reduce overhead would add value to Compound. From a market update perspective, a more streamlined process allows Compound to be more adaptive to changing market conditions as well as reduce resourcing costs for delegates.
Whether the community prefers Approach 1 (Update Configurator) or Approach 2 (Optimistic Governance), Gauntlet supports the solution as long as it leads to reduced overhead. We are happy to discuss and collaborate where needed to help bring this solution to fruition.
Hi Compounders. Unfortunately, an update of the Configurator contract will not solve the problem, because after the update of the Configurations, should be called deployAndUpgradeTo method at ProxyAdmin admin (Mainnet example of ProxyAdmin contract) which could be called only by Timelock. An update of Timelock seems like not the best solution because the contract is not upgradable and critical for the whole DAO infrastructure. Also, there should be an updated Configurator on 6 networks.
Update propose method:
4.1 If the proposal is created by FE address, then the review takes 20 hours, instead of 44 hours.
4.2 If the proposal is created by FE address, then voting time takes 1 day, instead of 3 days and 100-200K quorum, instead of 400K quorum.
Update queue method
5.1 If the proposal is created by FE address, then the queue takes 24 hours instead of 48 hours.
Also, we can update active proposals for FE members from 1 active proposal to 2-3 active proposals.
Current changes will decrease the proposal pipeline’s lifetime for Mainnet updates from 7 days to 3 days and for L2 updates - from 8 days to 4 days.
Note: New variable constants are example ones and can be changed. Note 2: The solution is the draft one and can require adding/updating additional constants/methods
As security measures, the discord bot for the governance feed can be updated and notify if FE address proposed not only updates of Configurator for faster delegators reaction.
The scope of updates is not only new Governor bravo implementation, tests and deployment scripts, but also requires the update of scenarios in the Comet repository.
Thanks, @dmitriywoofsoftware, you correctly pointed out that the additional changes needed to deploy the proxy were not captured. I will add that information, and it should not require Timelock modification.
Regarding Updating Governor Bravo:
We wanted to limit the number of changes. Updating Governor Bravo does provide a lot of flexibility, but also changes the core code of the governance process, thus creating a larger attack surface (I agree that we have timelock and pausable contracts to help mitigate issues in case anything goes wrong).
The ScopeLift team is working on an effort to update Governor Bravo to OpenZeppelin’s version. Updating Governor Bravo also means deviating a bit from the community-used version.
Configurator changes restrict the updates only to a few specific functions, preventing any future governance attacks.
Propagating configuration to all 6 chains is definitely suboptimal, but it’s a one-time change and is similar to other market/governance updates that we apply.
function changeProxyAdmin(TransparentUpgradeableProxy proxy, address newAdmin) public virtual onlyOwner
which can be used to update the admin, which can be a contract very similar to ​CometProxyAdmin but allows for upgrade from the alternate path/address. (So we don’t need to change timelock)
So the new path/address has very restrictive set of actions it can do, i.e. just update the market params, and deploy the comet based on the new configuration. These actions will be governed by a separate timelock, ensuring there is ample time to review changes before implementation. This setup circumvents the need for a full governance voting cycle, limits the changes/actions, and also adds a delay for review.
We have a few outstanding questions that the proposal description seems to not highlight.
“Grant the market admin role to an Safe address, which can be maintained by Gauntlet or other community members.” what is this Safe address, and who are the signers right now?
“Market Updates to the Configurator will go through a timelock, providing sufficient time for the community to review or even block the market updates via this alternate route.” What was the proposed timelock time, same as normal governance?
An update to the community on if anything has changed since this was last discussed over 4 months ago would be nice. Please outline exactly what will happen if the vote is passed, and what governance is deciding on.
Additionally, the title says “optimism” but nothing more about that. Is Optimism in reference to Optimistic approvals? or Optimism chain? We assume the chain but are not sure. It seems the discussion above hasn’t been “wrapped up” and ready for a governance vote, hence the lack of communication and then a governance vote out of the blue is concerning and confusing.
Thanks for keeping an eye and the questions. Here are the answers
Q1. - “Grant the market admin role to an Safe address, which can be maintained by Gauntlet or other community members.” what is this Safe address, and who are the signers right now?
A1. - Gauntlet members will own the market admin safe. All three signers will be from Gauntlet. Currently, DoDAO is one of the signers to oversee the process, but it will be completely transitioned to Gauntlet. If community members express concerns, it might make sense to update the safe to 3/5, and a member each from other contributing teams can be added as a signers.
Q.2. “Market Updates to the Configurator will go through a timelock, providing sufficient time for the community to review or even block the market updates via this alternate route.” What was the proposed timelock time, same as normal governance?
A.2. The current delay is 2 days. It’s configurable, and we can increase it if needed.
Q.3. An update to the community on if anything has changed since this was last discussed over 4 months ago would be nice. Please outline exactly what will happen if the vote is passed, and what governance is deciding on.
A.3. If the vote passes, Gauntlet, using the safe, will be able to update certain parameters on the markets, other than the list of parameters mentioned below. The Community Multisig or the main governance can pause this alternate governance track whenever they want.
List of parameters which Gauntlet can update:
function setSupplyKink(address cometProxy, uint64 newSupplyKink) external governorOrMarketAdmin
function setSupplyPerYearInterestRateSlopeLow(address cometProxy, uint64 newSlope) external governorOrMarketAdmin
function setSupplyPerYearInterestRateSlopeHigh(address cometProxy, uint64 newSlope) external governorOrMarketAdmin
function setSupplyPerYearInterestRateBase(address cometProxy, uint64 newBase) external governorOrMarketAdmin
function setBorrowKink(address cometProxy, uint64 newBorrowKink) external governorOrMarketAdmin
function setBorrowPerYearInterestRateSlopeLow(address cometProxy, uint64 newSlope) external governorOrMarketAdmin
function setBorrowPerYearInterestRateSlopeHigh(address cometProxy, uint64 newSlope) external governorOrMarketAdmin
function setBorrowPerYearInterestRateBase(address cometProxy, uint64 newBase) external governorOrMarketAdmin
function setBaseTrackingSupplySpeed(address cometProxy, uint64 newBaseTrackingSupplySpeed) external governorOrMarketAdmin
function setBaseTrackingBorrowSpeed(address cometProxy, uint64 newBaseTrackingBorrowSpeed) external governorOrMarketAdmin
function setBaseBorrowMin(address cometProxy, uint104 newBaseBorrowMin) external governorOrMarketAdmin
function updateAssetBorrowCollateralFactor(address cometProxy, address asset, uint64 newBorrowCF) external governorOrMarketAdmin
function updateAssetLiquidateCollateralFactor(address cometProxy, address asset, uint64 newLiquidateCF) external governorOrMarketAdmin
function updateAssetLiquidationFactor(address cometProxy, address asset, uint64 newLiquidationFactor) external governorOrMarketAdmin
function updateAssetSupplyCap(address cometProxy, address asset, uint128 newSupplyCap) external governorOrMarketAdmin
Here is the technical docs which outlines all the changes:
Q.4. Additionally, the title says “optimism” but nothing more about that. Is Optimism in reference to Optimistic approvals? or Optimism chain? We assume the chain but are not sure. It seems the discussion above hasn’t been “wrapped up” and ready for a governance vote, hence the lack of communication and then a governance vote out of the blue is concerning and confusing.
A.4. These “Market Updates - Alternate Governance Track” changes will be rolled out to one chain at a time. We are releasing it to Optimism first because there are frequent changes that Gauntlet would want to apply based on the incentives added by Optimism.
Last question I have is could you add the safe address here so we can take a look/for clarity, including the signers (you mentioned you were one of them right now)?
Here is the screen shot of all the signers. Its setup currently as 2/4. After the initial rollout, it can be completely taken over by Gauntlet with 2/3 as signers
As I have mentioned currently the deployment is just for Optimism. We have already deployed the safe for other environments also, which will be used in the future. Here are address of all the Safes
We agree with and voted for this proposal, which aims to accelerate decision-making within the DAO and enable more efficient utilization of community resources. This is an important move toward enhancing governance processes.
To complement this proposal, we’d like to suggest an additional idea. Ensuring transparency is essential, as participants may not always be aware of changes if propoer notifications are not set. It is essential to establish clear rules for notifying changes through the Forum or Discord channel, as well as mechanisms for reviewing change histories, such as implementing a dedicated dashboard for them.
Thanks for your consideration to the idea above in advance and we look forward to seeing the positive impact of this proposal.
We have been working on governance alerts already. We can definitely extend the functionality to include this also, and create a page where all the market updates via the new track can be shown.
