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.