Emergency Response MIP

Hello Friends!

I wrote up a MIP in hopes to create a consistent (but flexible) procedure when dealing with emergencies and other urgent issues.

There have been multiple expedited changes and proposals recently (PSM discussion, urgent configuration changes, WBTC bug, multiple debt ceiling increases, and oracle whitelisting). Unfortunately, they were all handled a little differently, which caused some confusion and were generally inefficient.

I reviewed some of the more recent emergencies to see how they were handled, and wrote up these procedures in a way that could be applied to all of them. I would really appreciate your feedback, as a lot of this is intentionally vague.

Thank you!

MIPX Emergency Response


Title: Emergency Response
Author(s): @jtathmann
Type: Process
Status: <Assigned by MIP Editor>
Date Proposed: <yyyy-mm-dd>
Date Ratified: <yyyy-mm-dd>



Sentence Summary

  • The Emergency Response MIP outlines the processes of implementing changes to the protocol outside of standard governance cycles.

Paragraph Summary

  • The Emergency Response MIP aims to provide a general guide that can be applied to a wide range of emergency situations. This MIP will differentiate between an emergency response and an urgent response, and provide processes which can be carried out in a consistent manor.

Component Summary

MIPXc1: Emergency Definitions

Defines the terms “urgent” and “emergency”

MIPXc2: Considerations of Expedited Protocol Changes

Outlines the various considerations that should be made before enacting expedited changes.

MIPXc3: Emergency Response Procedure

A general procedure for managing emergency situations.

MIPXc4: Urgent Response Procedure

A general procedure for managing urgent situations.

MIPXc5: Role of Governance Facilitators

Outlines the tasks of the Governance Facilitators during emergency interventions.


The protocol has often required changes outside of the standard weekly and monthly governance cycles to help maintain the peg or to respond to changes in the ecosystem. The goal of this MIP is to provide a consistent process to manage emergencies and urgent issues.

Specification / Proposal Details

MIPXc1: Emergency Definitions

The procedure for managing expedited changes to the protocol will depend on whether an event is classified as urgent or an emergency.

Emergency Response: Any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members of the ecosystem.

Urgent Response: Any situation where the system would benefit from an expedited governance process and following the standard governance cycles would yield an insufficient response.

MIPXc2: Considerations of Expedited Protocol Changes

There are several important factors to consider before expediting changes to the protocol.

  • Potential for MKR holders to miss a poll or executive vote due to diverging from the standard governance cycles.
  • Expedited governance may not allow for sufficient discussion, leading to a sub-optimal solution.
  • Increased governance burden on domain teams and community.
  • Frequent emergency actions may demonstrate lack of control in the governance process.

MIPXc3: Emergency Response Procedure

The ability to declare an emergency will be reserved for Domain Teams and Core Personnel due to their proximity to, and knowledge of, the Maker ecosystem. If a community member wishes to declare an emergency, they will follow the urgent response procedure outlined in MIPXc4.

The emergency response process will be initiated as follows:

  • Declare an emergency in the public forum providing sufficient detail regarding the issue and why immediate action is required. Creating a poll for community sentiment, feedback, or parameter changes is optional.
    • If a remedy is known and uncontentious the Governance Facilitators will coordinate with necessary domain teams to expedite an executive vote.
    • If a remedy is not known or is contentious the Governance Facilitators will coordinate an emergency governance call to discuss solutions and a plan for subsequent actions.

MIPXc4: Urgent Response Procedure

An urgent response may be requested by any community member if they believe the system would benefit from an expedited governance action. The process will be initiated with a signal request in the public forum stating the need for expedited governance and include the following:

  • Poll to gage community sentiment of whether urgent action is needed.
  • Identify the quorum needed to participate in the poll to validate the outcome.
    • Governance Facilitators will confirm the quorum is sufficient given recent community activity.
  • Propose the action that should be expedited in sufficient detail.
    • If this requires a poll, the practical guide to the signaling process will be followed.
    • Changes to system parameters must reach a 50% majority.
    • Changes outside existing system parameters require a 66% majority.
  • If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a confirmation poll for MKR holders.

At any time during the urgent response procedure a Domain Team or Core Personnel may elevate the status to an emergency. At this time, the procedure in MIPXc3 will be carried out.

MIPXc5: Role of Governance Facilitators

Governance Facilitators will oversee emergency processes to ensure they are carried out in a civil and consistent manor. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency process.


How does your proposed MIP relate to MIP5 - Emergency Voting System? https://github.com/makerdao/mips/blob/master/MIP5/mip5.md

Accidentally submitted this before finishing. More on the way…

Aight will do my usual and just read through and provide comments.

Titles are traditionally: ‘MIPX: Name’

Technically this is a General mip. Types are not super well defined, but in general:

  • Process = MIP that has it’s own sub-proposals.
  • Technical = MIP that includes code changes.
  • General = Anything else.

Should be September 7th :slight_smile:

Don’t use bullets for these. It’s one item by itself, no need for it.

I feel like ‘but within the agreed MIPs framework’ should be appended to this. Mainly because some changes can be made completely outside of everything (random person putting up random executive.) And some changes can be ‘urgent’ or ‘emergency’ but still follow ratified processes.


So most of these are fine. I would maybe re-word one or two of them with this in mind: These might be read outside of the context of this MIP in the future, meaning that they should include some level of context and be understandable without having read the rest of this MIP. Like if you see MIPXc1 and you hover over it and it says ‘Defines the terms “urgent” and “emergency”’ you don’t know the context for that, and it doesn’t help a whole lot towards understanding the MIP.

So this isn’t just a governance burden. Taking emergency or urgent action generally creates more work for all of the affected domain teams. Obviously sometimes this is necessary. Maybe ‘increased workload on domain teams’? And governance burden for community?

Mmm, technically this includes the MIP Editor, which I’m not sure is correct? There shouldn’t really be any MIP related emergencies. Though perhaps @charlesstlouis can think of one :slight_smile:

Like I’m also not certain that this justification is correct. The justification is primarily because they have been ratified to a role which in its definition / mandate says something along the lines of ‘These people should act to secure / protect the protocol in emergency situations.’ Writing that, I have no idea if this is technically in the current mandates. But it really should be if it isn’t.

So remove the top-level bullet point, for starters.

I feel like there are a couple of points this should address:

  • In an emergency situation, there is not always time to write a forum post in advance. Can you make clear that this should be done first if there is time, and immediately after / in parallel if there is not?
  • Regarding polls, can we be specific as to on-chain versus signal requests.
  • I would also say that convening an emergency governance call should be presented as a judgement call on behalf of the facilitators. (but include a list of considerations to take into account.)
  • I’d present polling in the same format as my last point. As in: ‘This is a judgement call’ but these are the considerations.

gage -> gauge

Quorum probably doesn’t have to be confirmed in advance (facilitators can respond confirming it?). Maybe make a requirement to inform the facilitators?

Requires elaboration, imo. The practical guide suggests a 2 week minimum.

Might also go straight to executive? Not sure if this is sensible if it’s community sourced. Probably depends ont he circumstances. Leave it up to the facilitators?

Good, this makes sense.

manor -> manner.

So the final sentence needs to go further. It isn’t just the governance facilitators job to identify abuse, they also need to decide whether abuse of the procedure justifies blocking the action (and then potentially blocking it). Fallback can always be removal of facilitators in extremis using MIP5 (I think?)

So, what’s there seems great generally. We’ve discussed having some sort of classification system previously beyond urgent / emergency. I’m not sure whether this is beneficial. But I like the idea of having a defcon-like system. Either numeric, or possibly some more intuitive naming convention. Maybe based on animals and how dangerous they are? Colours? Traffic light system? etc.

I’m also not sure this covers on-going emergencies as well as it could? For example after Black Thursday, we had a whole bunch of responses in the subsequent week. Would it be worth adding some sort of process for dealing with aftermath or ongoing urgencies / emergencies?

I think that about covers my thoughts for now.

My interpretation, is that MIP5 allows for emergency actions to take place. The Emergency Response MIP is aimed more at a framework/procedure for how those emergencies are initiated/communicated, and separating emergency actions from urgent actions.