[CMC20] [RFC] Proposal to extend the onchain voting and execution process

Summary

This proposal seeks to extend the CMC20 onchain governance process from 48 hours to 72 hours by increasing the review period, voting period and execution delay to 24 hours each. The objective is to strengthen governance security by providing the core team, governors and the wider community with additional time to identify and respond to malicious proposals before execution.

Problem Statement

Currently the onchain voting and execution process for CMC20 takes a total of 48 hours, 2 hour review period, 22 hour voting period and 24 hour execution delay. While this serves to quickly enact administrative changes in a dynamic environment, recent governance attacks have demonstrated that there is appetite to exploit DTFs and that this is a viable attack vector.

While Reserve benefits from an active governor community and oversight from the core team, extending the governance process provides an additional layer of protection against malicious proposals, particularly during periods of reduced community participation e.g weekends.

Rationale

This RFC proposes that the onchain voting and execution process for CMC20 is extended to 72 hours total, broken down into 24 hours each for the review, voting and execution delay periods.

A 72-hour governance process has already been adopted by several other Index DTFs and provides sufficient time for proposals to be reviewed across multiple time zones and over weekends.

Risks

The primary risk of this proposal is reduced governance agility, as rebalances and other administrative changes will take longer to progress from submission to execution.

While a longer process cannot fully prevent malicious proposals, it provides governors, delegates and the wider community with additional time to identify and respond to suspicious activity before execution.

Given the recent governance attack and the relatively low frequency of governance activity within CMC20, this trade-off is considered reasonable.

Conversely, maintaining the current governance parameters maintains governance agility but leaves CMC20 more exposed to well-timed governance attacks, particularly during periods of reduced community oversight.

Conclusion

Extending the governance process from 48 to 72 hours represents a modest reduction in governance agility in exchange for improved security. Given recent governance attacks and the low frequency of governance actions within CMC20, the proposed change is considered a prudent safeguard that better aligns CMC20 with governance standards adopted across the wider DTF ecosystem.

Poll

  • Yay, proceed with governance flow changes
  • Nay, make no change to the current governance flow
0 voters
1 Like

As a governance facilitator we’re extremely excited and happy to see another index DTF embrace transparency by surfacing decisions on the forum for community discussion.

The Forum is the place for the RSR holder and staker community to congregate and to get necessary information on what’s going on and what’s coming.

This function is vital for community health, and it’s great to see CMC20 going a step forward here.

Thanks @ham for the proposal.

1 Like

I fully agree it is great to see governance for Index DTFs is becoming more transparent by starting to bring proposals to the forum and generally follow the same approach for the (more mature) Yield DTFs.

Looking at the contents of the proposal, I do think it is important to highlight there are three different governance types and associated timelines for each Index DTF:

  • Basket Governance, which is about changes to the basket of the Index DTF
  • Non-basket Governance, which is about changes to fees and voting parameters
  • DAO Governance, which is about vote locking periods and approving revenue tokens.

See details for the first two below, more here:

In this proposal, I think you are focusing on Basket Governance. For this type for CMC20, the periods are indeed 2 hours, 22 hours and 24 hours for voting delay, voting period and execution delay respectively. For Non-Basket Governance for CMC20, for instance, these currently are 2 days, 3 days, 2 days respectively. If my assumption is right that you are focusing on Basket Governance periods, I would recommend to make that explicit in the proposal.

If indeed your proposal refers to CMC20 Basket Governance, I am (slightly) in favor. It is good to have more time to invite delegates and the entire community to weigh in and actively agree to the proposal. Having said that, considering this is ‘just’ about the Basket Governance (for Non-Basket and DAO Governance the periods are already longer than what is proposed here) and CMC20 is meant to ‘just’ follow the top-20 (non-stable) tokens, there is not so much room for discussion given the mandate/purpose of CMC20. With the extended periods, we do have a better opportunity to discover malicious/undesired basket changes. So, in favor(ish), but I do think the more important attack vectors are on other parameters than basket-changes and these governance types already benefit from longer periods.