Market Updates - Alternate Governance Track

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.


There are multiple ways to enable a bypass of governance for market updates:

  1. 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.

    Here is how the code changes can look like

    comet/contracts/Configurator.sol at main · compound-finance/comet · GitHub

  2. 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.

Please share your feedback.


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.


  • 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.