Signal Request: Calibrating GSM delay in light of recent market events

Overview

During the market collapse, the Governance Security Module (GSM) delay was decreased to 4 hours from 24 hours. A lot of discussion has occurred on the trade-offs between a short and long delay, so I’ll just do a quick summary below.

A shorter delay allows for governance votes to cast faster. However, it also allows a shorter timeframe to defend against governance attacks. The 4 hour delay was helpful during the market collapse when the ETH price was fluctuating wildly.

A longer delay helps protect the protocol against governance attacks. There is simply more time allotted to respond to adverse governance actions. During the market collapse, the 24 hour delay presented a risk as the mitigating changes we used to stabilize the protocol could not be applied with urgency.

This signal is requested to gauge an appropriate GSM delay based on recent experiences. Should you favor a longer delay than listed, please select other and provide your rationale in the discussion.

Things to consider (not exhaustive!) as we search for the right balance:

  • Are we stabilized or should we expect more volatile market activity prompting another GSM decrease?
  • If we keep the delay low, what kind of governance attacks are we subject to?
  • If we set the delay high, how will we respond if we enter another volatile period?

Resources to help inform your choice:

  • https://mkr.fyi/ (mkr liquidity section) to see available MKR liquidity on various pools

Additional reading:

Thank you kindly for your attention.

  • 4 hours (current)
  • 8 hours
  • 12 hours
  • 24 hours (previous)
  • Other

0 voters

3 Likes

Hehe forgot I can choose two options! 12 was my original choice since responsiveness still seems important with the high uncertainty in the world, and I assumed that foundation people have some sort of notification security system in place, so I figured 12h would be enough to decide on emergency ES (they can trigger it themselves with multi sig if need be). 24 hours also makes sense to me too, less rushed decision making. Regardless I am guessing. If anyone is doing better than guessing please share.

I’m mostly on the same page as @Mitote . Doesn’t feel like anything less than 12 hours is realistically enough to react to a governance attack.

Lower bounds might help in the event of another serious market event, but it’s far from certain that it would and there are measures in place that don’t require us to wait for the GSM delay to activate.

1 Like

Summary

The vote has concluded with 19 voters and 26 total votes.

The two options that received the highest vote percentages:

  • 24 hours (previous GSM) at 47%
  • 12 hours at 36%

Discussion in the thread was limited, and those that commented appeared to agree that 12 hours was the minimum that should be considered as that is a realistic timeframe to respond to a governance attack.

*Discussion in the Rocketchat #governance-and-risk channel revolved around 24 hours being a realistic time period as it provided sufficient time for MKR holders to muster the 50k MKR vote threshold to trigger Emergency Shutdown (ES) in the event of a governance attack.

A few contributors suggested GSM delays beyond 24 hours in the forum thread although there appeared to be consensus that moving to a delay of that length should occur in the medium to long-term.

*Discussion begins at the linked comment in the #governance-and-risk channel and continues thereafter.

On-chain Vote Summary

Winning proposal is 12 Hours with 98.15% of the vote (23,613.85 MKR)

  • 12 Hours 23,613.85 MKR (98.15%)
  • 445.54 MKR (1.85%)

The change was reflected in this linked spell.

4 Likes

I’d like to see the on-chain vote with those options (maybe also 48 hours) and not just voting Yes/No and bundling that into next exec vote.

I disagree. We can already increase the delay again, but let’s move back to 24 hours ASAP.

Nevermind, I guess the poll is already up.

I agree. Ranked poll choice is probably not available yet, right?

The on-chain poll only includes options for 12 and 24 hours. It would be nice to always include an on-chain option to stick with the current settings, that way it doesn’t seem like we’re forcing a change on MKR holders.

Yeah, agree. Imo, this should have been ‘24 hours? yes/no’ based on the previous convention around polling. If that 24 hours had failed, we maybe could have tried 12 hours next week, though frankly neither of these proposals got over 50% of the forum vote.

I would have preferred that the forum polling stage had been extended and interested parties started campaigning to bring people into consensus (ie >50% on one of the options.) But this takes longer and people are too used to FPTP type polls.

I don’t think yes/no votes are best examples of decentralized governance. I’m glad that the we are offered at least two numeric choices (12/24). I’d like to see more of that approach + an option to stick with the current settings if applicable.

Yes, that should be a standard for all polls where applicable.

Good point. I should’ve included “no change” as an option. I’ll include that option in the future. If anyone feels strongly about staying, or returning, to 4 hours we can continue that discussion.

I think 4 hours is very dangerous - all collateral is at stake because there are scenarios (think Covid-19, lockdowns, network failures…) where the MKR holders might not be able to prevent the attack in time.

I disagree if the content of the yes/no vote has come out of a prior vote with greater than 50% agreement. With more options you turn the poll into FTFP, which historically has the potential to produce outcomes that a majority dislike.

One solution to this is ranked polling on-chain.

1 Like

Yes. I voted for 4h and 8h, but i’ve changed my mind after more thought.
Now, i would vote for 12h, wait 2-3 months (just to see in what state are world markets - how volatile), then go to 24h, if there is not very volatile situation.

It is dangerous. It served its purpose during the market collapse, but in the current state requires constant vigilance. Mobilizing in 4h would be difficult.

I am an advocate for incremental governance changes, so I voted 8h and 12h. The discussion in the forums, rocketchat, and this thread brought up a good point about 12h being the minimum timeframe we can reasonably expect to mobilize MKR against a critical governance attack.

If anyone has feedback on how this process was carried out, or any feedback for me specifically, I would appreciate if it could be shared in this thread. As others have suggested, in due time we can incorporate any feedback and start the process again to adjust the delay based on more recent information.