Governance Security Module (GSM) Adjustment


The Governance delay period (GSM) was designed to give the MKR token holders a chance to review any changes that will go into the Maker Protocol and act accordingly if those changes are deemed malicious. The current governance delay period is set to 72 hours. This period was established to allow the community to take more time to mitigate technical errors, oracle malfunctions, or deal with sophisticated attacks on the system.

The Smart Contracts Domain team has determined that a governance delay period of 48 hours provides a better balance of risks between governance attack mitigation and emergency protocol intervention than the current 72 hour delay period. In general, the choice of 48 hours provides a 24 hour period to communicate the situation to the Maker Community and a 24 hour period for the governance community (MKR holders) to adequately prepare for voting once they have been made aware of the situation at hand.

Main Considerations

The two primary risk considerations to find a balance between are:

  1. Governance Attack Risk: The governance attack risk, while reduced after DsChief 1.2 has been implemented, is still a risk that needs to be mitigated. More specifically, the way in which MKR holders mitigate a governance attack is by re-taking the hat and then using the remaining time to attempt to drop the malicious action from occurring, and if that fails, triggering an Emergency Shutdown of the Maker Protocol.
  2. Emergency Protocol Intervention Risk: There is a risk that MKR holders need to intervene to remedy bugs or misconfigurations in the Maker Protocol codebase. The longer the delay is, the more secure the Maker Protocol is against any governance attack risk. Still, the Smart Contracts Domain team is less likely to be able to remediate any protocol problems before they can have widespread consequences. A few select modules exist outside the GSM delay, such as the Emergency Shutdown Module (ESM) that would require the Smart Contracts Domain Team to intervene before the GSM delay, but keeping this delay shorter helps the team intervene in situations that cannot be foreseen or predicted.

Overall, the Smart Contracts Domain team believes a 48 hour period provides sufficient time to respond to a governance attack as well as provide an Emergency Intervention when necessary.

Next Steps

With the upcoming Executive Vote for the Chief 1.2 upgrade occurring this Wednesday, December 2, the Smart Contracts Domain team will add an adjustment to the GSM delay to 48 hours as a balance between these two risks mentioned above. This action will reduce the GSM delay from 72 hours to 48 hours after the DSChief 1.2 upgrade has mitigated some of the governance attack risks by preventing flash loans.

Once flash loan governance attack risks have been mitigated, a forum post and a signal request will be published, laying out all the arguments for different GSM delay options. At that point, the Maker community can determine the optimal period for balancing risk in the future.


If this proposal included a poll I would vote in favor of it.

1 Like

Unfortunately, there is no time for a poll before tomorrow. The smart contracts domain team can make the change under our mandate though (the same way we went to 72 hours). The executive must still be ratified, so MKR holders still get their say.

We will cycle back to this after the holidays and put a more granular choice to governance.


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