Market Updates - Alternate Governance Track

[DoDAO]

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:

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.

[cylon]

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.

[Gauntlet]

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.

[dmitriywoofsoftware]

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.

What WOOF! team suggests

Update only Governor Bravo implementation on Mainnet.

1. Add an array of fast executors. (farther FE)
2. Add method to whitelist FE
3. Add method to de-whitelist FE
4. 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.
5. Update queue method
   5.1 If the proposal is created by FE address, then the queue takes 24 hours instead of 48 hours.
6. 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.

[dmitriywoofsoftware]

One more possible solution is to remove review and queue steps but stay with a 3-day voting period and 400K quorum.

Push proposal → instantly start voting → 3 days voting + 400K quorum → end of voting → instant execution without pushing in queue.

[robinnagpal]

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:

1. 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).
2. 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.
3. 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.

[robinnagpal]

CometProxyAdmin has

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.

[PGov]

We see that the governance vote is live here.

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.

[robinnagpal]

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:

Market Admin - Changes - V1

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.

Here are the posts of the Audits

Market Admin Audit

Summary Timeline: From 2024-09-16 To 2024-09-25 Total Issues: 5 (4 resolved) Low Severity Issues: 5 (4 resolved) Scope OpenZeppelin started the review on pull request #1 of the RobinNagpal/comet repository at commit bb32bfb, and later on we were requested to confirm the changes at commit 368842d and commit f05d35c. Under review was the introduction of an alternative Compound governance process that would facilitate quicker and more efficient upgrades to the Comet markets. In scope were…

Optimism Market Admin Migration Review

Summary Timeline: From 2024-11-11 To 2024-11-12 Total Issues: 0 (0 resolved) Scope We reviewed the calldata generated by the Optimism migration script in PR#1 at the 607ce91 commit. Migration review We reviewed the Market Admin migration for the Optimism network. During the migration review, we analyzed the following aspects: Migration Call Sequence: The migration follows the expected sequence, updating the Configurator to the new implementation and all Comet market contracts on Optimi…

@jbass-oz @dmitriywoofsoftware @pauljlei @sharp Please add if anything is missed.

[PGov]

Thanks for the prompt response!

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)?

[robinnagpal]

Hi @PGov ,

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

Gauntlet EOA addresses:

0xDD659911EcBD4458db07Ee7cDdeC79bf8F859AbC

0xda32C5AEE8Fc5C51Ed9a99f5608c33f435F740B4

0x1D8e0b8F4CEd9262C9ac0c0870BF8B45D74ad9D9 

DoDAO

0x47526FDDBA0A5a7ef001FaaD4836b771B3e92522

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

Mainnet - 0xA1C7b6d8b4DeD5ee46330C865cC8aeCfB13c8b65

Base - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

OP - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

ARB - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

SCROLL - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

Mantle - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

Polygon - 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e

[Tane]

Thanks @DoDAO and @robinnagpal for the proposal.

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.

[DoDAO]

Makes complete sense @Tane. // cc @cylon

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.

[robinnagpal]

Here is the proposal for Mantle

Tally | Compound | Alternate Governance track for Market Updates - Mantle

For optimism this code is already deployed

Here is the link to audit report - Mantle Market Admin Migration Review

[sharp]

Thank you @robinnagpal for these deployments. the Alt governance track will help us in moving a lot faster on the Markets on deployed chains

[woof]

Alternate Governance Track: Infrastructure Readiness

TL;DR: DoDAO has successfully deployed the Alternate Governance Track infrastructure on Optimism, enabling Gauntlet to update market parameters in 2 days instead of 10 days. However, before expanding to other chains, WOOF! wants to remind the community what the new alternative governance pipeline is and how it can speed up protocol management.

Background: Solving Governance Bottlenecks

The Alternate Governance Track was originally proposed by DoDAO and successfully deployed on Optimism to address a fundamental challenge in Compound’s multi-chain strategy: the governance bottleneck for market parameter updates.

Gauntlet, as Compound’s risk management partner, regularly needs to adjust market parameters based on real-time market conditions and risk analysis. Previously, every parameter adjustment required the full governance process, creating significant delays that could impact protocol safety and capital efficiency.

Two Governance Pipelines

Traditional Governance Pipeline (Current on Ethereum)

Process Flow:

1. Proposal pending period (~2 days): Community member creates governance proposal on Ethereum
2. Voting Period (~2-5 days): Community votes, with automatic 48-hour extension on reaching quorum
3. Proposal in queue (2 days): Proposal queued and executed on Ethereum Timelock
4. Cross-Chain Relay (1 day): Message relayed to L2 and executed on local Timelock

Total Timeline: ~7-10 days

Pros:

• Community controls voting through a transparent governance process
• Full decentralized oversight of all changes
• Proven security model with extensive community participation

Cons:

• Takes significantly more time (7-10 days vs 2 days)
• Consumes more gas across multiple transactions
• Relies on cross-chain bridge infrastructure for L2 execution
• Can delay critical risk management responses to market volatility
• Overwhelm the DAO with regular proposals

Alternate Governance Pipeline (New on Optimism)

Process Flow:

1. Direct Submission: Gauntlet submits the proposal directly to MarketUpdateTimelock on L2
2. Timelock Period (2 days): Proposal queued with community oversight window
3. Execution: Anyone can execute after the timelock expires, applying parameter changes

Total Timeline: ~2 days

Pros:

• Actions performed entirely on the L2 network without cross-chain complexity
• Significantly faster response time for risk management
• Community retains cancellation rights through multiple mechanisms
• Lower gas costs and operational overhead

Cons:

• Currently, only Gauntlet multisig can propose updates
• Requires a monitoring infrastructure for community oversight

Security & Control

The Alternate Governance Track maintains security through multiple cancellation mechanisms:

Cancellation Authority:

• Proposal Guardian: Designated multisig wallet for emergency intervention
• Gauntlet: Can cancel their own proposals if needed

Parameter Scope Restrictions: The system only allows updates to specific market parameters, not fundamental protocol changes. Gauntlet can update the following functions:

• Interest Rate Parameters:

  • setSupplyKink / setBorrowKink - Kink points in interest rate curves
  • setSupplyPerYearInterestRateSlopeLow/High / setBorrowPerYearInterestRateSlopeLow/High - Interest rate slopes
  • setSupplyPerYearInterestRateBase / setBorrowPerYearInterestRateBase - Base interest rates

• Collateral & Risk Parameters:

  • updateAssetBorrowCollateralFactor - Borrowing collateral factors
  • updateAssetLiquidateCollateralFactor - Liquidation collateral factors
  • updateAssetLiquidationFactor - Liquidation incentive factors
  • updateAssetSupplyCap - Asset supply caps
  • setBaseBorrowMin - Minimum borrow amounts

Critical Infrastructure Concerns

Despite the successful Optimism deployment, several infrastructure gaps need addressing before broader adoption:

1. Community Monitoring Platform

Problem: Currently, the community has no dedicated interface to monitor pending Gauntlet proposals through the Alternate Governance Track.

Tally, the primary governance platform used by Compound, does not yet support this optimistic governance functionality. This creates a critical visibility gap where proposals could be submitted and executed without adequate community awareness.

Potential Solutions:

• Tally Integration: Work with Tally to add native support for monitoring optimistic governance proposals
• Custom Platform: Develop a dedicated monitoring interface that displays pending proposals and enables community interaction

WOOF! Is happy to help with any Governance platform to integrate new functionality using WOOF! capacity. If you are interested in integration, reach out to dmitriy@woof.software or via telegram: @dmitriywoof.

2. Cross-Chain Governance Support

Problem: Tally currently doesn’t support the two-step execution required for cross-chain proposals. Proposals may show as “executed” on Ethereum while remaining unexecuted on the target L2 chain.

Impact: This has already caused issues where governance proposals passed on Ethereum but weren’t executed on destination chains, creating incomplete deployments.

Solutions Needed:

• Enhanced cross-chain execution tracking in governance platforms
• Automated L2 execution triggers after Ethereum execution
• Clear status indicators for multi-chain proposal states

WOOF! Is happy to help with any Governance platform to integrate new functionality using WOOF! capacity. If you are interested in integration, reach out to dmitriy@woof.software or via telegram: @dmitriywoof.

3. Security Team Monitoring

Existing Infrastructure: OpenZeppelin has confirmed they have proper infrastructure to monitor proposals, and there are existing notification systems, including a Discord bot developed by community members for real-time alerts.

Additional Questions for Auditors: Do security teams and auditors require specialized infrastructure beyond existing solutions to monitor these optimistic governance proposals?

4. Gauntlet Operational Readiness

Gauntlet has confirmed operational readiness and has successfully used the system on Optimism. However, as we expand to additional chains, we should ensure:

• Standardized operational procedures across all chains
• Clear escalation paths for emergency situations
• Regular internal and community communication about the parameter update rationale

5. Rewards V2 Integration

With the introduction of Rewards V2 functionality, there’s an opportunity to expand the Alternate Governance Track to include reward speed management. Since reward speeds are directly connected to Rewards V2 and require frequent adjustments based on market conditions, allowing Gauntlet to update these parameters through the optimistic governance track would provide additional operational efficiency.

This enhancement would extend the current parameter scope to include more granular control over incentive mechanisms while maintaining the same security and oversight framework.

Restrictions will be extended with setBaseTrackingSupplySpeed / setBaseTrackingBorrowSpeed parameters.

Community Input Needed

We’re seeking community feedback on several critical questions:

1. Governance Infrastructure: Should we prioritize Tally integration or develop a standalone monitoring platform? What specific features are most important for community oversight?
2. Security Requirements: What additional monitoring or alert capabilities do auditors and security teams need?
3. Chain Prioritization: Which chains should receive priority for Alternate Governance Track deployment based on TVL and risk management needs?
4. Rewards speed configurations: Should the solution support the management of the speeds?

Next Steps

The Alternate Governance Track represents a significant improvement in Compound’s operational efficiency while maintaining security through multiple oversight mechanisms. However, the infrastructure concerns outlined above must be addressed to ensure responsible deployment across the multi-chain ecosystem.

Successfully Deployed:

• Optimism: Fully operational with proven track record
• Core Contracts: Audited and battle-tested infrastructure

Pending Community Decision:

• Governance platform integration strategy
• Chain deployment prioritization
• Cross-chain deployment framework (allows for deploying proposals more securely and faster - there will be a separate post)
• Enhanced monitoring capabilities

The post can be a good starting point for raising a new topic for discussion - reconsider the pipeline for deployment of collaterals and markets to make it more time-sensitive and convert the 7-10 days pipeline to at least a 4-6 days flow.

[robinnagpal]

Thank you, @woof and @dmitriywoofsoftware, for providing support with rolling out the Alternate Governance Track across various chains.

There is already robust tooling in place for analyzing the Alternative Governance Track. The checks currently run on both main and alternative proposals include:

Checks that currently run on main or on alternative proposals are

1. Comet Related Checks - For each of the market parameter changes within the proposal, a sentence based description is produced by the formatters (from the function signature, targets and calldata - after normalization of the values and unit conversion if needed). Raw values are also presented for cross-checking. Also wherever possible, on-chain data is fetched and a comparison is made between the old and new value and the percentage change is reported.
2. Decode calldata check
3. Logs check
4. Simulation failure check
5. Slither check
6. Solc check
7. State changes check
8. Targets no self-destruct check
9. Value required check
10. Targets verified on the respective chain explore

All of the checks that we’ve built into Seatbelt are now applied in this new track as well. We receive alerts for these in Discord, and detailed reports are generated automatically.

For example:

• See this Discord alert: https://discord.com/channels/402910780124561410/974392321242169354/1379907835886047282
• See this report: https://compound-governance-proposals.s3.amazonaws.com/all-market-update-proposals/optimism/5.pdf

Thus, the following requirements have already been implemented:

1. Community Monitoring Platform
2. Cross-Chain Governance Support.

[jbass-oz]

@woof

Additional Questions for Auditors: Do security teams and auditors require specialized infrastructure beyond existing solutions to monitor these optimistic governance proposals?

No additional infrastructure needed, only the contract addresses.