[Signal Request] Increase duration of governance security module?

The governance security module is currently set to 12 hours. This is barely enough time to prevent a governance attack. We had the duration set at 24 hours before Black Thursday March 12-13. Is it time to go back to a 24 hour delay?

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.

The most recent change to the delay occurred in the thread, Signal Request: Calibrating GSM delay in light of recent market events

  • Keep unchanged at 12 hours
  • Increase to 24 hours

0 voters

After two weeks, if there is support for a 24 hour delay then this matter can proceed to an on-chain poll.


I appreciate that things are a little hectic at the moment and that we’ve been playing fast and loose with the emergency signal requests, but could we try to stick to the practical guide as much as possible for the non-emergency changes, please.

Specifically in this case I’d like to see a summary of the pros and cons with relation to changing the delay, and some clear lines of progress. I know for some of us this is well-trodden ground, but that’s not necessarily the case for the newer members of the forum.


So close and lock this thread and try again?

I’m happy for you to edit this to take into account the requirements. You could replace the poll to something with more options, if you wanted. I don’t think that would strictly be a requirement though.

I’d suggest also adding more options than only the status quo plus one that is different, since there is a wide range of potential values for this. An “abstain” option might be useful too, for those paying attention but don’t feel they are sufficiently well informed.


Since there is no clear winner, I support an onchain poll with just those 2 options. I think we had a situation recently that anyone with >60.000 MKR could start the governance attack.

Should we have a procedure for dealing with the attack or we should rely on the Foundation to organize the defense?

1 Like

This is a pretty interesting question. Realistically at this stage the Foundation is going to take a large role in reacting to a governance attack, mainly because they have channels of communication to large Maker holders. That said, some sort of emergency notification procedure is a sensible idea, and will need to be implemented in the future.


Absolutely needed is a kind of Maker operational alarm system that anyone can opt into to receive alarm updates (where they can even manage a subset of all available alarm types). I wondered if someone could put up a new executive for vote and who would notice when. I see the bot posting a new executive in rocketchat but does this work if someone else tries to put up an executive themselves?

As to the GSM. Personally I really want to revisit what are the actions that wait for the GSM and ones that don’t as we now have certain actions that DO NOT need to wait for the GSM delay.

Because we don’t have a formal Maker operational alarm system, we don’t have emergency response tests (to determine how fast X amount of MKR could be mustered for an emergency) to measure MKR governance emergency response times.

All of this needs to be factored into this whole GSM and emergency response measures.

Something I never got to was the whole analysis of when to use an ES and how it affects the community. I have come to the conclusion that unless the system already has lost more than 1/4-1/2 of its value will an ES be used and even then the protocol will have lost so much value that no-one will pull the trigger on the 50K MKR required to pull the ES trigger here.

There is a lot to consider vs. just the GSM delay time here but really we are back to re-analyzing what we have in terms of governance security (or not) and what should or should not have a delay. I think we covered most of the discussion regarding the need for a GSM, but I still don’t think we have settled on a delay time and this is mostly in relation to the fact that we never do ‘test emergencies’ out of the blue and at odd times/days to measure what the community emergency response IS. Until we get at least a baseline measurement of this response personally I have no clue what we need to set the GSM to.

1 Like

Status quo wins.

Thank you for participating.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.