DoDAO has been examining various areas where improvements can be made to governance in Compound through tooling or automation. A significant issue raised repeatedly by many members concerns the time …
01Summary
Compound proposes creating an alternate governance track for market parameter updates to reduce governance overhead and speed up decision-making. Currently, 70-90% of proposals are market updates costing ~$300k/year in review effort with minimal community validation. The proposal grants market admin role to a Safe address (maintained by Gauntlet or others) with market updates going through a timelock for community review before execution. On-chain action configures the Configurator contract with new proxy admins and market admin permissions.
- Type
- governance change
Key changes
- Establish alternate governance track for market parameter updates bypassing standard governance lifecycle(high)
- Grant market admin role to Safe address (Gauntlet or community members) instead of going through full governance(high)
- Implement timelock for market updates to allow community review and blocking capability(high)
- Update Configurator contract with new proxy admins and permission checker(high)
- Redirect governance focus from routine market updates to strategic decisions (partnerships, new chains, assets)(medium)
Notable concerns
- Centralization risk - market admin role concentrated in single Safe address
- Reduced community participation in market update validation compared to full governance process
- Potential reduction in thorough review of market parameters despite timelock safeguard
- Governance process fragmentation with parallel tracks may create complexity
Generated by Kvorum
02Description
DoDAO has been examining various areas where improvements can be made to governance in Compound through tooling or automation. A significant issue raised repeatedly by many members concerns the time and effort required to apply Market Updates.
Currently, approximately 70-90% of the proposals pertain solely to updating market parameters. Gauntlet uses analytics and algorithms to determine new parameters based on current market conditions. These proposals are highly specific and require unique skills for validation. So far, we have seen minimal participation from other community members or teams in validating these parameters.
Assuming the total cost of reviewing a proposal (including the effort of all delegates) is $2,000 per proposal, we are spending upwards of $300,000 per year on a process that currently acts more as a friction layer without much safeguard, as these market update proposals are rarely reviewed thoroughly.
This not only slows down the process but also diverts focus from reviewing essential proposals related to new partnerships, the addition of new chains, and the introduction of assets, etc.
We propose a parallel process specifically for market updates that can bypass the normal governance lifecycle. This would enable us, as a Compound community, to move faster and concentrate on the most critical decisions.
This proposal has already been discussed here - https://www.comp.xyz/t/market-updates-alternate-governance-track/5379
The forum post includes two solutions, and OpenZeppelin has provided details and feedback on those solutions.
After discussing with OpenZeppelin, DoDAO and OZ together believe that given the amount of changes, updating the Configurator could be the best solution. OpenZeppelin mentioned a couple of important points in the forum post:
- Grant the market admin role to an Safe address, which can be maintained by Gauntlet or other community members.
- 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.
03Mismatch analysis
The proposal describes a strategic initiative to create a faster governance track for routine market-parameter updates by (1) granting a market admin role to a Safe address and (2) routing Configurator changes through a timelock for community oversight. The single decoded action is a cross-chain sendMessage carrying an encoded batch that performs changeProxyAdmin (x4), an upgrade call, and setMarketAdminPermissionChecker. These technical steps are consistent with implementing new admin/timelock infrastructure for the Configurator, which aligns with the described intent — proxy admin reassignment and installation of a permission-checker contract plausibly correspond to establishing the new admin/timelock gating described in the proposal. However, the raw addresses in the calldata (e.g., the new proxy admin and the permission-checker target) cannot be independently confirmed from the prose to be the specific 'Safe' address or 'timelock' contract named in the description, since the description provides no addresses to cross-check. This is typical for a technical implementation of a previously-discussed forum proposal and falls within legitimate summarization rather than a material contradiction. No numeric parameter mismatches, redirected funds, or unrelated grants were found. Given the opacity of the encoded calldata and lack of explicit on-chain labels, confidence is medium rather than high, but nothing contradicts the stated intent, so the overall assessment is consistent with only a minor documentation gap noted.
Discrepancies
- lowomitted in description
The description speaks in high-level strategic terms (granting admin to a Safe, adding a timelock) but never mentions that execution occurs via a cross-chain bridge message, nor does it enumerate the specific technical steps actually being taken (four proxy-admin transfers, an implementation upgrade, and installation of a permission-checker contract). This is a reasonable summarization for a governance narrative, but delegates cannot verify from the prose alone that the specific addresses being wired in (e.g., the permission-checker and new proxy admin) correspond to the 'Safe' and 'timelock' described, since the calldata only exposes raw addresses without labels.
“Grant the market admin role to an Safe address, which can be maintained by Gauntlet or other community members.”
Generated by Kvorum
04Actions
- Target
- 0x25ac…5fa1
- Value
- 0 wei
- Function
- sendMessage(address,bytes,uint32)
- Arguments
{ "0": "0xC3a73A70d1577CD5B02da0bA91C0Afc8fA434DAF", "1": "0x000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000001600000000000000000000000000000000000000000000000000000000000000240000000000000000000000000000000000000000000000000000000000000054000000000000000000000000000000000000000000000000000000000000000060000000000000000000000003c30b5a5a04656565686f800481580ac4e7ed1780000000000000000000000003c30b5a5a04656565686f800481580ac4e7ed1780000000000000000000000003c30b5a5a04656565686f800481580ac4e7ed1780000000000000000000000003c30b5a5a04656565686f800481580ac4e7ed17800000000000000000000000024d86da09c4dd64e50db7501b0f695d030f397af00000000000000000000000084e93ec6170ed630f5ebd89a1aae72d4f63f27130000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000120000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000001e00000000000000000000000000000000000000000000000000000000000000240000000000000000000000000000000000000000000000000000000000000028000000000000000000000000000000000000000000000000000000000000000216368616e676550726f787941646d696e28616464726573732c61646472657373290000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000216368616e676550726f787941646d696e28616464726573732c61646472657373290000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000216368616e676550726f787941646d696e28616464726573732c61646472657373290000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000216368616e676550726f787941646d696e28616464726573732c61646472657373290000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000187570677261646528616464726573732c6164647265737329000000000000000000000000000000000000000000000000000000000000000000000000000000287365744d61726b657441646d696e5065726d697373696f6e436865636b6572286164647265737329000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000120000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000001e0000000000000000000000000000000000000000000000000000000000000024000000000000000000000000000000000000000000000000000000000000002a000000000000000000000000000000000000000000000000000000000000000400000000000000000000000002e44e174f7d53f0212823acc11c01a11d58c5bcb00000000000000000000000024d86da09c4dd64e50db7501b0f695d030f397af0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000995e394b8b2437ac8ce61ee0bc610d617962b21400000000000000000000000024d86da09c4dd64e50db7501b0f695d030f397af0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000e36a30d249f7761327fd973001a32010b521b6fd00000000000000000000000024d86da09c4dd64e50db7501b0f695d030f397af000000000000000000000000000000000000000000000000000000000000004000000000000000000000000084e93ec6170ed630f5ebd89a1aae72d4f63f271300000000000000000000000024d86da09c4dd64e50db7501b0f695d030f397af000000000000000000000000000000000000000000000000000000000000004000000000000000000000000084e93ec6170ed630f5ebd89a1aae72d4f63f2713000000000000000000000000371db45c7ee248daff4dc1ffb67a20faa0ecfe02000000000000000000000000000000000000000000000000000000000000002000000000000000000000000062dd0452411113404cf9a7fe88a5e6e86f9b71a6", "2": "2500000" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- Market Updates - Alternate Governance Track ↗discourse · high confidence
Arguments for
- Routing routine market parameter updates through full governance imposes significant time, coordination, and gas costs (potentially $2000+ per proposal) that could be avoided with a faster alternate track.— DoDAO, cylon, Gauntlet
- A faster, dedicated pipeline lets Gauntlet respond quickly to changing market conditions and risk events, improving protocol safety and capital efficiency.— Gauntlet, woof, sharp
- Security is preserved because the new track restricts Gauntlet to a narrow whitelist of parameter-setting functions, uses a timelock delay, and grants cancellation rights to a Proposal Guardian/community multisig.— robinnagpal, woof, DoDAO
- The design has already been implemented and audited (OpenZeppelin reviews) and successfully deployed on Optimism, cutting update time from ~10 days to ~2 days without issues.— woof, robinnagpal, sharp
- Existing Seatbelt-style monitoring, checks, and Discord alerts already give the community visibility into alternate-track proposals, addressing transparency needs.— robinnagpal, DoDAO
- Adding clearer notification rules and a dashboard for change history would further strengthen community awareness of updates made via the new track.— Tane, DoDAO
Arguments against
- Bypassing full governance for market updates reduces direct community oversight and voting control over parameter changes.— cylon
- The simple Configurator-only approach is technically insufficient because applying changes still requires a ProxyAdmin upgrade callable only by the Timelock, complicating the 'bypass governance' goal.— dmitriywoofsoftware
- Concentrating signing authority in a small Gauntlet-controlled Safe (moving toward 2/3 or 3/5) raises centralization and trust concerns over who controls market parameters.— PGov
- The proposal went to an on-chain vote after a long silence and with unclear details (e.g., ambiguous 'Optimism' title, timelock duration, signer identities), creating confusion about what governance was actually approving.— PGov
Unresolved concerns
- Whether Tally or a custom platform should be built to give the community native visibility into pending optimistic/alternate-track proposals remains an open infrastructure decision.— woof, robinnagpal
- Final composition and long-term governance of the Market Admin Safe (number of signers, inclusion of non-Gauntlet parties) has not been settled.— PGov, robinnagpal
- Whether Rewards V2 speed parameters (setBaseTrackingSupplySpeed/BorrowSpeed) should be added to the alternate track's scope is still under community discussion.— woof
- Prioritization of which chains should next receive the Alternate Governance Track deployment has not been decided.— woof
- Cross-chain execution status tracking (proposals showing 'executed' on Ethereum but not yet on L2) was flagged as a gap, with only partial confirmation that it's fully resolved.— woof, robinnagpal
Notable participants
- DoDAOOriginal proposer who identified the governance overhead problem and proposed the Configurator-based bypass approach.
- cylonOpenZeppelin representative who provided detailed technical analysis of both proposed approaches and their trade-offs.
- GauntletRisk manager who would operate the new market admin role and expressed general support for either approach.
- dmitriywoofsoftwareWOOF! team member who identified a technical flaw in the Configurator-only approach and proposed an alternative Governor Bravo modification.
- robinnagpalDoDAO lead who refined the technical design, answered community questions, provided safe/signer details, and reported on deployments and audits.
- PGovCommunity member who raised pointed questions about transparency, safe signers, and the timelock/chain naming ambiguity before the governance vote.
- TaneSupportive voter who suggested adding transparency mechanisms like notifications and a change-history dashboard.
- woofWOOF! team member who provided a post-deployment infrastructure review, flagged monitoring gaps, and proposed extending scope to Rewards V2.
- sharpCommunity member who affirmed the alternate track's benefit for faster market management on deployed chains.
- jbass-ozOpenZeppelin auditor who confirmed audit results and stated no additional infrastructure was needed for monitoring.
Generated by Kvorum
08Similar proposals
- compoundexecutedAlternate Governance track for Market Updates - Optimism97%
- compoundexecutedAlternate Governance track for Market Updates - Mantle96%
- compoundexecutedPause Supply for Compound Assets58%
- compoundexecutedSet Pause Guardian to Community Multi-Sig54%
- compoundcanceledUnpause Seize50%
- compoundcanceledUnpause Seize50%
- lidoexecutedOmnibus vote: 1) Grant PAUSE_ROLE on WithdrawalQueue 0x889edC2eDab5f40e902b864aD4d7AdE8E412F9B1 for the new GateSeal 0x79243345eDbe01A7E42EDfF5900156700d22611c;47%
- compoundexecutedResume cUSDC minting37%
- lidoexecutedUnpause protocol deposits37%