MIP24: Emergency Voting System (Replaces MIP 5)

Note: @Jtathmann took a break, this MIP is currently being lead by @Davidutro


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!

MIP24: Emergency Voting System

Preamble

MIP#: 24
Title: Emergency Response
Author(s): @Davidutro, @jtathmann 
Contributors:
Type: General
Status: <Assigned by MIP Editor>
Date Proposed: 2020-09-07
Date Ratified: <yyyy-mm-dd>
Dependencies:
Replaces: MIP 5

References

MIP5: Emergency Voting System
Forum Thread: Emergency / Urgent Governance Process
Forum Thread: Covid Crash: Emergency Governance Summary

Sentence Summary

MIP24 defines emergency and urgent situations for the Maker protocol, as well as the process for handling them.

Paragraph Summary

This proposal defines an emergency voting system. Emergency votes are executive votes that can be initiated by any community member. This MIP aims to provide a general guide that can be applied to a wide range of urgenct situations. Additionally, this MIP will differentiate between an emergency and an urgent situation, and provide processes which can be carried out to deal with either consistently.

Component Summary

MIP24c1: Situation Definitions

Defines the terms “urgent” and “emergency” for purposes of an expedited governance change.

MIP24c2: Considerations of Expedited Protocol Changes

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

MIP24c3: Emergency Response Procedure

A general procedure for managing emergency situations.

MIP24c4: Urgent Response Procedure

A general procedure for managing urgent situations.

MIP24c5: Role of Governance Facilitators

Outlines the tasks of the Governance Facilitators during emergency interventions.

Motivation

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

MIP24c1: Situation Definitions

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

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

Urgent: Any situation that includes a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

MIP24c2: 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 departure from the standard governance cycles.
  • Expedited votes may not allow for sufficient discussion, leading to a sub-optimal solution.
  • Increased governance burden on community and increased workload for domain teams.
  • Frequent expeditate votes may signal a lack of appreciation for a consistent and predictable governance process.

MIP24c3: Emergency Response Procedure

The ability to declare an emergency will be reserved for Domain Teams and Governance Facilitators due to their proximity to, and knowledge of, the Maker Protocol and surrounding ecosystem. If a community member wishes to declare an emergency, they will follow the urgent response procedure outlined in MIP24c4. If a Governance Facilitator agrees that the status of the urgent situation should be escalated to “emergency,” they will do so.

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. If time does not permit, a forum post will be created immediately after or in parallel to taking emergency action. Creating a signal request thread or governance poll 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, explicitly inviting known stakeholders.

MIP24c4: Urgent Response Procedure

An urgent response may be requested by any community member if they believe the system is experiencing an emergency or urgent situation as defined in MIP24c1.

The urgent response process will be initiated as follows:

The process will be initiated with a signal request thread in the public forum stating the need for expedited governance action and include the following:

  • Sufficient detail regarding the issue.
  • Proposed action or request to discuss what action governance should take.
  • Signal Poll to gauge community sentiment of whether urgent action is needed.
  • Tag @Gov-Facilitators at the bottom of the post, so that they will be notified and oversee discussion.

Signal Poll Requirement

Any signal poll must adhere to the practical guide as closely as possible given the circumstances for the change.

  • In order for the community to make a change to a system parameter, a signal request must reach a 50% majority and have a reasonable quorum of voters given recent participation.
  • In order for the community to make a change outside of the existing system parameters, a signal request must reach a 66% majority and have a reasonable quorum of voters given recent participation.

Mandated Actor Responsibilities

If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a governance poll for MKR holders or to advance an executive vote, at their discretion.

At any time during the urgent response procedure a Domain Team or Governance Facilitator may elevate the status to an emergency. At that time, the procedure in MIP24c3 will be carried out.

MIP24c5: Role of Governance Facilitators

Governance Facilitators will oversee emergency and urgent situation processes to ensure they are carried out in a civil and consistent manner. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency voting system, and may block a request for emergency action at their discretion.

5 Likes

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.

manner.

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.

2 Likes

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.

1 Like

Updated with @LongForWisdom suggestions.

A few things I haven’t updated yet:

I didn’t make this update, yet, because I like the encompassing nature of these two statements. I don’t believe there can exist an emergency that does not fall within these parameters.

I also like the way these statements are sorted because it provides clear, yet general guidelines for when there should be an emergency call. If something were an Emergency that did not have a solution or was contentious, I don’t believe discussion on the forum would be sufficient.

It seems odd to me that all ratified members would have the authority to declare emergencies except the MIP editor. I’d be more inclined to include the MIP editor just in case all other members are incapacitated, even if it is rarely used. Might come in handy some day :thinking:

Still working!

I meant just don’t use the actual bullet point syntax for top level points. The content of the statements is fine.

Some Header

  • This is a bad top-level point
    • Bad
    • Bad

Some Header
This is a good top level point

  • Good
  • Good
2 Likes

I feel like this should be proposed as a MIP5 amendment

1 Like

How I understand this, it would be cleaner to make this MIP dependent on MIP5.

I think the addition of this procedure would exceed MIP4c1’s guidance of only using amendments for minor changes.

MIP4c1: Purpose Description

Amendments MIP Amendments that preserve the MIP number can be performed as long as there are no changes to the logic of the MIP or to the MIP’s external output dependencies. They should only be used when minor changes are required.

I’m not married to this stance though :slight_smile:

3 Likes

You’re right, doing this is an amendment would be an enormous change to MIP 5.

I think, in general, MIP 5 should go through a full rewrite with your proposed MIP 24 in mind. At the moment MIP 5 is for the “Emergency Voting System” and only outlines two things

  • How to remove a rogue Governance Facilitator
  • How Governance Facilitators handle an “Emergency vote”

The latter is what MIP 24 basically expands upon. The former is an emergency personnel removal process.

@LongForWisdom what would be the right way to go about a full rewrite of an existing MIP, because this is def more than minor changes. I’m not sure an amendment here makes sense.

2 Likes

There are two other methods you can use to replace/re-write a MIP:

  1. (Proactive Approach) As MIP0c5: MIP Replacement Process states, when a MIP is proposed, it can define one or more replacement targets (already existing MIPs/MIP-SPs) in its preamble. If the MIP goes through the governance cycle successfully and is given the Accepted status, the replacement target(s) then receive the Obsolete status and effectively become inactive. The replaced MIP will in its MIP document contain the number of the MIP that replaced it, and other MIPs that depend on the replaced MIP will instead interact with the new MIP.
  2. Using MIP4c3: MIP Removal Process, you can remove an already Accepted MIP using the MIP4c3 subproposal process. This process is meant to be used for removing MIPs that are no longer useful. Once the subproposal to remove a MIP goes through the governance cycle successfully, the MIP is effectively removed from use. In parallel or after it has been removed, you may create a new MIP to replace the old/outdated version of the proposal. Note that if there are other MIPs that depend on a MIP that is being removed, they must also be removed in the same governance cycle, or the proposal will be invalid.
2 Likes

Thanks Charles, that’s super helpful.

I think the best course of action is the proactive approach.

I may tackle a rewrite, @Jtathmann, combining MIP 5 and this proposed MIP 24.

Shouldn’t be too hard imo. DM me on rocket and I can send you the working doc. Or vice versa :))

2 Likes

MIP24: Emergency Voting System

Preamble

MIP#: 24
Title: Emergency Response
Author(s): @Davidutro, @jtathmann 
Contributors:
Type: General
Status: <Assigned by MIP Editor>
Date Proposed: 2020-09-07
Date Ratified: <yyyy-mm-dd>
Dependencies:
Replaces: MIP 5

References

MIP5: Emergency Voting System
Forum Thread: Emergency / Urgent Governance Process
Forum Thread: Covid Crash: Emergency Governance Summary

Sentence Summary

MIP24 defines emergency and urgent situations for the Maker protocol, as well as the process for handling them.

Paragraph Summary

This proposal defines an emergency voting system. Emergency votes are executive votes that can be initiated by any community member. This MIP aims to provide a general guide that can be applied to a wide range of urgenct situations. Additionally, this MIP will differentiate between an emergency and an urgent situation, and provide processes which can be carried out to deal with either consistently.

Component Summary

MIP24c1: Situation Definitions

Defines the terms “urgent” and “emergency” for purposes of an expedited governance change.

MIP24c2: Considerations of Expedited Protocol Changes

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

MIP24c3: Emergency Response Procedure

A general procedure for managing emergency situations.

MIP24c4: Urgent Response Procedure

A general procedure for managing urgent situations.

MIP24c5: Role of Governance Facilitators

Outlines the tasks of the Governance Facilitators during emergency interventions.

Motivation

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

MIP24c1: Situation Definitions

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

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

Urgent: Any situation that includes a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

MIP24c2: 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 departure from the standard governance cycles.
  • Expedited votes may not allow for sufficient discussion, leading to a sub-optimal solution.
  • Increased governance burden on community and increased workload for domain teams.
  • Frequent expeditate votes may signal a lack of appreciation for a consistent and predictable governance process.

MIP24c3: Emergency Response Procedure

The ability to declare an emergency will be reserved for Domain Teams and Governance Facilitators due to their proximity to, and knowledge of, the Maker Protocol and surrounding ecosystem. If a community member wishes to declare an emergency, they will follow the urgent response procedure outlined in MIP24c4. If a Governance Facilitator agrees that the status of the urgent situation should be escalated to “emergency,” they will do so.

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. If time does not permit, a forum post will be created immediately after or in parallel to taking emergency action. Creating a signal request thread or governance poll 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, explicitly inviting known stakeholders.

MIP24c4: Urgent Response Procedure

An urgent response may be requested by any community member if they believe the system is experiencing an emergency or urgent situation as defined in MIP24c1.

The urgent response process will be initiated as follows:

The process will be initiated with a signal request thread in the public forum stating the need for expedited governance action and include the following:

  • Sufficient detail regarding the issue.
  • Proposed action or request to discuss what action governance should take.
  • Signal Poll to gauge community sentiment of whether urgent action is needed.
  • Tag @Gov-Facilitators at the bottom of the post, so that they will be notified and oversee discussion.

Signal Poll Requirement

Any signal poll must adhere to the practical guide as closely as possible given the circumstances for the change.

  • In order for the community to make a change to a system parameter, a signal request must reach a 50% majority and have a reasonable quorum of voters given recent participation.
  • In order for the community to make a change outside of the existing system parameters, a signal request must reach a 66% majority and have a reasonable quorum of voters given recent participation.

Mandated Actor Responsibilities

If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a governance poll for MKR holders or to advance an executive vote, at their discretion.

At any time during the urgent response procedure a Domain Team or Governance Facilitator may elevate the status to an emergency. At that time, the procedure in MIP24c3 will be carried out.

MIP24c5: Role of Governance Facilitators

Governance Facilitators will oversee emergency and urgent situation processes to ensure they are carried out in a civil and consistent manner. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency voting system, and may block a request for emergency action at their discretion.

3 Likes

My initial comment:

  • If @Jtathmann agrees with the changes, the actual MIP itself will need to be updated in John’s original post as well as a PR to update the proposal on Github (on the RFC branch).

I will follow up with some more comments tomorrow on the content.

Went through and made some comments. Thanks David!

This makes it sound like there are emergency changes to the facilitator role, which isn’t the case.

I feel like this might be too vague. One could argue that all changes would benefit from an expedited governance process. What makes a response insufficient?

Not sure I would phrase this as a lack of control. Maybe a lack of appreciation for consistent and predictable governance?

@Gov-Facilitators is the correct tag to notify the facilitators group.

Can you include some of the points in the Emergency / Urgent Governance Process thread in this section please? Mainly the following (some of it is covered in MIP24c5, which is probably sufficient.)

I would also consult this post: Covid Crash: Emergency Governance Summary specifically the final section.

Executive spells only include code. Maybe clarify that this should be specified in the copy accompanying the executive vote.

This isn’t correct under DssGov (the new governance contract). There is not one active proposal under the new system as currently designed.

Who provides this list? Where do they provide it, as part of the vote or in the forum?


On more of a general level. I liked the idea of providing a traffic-light / defcon / etc type system that categorizes the severity of emergency situations in a slightly more granular way.

Have you considered integrating something like that into this MIP?

This makes it sound like there are emergency changes to the facilitator role, which isn’t the case.

I’ve removed the whole bit about the removal of GF from this MIP, as it seems to be covered in MIP0c11: Governance Facilitator Role and MIP0c13: Core Personnel Offboarding. I thought it was from an emergency removal situation, but there’s no reason the standard process can’t be followed.

I feel like this might be too vague. One could argue that all changes would benefit from an expedited governance process. What makes a response insufficient?

rewrote as
“Any situation that includes a time-sensitive matter that would need an expedited governance process, where following the standard governance cycles would be too slow, risk a larger problem, or constitute an important missed opportunity.”

Not sure I would phrase this as a lack of control. Maybe a lack of appreciation for consistent and predictable governance?

fixed to, “Frequent emergency actions may signal a lack of appreciation for a consistent and predictable governance process.”

Tag Governance Facilitator

fixed tag

I liked the idea of providing a traffic-light / defcon / etc type system that categorizes the severity of emergency situations in a slightly more granular way.
Have you considered integrating something like that into this MIP?

I have, but I think it needs more discussion around what the different “defcon” levels would be. There is no rush here, since this can be added as an amendment to MIP24c1: Situation Definitions, or amended as a new component all together.

I edited the draft MIP in the comment above.

1 Like

I have not received a response from @Jtathmann, @charlesstlouis

1 Like

Well, there is a reason the standard process doesn’t work, because the Governance Facilitator manages the standard process.

My point was more that it’s not an emergency change to the role itself, it’s an emergency removal of an individual from the role.

I like this a fair bit better, thanks.

That’s fair. My point was more that we should consider starting those discussion and thinking about whether there are useful separations of severity we can use. I agree that it’s not essential, but I think it’s worth considering.

1 Like

Do you think it’s worth keeping the emergency personnel removal here then?

Is there a reason an emergency removal couldn’t go through MIP 24, as it’s proposed? The community would put up the same type of explanatory forum thread detailing why the GF in question should be removed and why it’s an urgent situation.

The next-up GF can execute on the request.

In the absence of another GF, maybe an additional signal can be created electing someone in the interim?

In the absence of another GF, maybe an additional signal can be created electing someone in the interim?

I guess this is the piece of the process that should be captured somewhere in the MIPs

After coordinating with @LongForWisdom, @Davidutro, and @Jtathmann, I’m transferring Authorship of MIP24 to @Davidutro which will allow him to incorporate the new changes he has proposed for MIP24 as well as decide when to Formally Submit the proposal.

4 Likes

I have updated the MIP with some final edits to clean up the language. I added the updated version to the top-level original post as well as my own comment above.

I decided, for the time being, to leave off emergency removal of GF since I believe it can be covered by this process implicitly.

In the future of this MIP I expect the community to discuss and reach some consensus around a multi-level warning system rather than the simple urgent / emergency system being proposed here.

In general, I believe this is a huge improvement on MIP 5. Please let me know any final comments or changes I can make before officially submitting it for the November governance cycle.

@LongForWisdom @charlesstlouis

1 Like