diff --git a/mip0.md b/mip0.md index bb5e7ad92..6480281b0 100644 --- a/mip0.md +++ b/mip0.md @@ -12,23 +12,49 @@ Dependencies: n/a Replaces: n/a ``` -### Components -**MIP0c1:** Definitions of the Maker Improvement Proposal Framework -**MIP0c2:** Core Principles -**MIP0c3:** The MIP Lifecycle -**MIP0c4:** MIP Components and MIP Component Types -**MIP0c5:** MIP Replacement Process -**MIP0c6:** MIP Templates -**MIP0c7:** MIP0 Domain Role Dependencies -**MIP0c8:** MIP Editor Election Process -**MIP0c9:** MIP Editor Removal Process -**MIP0c10:** Governance Facilitator Election Process -**MIP0c11:** Governance Facilitator Removal Process - -## Summary +## Sentence Summary + +MIP0 defines and describes the MIPs Framework. + +## Paragraph Summary MIP0 is the genesis proposal describing the MIPs Framework. This includes the core components and statuses as well as the various MIP types and the overall MIP lifecycle. Furthermore, it provides the necessary tools, such as MIP templates, replacement processes, and dependencies. Lastly, the proposal details the key roles of the framework, the MIP Editor and the Governance Facilitator along with the process for adding and removing them. +## Component Summary + +**MIP0c1: Definitions of the Maker Improvement Proposal Framework** +Defines several concepts that are important for understanding the MIPs process. + +**MIP0c2: Core Principles** +Discusses some core principles that all MIPs should aim to follow. + +**MIP0c3: The MIP Lifecycle** +Lays out how a MIP is created and moves through the process to become Accepted or Rejected. + +**MIP0c4: MIP Components and MIP Component Types** +Discusses the use of components to compartmentalize and organise MIPs + +**MIP0c5: MIP Replacement Process** +Discusses how MIPs can be replaced and the steps to be taken to maintain dependencies. + +**MIP0c6: MIP Templates** +Defines the MIP templates for both General and Technical MIPs. + +**MIP0c7: MIP0 Domain Role Dependencies** +Defines the core roles that the MIPs process requires to operate successfully. + +**MIP0c8: MIP Editor Election Process** +A process component that defines both the role and the process to elect a new MIP Editor. + +**MIP0c9: MIP Editor Removal Process** +A process component that defines both the criteria and the process to remove a MIP Editor. + +**MIP0c10: Governance Facilitator Election Process** +A process component that defines both the role and the process to elect a Governance Facilitator. + +**MIP0c11: Governance Facilitator Removal Process** +A process component that defines both the criteria and the process to remove a Governance Facilitator. + ## Motivation @@ -225,13 +251,17 @@ Date Proposed: Dependencies: n/a Replaces: n/a ``` -**Components** +**Sentence Summary** -A list of components that are included in the specification / proposal details. +A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. -**Summary** +**Paragraph Summary** -A description of what the Maker Improvement Proposal (MIP) is focused on. +A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 100 words max. + +**Component Summary** + +A description of the purpose of each component in the MIP . Suggest 30 words max per component. **Motivation** @@ -257,13 +287,17 @@ Dependencies: Replaces: License: ``` -**Components** +**Sentence Summary** + +A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. + +**Paragraph Summary** -A list of components that are included in the specification. +A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 100 words max. -**Summary** +**Component Summary** -A short description of what the Maker Improvement Proposal (MIP) is focused on. +A description of the purpose of each component in the MIP . Suggest 30 words max per component. **Motivation** diff --git a/mip1.md b/mip1.md index 0bf77ce34..d9b18cb88 100644 --- a/mip1.md +++ b/mip1.md @@ -5,6 +5,7 @@ MIP#: 1 Title: Governance Paradigms Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom Type: Process Status: Date Proposed: 2020-04-06 @@ -12,15 +13,29 @@ Dependencies: n/a Replaces: n/a ``` -### Components -**MIP1c1:** Definitions -**MIP1c2:** The Initial Problem Space -**MIP1c3:** Changing the Problem Space +## Sentence Summary -## Summary +MIP1 defines and describes Governance Paradigms and problem spaces. + +## Paragraph Summary A Governance Paradigm is a complete and specific group of MIP Sets that solve an entire problem space. A problem space is defined as a list of issues that must be addressed in order for the Maker Protocol to be able to sustain itself and grow into the future Maker governance. +## Component Summary + +**MIP1c1: Definitions** +Defines what is meant by a problem space and a Governance Paradigm. + +**MIP1c2: The Initial Problem Space** +Defines an initial list of problems that will need to be solved in order for there to be a complete Governance Paradigm. + +**MIP1c3: Changing the Governance Paradigm** +Defines MIPs and MIP Sets as the method used to amend or replace the Governance Paradigm. + + +**MIP1c4: Changing the Problem Space** +A process component that provides a method and a template for adjusting the problem space. + ## Motivation The goal of having a defined governance paradigm is to give the community a complete overview of what specific MIPs are used to address specific problems. By having a Governance Paradigm in place, the community can reform and upgrade specific parts of the governance process while complexity and dependency issues are kept in check. At the same time, it also makes it more clear how the community can completely replace and overhaul the governance process, and create something new, while guaranteeing that all the problems that were solved by the old process are also fully solved by the new process. @@ -29,7 +44,7 @@ It is important at all times to have the best possible estimate of what the long ## Specification / Proposal Details -### MIP1c1: Definitions +### MIP1c1: Definitions **Problem Space** @@ -49,20 +64,6 @@ A complete set of processes, implemented through MIPs, that allows Maker Governa A MIP Set is a group of several MIPs that are interdependent, in which without the entire set of MIPs existing, one or more MIPs in the Set becomes inconsistent, invalid or nonsensical. The intention is for MIP sets to together describe a single complex behaviour in such a way that allows each individual MIP to be written following the principle of Specificity but work together as a cohesive modular whole. -**Amending the Governance Paradigm** - -A Governance Paradigm can be amended by replacing specific MIPs, or an entire MIP Set, in the Governance Paradigm while maintaining correct interfacing with all other MIPs within the MIP set and wider Governance Paradigm. - -**Replacing a Governance Paradigm** - -A governance paradigm can be replaced in its entirety by replacing all MIPs in the Governance Paradigm with a complete grouping of new MIPs, contained in MIP Sets that fully address all items in the Governance Paradigm Problem Space - -An individual MIP or MIP Set in the active Governance Paradigm cannot be replaced if the replacement doesn't properly interact with the other MIPs in the Governance Paradigm that the replaced MIP is dependent on, or that are dependent on the replaced MIP. Otherwise, the Governance Paradigm as a whole could break and MIPs could stop functioning correctly due to interdependency issues. Thus, you have to either replace an individual MIP or MIP Set in a Governance Paradigm or replace the entire Governance Paradigm with a completely new grouping of MIP Sets that fully address all items in the Governance Paradigm Problem Space. - -**Amending the Problem Space** - -If Maker Governance wishes to change the Governance Paradigm and processes more drastically, they need to alter the Governance Paradigm Problem Space. In most cases, this is done by expanding the Problem Space after practical experience makes it clear there are additional problems, challenges or opportunities that Maker Governance needs a clear predetermined process to deal with. However, it could also be reducing the scope of the Problem Space, or changing the language or logical grouping of some of its aspects. - --- ### MIP1c2: The Initial Problem Space @@ -88,14 +89,31 @@ The current Governance Paradigm Problem Space is defined as follows and is organ 15. **Dai Foundation:** Manage and fund the entity that controls legal and centralized assets, such as trademarks and copyrights, that are critical to MakerDAO. This is important for the safeguarding of the assets and preventing any possible misuse. It is critical that the community is able to have a formalized process for funding and interacting with the Dai Foundation. -**Important Note**: -- The problem spaces listed above are not final but rather estimates of the problems the Maker Foundation believes will need to be addressed over the course of the next few years on our path to self-sustainability. Overall, this is a starting point and does not represent a long term commitment. It is expected that it will change over time based on the needs and experience of the Maker community. +**Important Note** + +The problem spaces listed above are not final but rather estimates of the problems the Maker Foundation believes will need to be addressed over the course of the next few years on our path to self-sustainability. Overall, this is a starting point and does not represent a long term commitment. It is expected that it will change over time based on the needs and experience of the Maker community. + +--- + +### MIP1c3: Changing the Governance Paradigm + +**Amending the Governance Paradigm** + +A Governance Paradigm can be amended by replacing specific MIPs, or an entire MIP Set, in the Governance Paradigm while maintaining correct interfacing with all other MIPs within the MIP set and wider Governance Paradigm. + +**Replacing a Governance Paradigm** + +A governance paradigm can be replaced in its entirety by replacing all MIPs in the Governance Paradigm with a complete grouping of new MIPs, contained in MIP Sets that fully address all items in the Governance Paradigm Problem Space + +An individual MIP or MIP Set in the active Governance Paradigm cannot be replaced if the replacement doesn't properly interact with the other MIPs in the Governance Paradigm that the replaced MIP is dependent on, or that are dependent on the replaced MIP. Otherwise, the Governance Paradigm as a whole could break and MIPs could stop functioning correctly due to interdependency issues. Thus, you have to either replace an individual MIP or MIP Set in a Governance Paradigm or replace the entire Governance Paradigm with a completely new grouping of MIP Sets that fully address all items in the Governance Paradigm Problem Space. --- -### MIP1c3: Changing the Problem Space +### MIP1c4: Changing the Problem Space + +If Maker Governance wishes to change the Governance Paradigm and processes more drastically, they need to alter the Governance Paradigm Problem Space. In most cases, this is done by expanding the Problem Space after practical experience makes it clear there are additional problems, challenges or opportunities that Maker Governance needs a clear predetermined process to deal with. However, it could also be reducing the scope of the Problem Space, or changing the language or logical grouping of some of its aspects. -MIP1c3 is a Process-MIP component that allows the creation of sub proposals with a 3 month feedback period that can add or delete items in the Governance Paradigm Problem space. +MIP1c3 is a Process MIP component that allows the creation of sub proposals with a 3 month feedback period that can add or delete items in the Governance Paradigm Problem space. - **Feedback Period**: 3 months - **Frozen Period**: 1 month diff --git a/mip10.md b/mip10.md index b53f5efa2..b7ec58eed 100644 --- a/mip10.md +++ b/mip10.md @@ -13,16 +13,28 @@ Replaces: n/a -### Components -**MIP10c1:** Oracle Onboarding -**MIP10c2:** List of Active Oracle Data Models -**MIP10c3:** Process for onboarding -**MIP10c4:** Process for offboarding +## Sentence Summary -## Summary +MIP10 defines how oracles are onboarded, offboarded and managed in order to support the collateral onboarding process. + +## Paragraph Summary This proposal defines the process for onboarding, offboarding and managing oracles. +## Component Summary + +**MIP10c1: Oracle Onboarding** +Defines a process for onboarding new oracles into the Maker Protocol. + +**MIP10c2: List of Active Oracle Data Models** +A list component that is kept up-to-date with the currently active oracle data models. + +**MIP10c3: Process for onboarding** +A process component that defines the method and template to be used to onboard new oracles for collateral assets. + +**MIP10c4: Process for offboarding** +A process component that defines the method and template to be used to offboard oracles in the case they have become obsolete or otherwise undesireable. + ## Motivation In the Maker Protocol, every collateral type has a corresponding Oracle that publishes a reference price that the protocol utilizes. Therefore, the Oracle requirements must be laid out in detail for the collateral onboarding process. Governance may also choose to create Oracles for non-collateral assets for use by 3rd parties. diff --git a/mip11.md b/mip11.md index c1dc2caab..44a7374ab 100644 --- a/mip11.md +++ b/mip11.md @@ -11,16 +11,28 @@ Date Proposed: 2020-04-06 Dependencies: MIP0, MIP3, MIP7 Replaces: n/a ``` -### Components -**MIP11c1:** General Risk Model Requirements -**MIP11c2:** List of Active General Risk Models -**MIP11c3:** Process for Onboarding -**MIP11c4:** Process for offboarding +## Sentence Summary -## Summary +MIP11 defines the requirements of general risk models and how they are onboarded to and offboarded from the Maker Protocol. + +## Paragraph Summary This proposal defines the process and requirements for risk teams to onboard general risk models for use in collateral onboarding in MIP12. +## Component Summary + +**MIP11c1: General Risk Model Requirements** +Describes the concept of a general risk model and defines both the required components that all general risk models must have and optional components that a general risk model may have. + +**MIP11c2: List of Active General Risk Models** +A list component that is kept up-to-date with the currently active general risk models. + +**MIP11c3: Process for Onboarding** +A process component that defines a method and a template for onboarding a general risk model. + +**MIP11c4: Process for offboarding** +A process component that defines a method and a template for offboarding a general risk model. + ## Motivation Risk models are a crucial element of the Maker Protocol's maintenance and growth. The models provide a representation of how a risk team intends to evaluate an asset or other part of the risk function. Therefore, the purpose of this proposal is to create a defined and formalized process for Risk teams to more easily onboard their models to the Maker Protocol and ultimately help grow and maintain the Protocol. diff --git a/mip12.md b/mip12.md index cecaa6076..85271e29a 100644 --- a/mip12.md +++ b/mip12.md @@ -11,16 +11,25 @@ Date Proposed: 2020-04-06 Dependencies: MIP0, MIP3, MIP7, MIP10, MIP11 Replaces: n/a ``` +## Sentence Summary -### MIP11 Components -**MIP12c1:** Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol -**MIP12c2:** Proposing New Risk Parameters, Oracles, and Collateral Adapters -**MIP12c3:** Collateral Type Checklist (Governance) +MIP12 defines the domain team and documentation requirements for adding or changing collateral packages in the Maker Protocol. -## Summary +## Paragraph Summary This proposal defines the documentation requirements for the onboarding of a new collateral type to the Maker Protocol, more specifically, the risk teams' objectives and requirements to deliver it in a unified package risk construct. +## Component Summary + +**MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol** +Lists the required and optional domain teams involved in onboarding a collateral type to the Maker Protocol. + +**MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters** +A process component that defines a method, a template and the requirements for proposing new risk parameters, oracles or collateral adaptors. + +**MIP12c3: Collateral Type Checklist (Governance)** +Defines a checklist of actions that must be completed before and after governance approval of a collateral type. + ## Motivation This proposal will focus on the collateral onboarding process blueprint for submitting MIP12 Subproposals (MIP12-SPs). The subproposals allow any community member to propose new risk parameters, oracles, and adapters for a new, or existing collateral type. Additionally, it will also define priority polls and the overall collateral onboarding process requirements. Furthermore, it allows domain teams to execute on collateral onboarding via the executive vote. This is the last step that needs to be completed when you have the risk construct with risk parameters based on a risk model ratified through MIP11. diff --git a/mip2.md b/mip2.md index 8772d60aa..3375b0138 100644 --- a/mip2.md +++ b/mip2.md @@ -1,24 +1,23 @@ # MIP2: Launch Period - ## Preamble ``` MIP#: 2 Title: Launch Period Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom Type: Process Status: Date Proposed: 2020-04-06 -Dependencies: n/a +Dependencies: MIP0, MIP1 Replaces: n/a ``` -### Components -**MIP2c1:** Interim Phase 1 -**MIP2c2:** Interim Phase 2 -**MIP2c3:** MIP2 Obsolescence +## Sentence Summary + +MIP2 details two interim phases during which logic defined in MIP0 is overriden. -## Summary +## Paragraph Summary This proposal details the process of how Maker Governance can bootstrap the setup and implementation of the first Governance Paradigm. More specifically, it defines two phases: 1. **Phase 1:** when a core governance framework is put in place and a functional collateral onboarding process is ratified. @@ -26,6 +25,17 @@ This proposal details the process of how Maker Governance can bootstrap the setu Lastly, the proposal states that MIP2 itself will become obsolete when the Problem Space has officially been addressed. +## Component Summary + +**MIP2c1: Interim Phase 1** +Defines the first interim phase, in which the feedback period and freeze period for MIPs are ignored until both a core governance framework and a functional collateral onboarding process are implemented through MIPs. + +**MIP2c2: Interim Phase 2** +Defines the second interim phase, in which the feedback period and freeze period for MIPs are reduced until the initial problem space has been addressed. + +**MIP2c3: MIP2 Obsolescence** +Defines the obsolescence of this MIP once the interim phases have passed. + ## Motivation @@ -41,16 +51,16 @@ As a result, the community should prioritize getting the initial processes in pl ### MIP2c1: Interim Phase 1 -**Interim Phase 1 commences with the ratification of this MIP. During Interim Phase 1, the following logic overrides that defined in MIP0:** +**Interim Phase 1 commences when the governance timing vote elects that the initial MIPs should proceed with the ratification vote. During Interim Phase 1, the following logic overrides that defined in MIP0:** 1. The Feedback Period and Frozen Period defined in MIP0 are ignored for both MIPs and Subproposals. -2. Multiple MIPs can be voted in with a single vote. +2. Multiple MIPs and Subproposals and can be voted in with a single vote. - Before the vote, alternatives to the MIPs within the MIP Set can be proposed if they interface correctly with all the other MIPs within the Set. **During Interim Phase 1, the following additional logic is applied to the MIPs process defined in MIP0:** -- A single vote approves or rejects all MIPs during phase 1. +- A single vote approves or rejects all MIPs and Subproposals during phase 1. - If rejected, MIPs can be reintroduced to the community for another vote once the issues that resulted in its initial rejection have been addressed. -Interim Phase 1 ends when there is a core governance framework in place and a functional collateral onboarding process. +Interim Phase 1 ends 3 months after there is a formal a core governance framework in place and a functional collateral onboarding process. --- ### MIP2c2: Interim Phase 2 @@ -58,13 +68,13 @@ Interim Phase 1 ends when there is a core governance framework in place and a fu Interim Phase 2 commences as Interim Phase 1 ends. **During Interim Phase 2, the following logic overrides that defined in MIP0:** -1. The Feedback Period and Frozen Period defined in MIP0 are ignored. +1. The Feedback Period and Frozen Period defined in MIP0 are ignored for both MIPs and Subproposals. **During Interim Phase 2, the following additional logic is applied to the MIPs process defined in MIP0:** -1. The Feedback Period for the MIPs going through the MIPs process is 1 month. -2. The Frozen Period for the MIPs going through the MIPs process is 1 week. -3. If rejected, MIPs can be reintroduced to the community for another vote once the issues that resulted in its initial rejection have been addressed. +1. The Feedback Period for the MIPs and Subproposals going through the MIPs process is 1 month unless otherwise defined to be shorter. +2. The Frozen Period for the MIPs and Subproposals going through the MIPs process is 1 week unless otherwise defined to be shorter. +3. If rejected, MIPs and Subproposals can be reintroduced to the community for another vote once the issues that resulted in its initial rejection have been addressed. Interim Phase 2 ends when the Problem Space has been addressed. More specifically, this is when MIP Sets have been ratified that have addressed each problem statement within the Problem Space. diff --git a/mip3.md b/mip3.md index 66d370812..5d4caefed 100644 --- a/mip3.md +++ b/mip3.md @@ -12,14 +12,23 @@ Dependencies: n/a Replaces: n/a ``` -### Components -**MIP3c1:** Governance Cycle Breakdown -**MIP3c2:** Default Inclusion Threshold Modification Subproposals +## Sentence Summary -## Summary +MIP3 defines a monthly Governance Cycle with the aim of providing a predictable framework for Maker governance decisions. + +## Paragraph Summary This proposal formally introduces a Governance Cycle. The Governance Cycle provides a predictable framework for Maker Governance decisions. Furthermore, it provides participants (MKR holders) with a monthly overview of the decisions that are to be made, allowing participation despite time constraints. +## Component Summary + +**MIP3c1: Governance Cycle Breakdown** +Breaks the Governance Cycle down into the actions that take place each week of the monthly cycle. + +**MIP3c2: Default Inclusion Threshold Modification Subproposals** +A process component that defines a method and template for the modification of the default inclusion threshold. + + ## Motivation The goal of the standardized monthly governance cycle is to provide advance notification and high predictability of governance activities in order to enable MKR holders to stay informed on relevant topics and participate in voting despite being time-constrained. diff --git a/mip4.md b/mip4.md index 65f3a7413..3b9860951 100644 --- a/mip4.md +++ b/mip4.md @@ -5,6 +5,7 @@ MIP#: 4 Title: MIP Amendment and Removal Process Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom Type: Process Status: Date Proposed: 2020-04-06 @@ -12,15 +13,25 @@ Dependencies: n/a Replaces: n/a ``` -### Components -**MIP4c1:** Purpose Description -**MIP4c2:** MIP Amendment Process -**MIP4c3:** MIP Removal Process +## Sentence Summary -## Summary +MIP4 defines processes for the amendment and removal of accepted MIPs. + +## Paragraph Summary The Amendment and Removal Process-MIP outlines the process for very small and relatively superficial changes to MIPs. This MIP Contains two Process Components, the first dealing with the Removal of ratified MIPs, and the second dealing with Amending current active MIPs. +## Component Summary + +**MIP4c1: Purpose Description** +Suggests the purpose of the amendment and removal processes and possible reasons for using each process. + +**MIP4c2: MIP Amendment Process** +A process component which defines a method and template for the amendment of an accepted MIP. + +**MIP4c3: MIP Removal Process** +A process component which defines a method and template for the removal of an accepted MIP. + ## Motivation The motivation behind this proposal is that changing small details to MIPs should not require the original MIP to become obsolete or replaced, so this Process-MIP is needed to define and outline the process behind making these changes to MIPs once they have already been ratified and implemented. Additionally, this MIP defines the process for the removal of MIPs that are have become no longer useful. @@ -31,22 +42,25 @@ The motivation behind this proposal is that changing small details to MIPs shoul ### 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. The validity of MIP Amendments is ultimately up to the community but possible reasons for amendments could be (but are not limited to): - - A formatting change - - Typos - - Rewording/clarification +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. + +**Validity** +The validity of MIP Amendments is ultimately up to the community but possible reasons for amendments could be (but are not limited to): +- A formatting change +- Typos +- Rewording/clarification -- MIP Amendments are invalid if, based on the assessment of the community and confirmed by a governance facilitator, are so severe that the changes should be achieved through a MIP replacement instead. +MIP Amendments are invalid if, based on the assessment of the community, the changes are so severe that they should be achieved through a MIP replacement instead. **Removals** -- MIP4 also enables the removal of MIPs that are no longer useful. 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. +MIP4 also enables the removal of MIPs that are no longer useful. 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. --- ### MIP4c2: MIP Amendment Process - This component details the process of making the amendments. -- **Feedback Period:** 3 months -- **Frozen Period:** 1 month + This component details the process of making amendments. +- **Feedback Period:** 1 month +- **Frozen Period:** 1 week - **Template:** - The amendment process follows the same template of the MIP you are proposing an amendment to. diff --git a/mip5.md b/mip5.md index 5619410ba..ad525ea5f 100644 --- a/mip5.md +++ b/mip5.md @@ -5,20 +5,30 @@ MIP#: 5 Title: Emergency Voting System Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom Type: Process Status: Date Proposed: 2020-04-06 Dependencies: n/a Replaces: n/a ``` -### Components -**MIP5c1:** Governance Facilitator Emergency Votes -**MIP5c2:** An Emergency State Change -## Summary +## Sentence Summary + +MIP5 defines emergency changes to the protocol and Governance Facilitator role and how they should be handled in practice. + +## Paragraph Summary This proposal defines an emergency voting system. Emergency votes are executive votes that can be initiated by any community member. +## Component Summary + +**MIP5c1: Governance Facilitator Emergency Votes** +This component addresses the emergency removal of an individual from the Governance Facilitator role. + +**MIP5c2: An Emergency State Change** +This component addresses emergency state changes to the protocol and how they are to be handled by the Governance Facilitators. + ## Motivation This standard is being proposed in order to allow the community to overcome the constraints of the governance cycle (MIP3) in special situations where it is time critical to make changes or remove a part of the operating system. @@ -28,11 +38,13 @@ This standard is being proposed in order to allow the community to overcome the ### MIP5c1: Governance Facilitator Emergency Votes -- A governance facilitator emergency vote encodes one or more website URLs into an on-chain voting contract (spell), as well as containing logic that stops any payment stream to the existing governance facilitators. If the executive vote gets the most MKR votes and becomes the active proposal the existing Governance facilitators are then removed. The list of website URLs then corresponds to a list of one or more new Interim Governance facilitators and their governance platforms that will replace the current governance facilitators. The current governance cycle is canceled, and the new Interim Governance Facilitators initiate a new governance cycle on the following 1st Monday of the month. +A governance facilitator emergency vote encodes one or more website URLs into an on-chain voting contract (spell), as well as containing logic that stops any payment stream to the existing governance facilitators. If the executive vote gets the most MKR votes and becomes the active proposal the existing Governance facilitators are then removed. The list of website URLs then corresponds to a list of one or more new Interim Governance facilitators and their governance platforms that will replace the current governance facilitators. The current governance cycle is canceled, and the new Interim Governance Facilitators initiate a new governance cycle on the following 1st Monday of the month. --- ### MIP5c2: An Emergency State Change -- An emergency executive vote that contains state change logic. For example, changing the DSR or removing a collateral type. These types of votes can in some cases be used to reduce risk in the system, help stabilize the peg, or fix critical technical issues. However, they are also very dangerous and must be used carefully as they can potentially be attacks that, for example, drain all the collateral from the system. -- Governance Facilitators can ignore an emergency state change, or either declare support for an emergency state change by adding it as an irregularly scheduled executive vote on their governance portals, or declare it a governance attack, potentially encouraging users to trigger an emergency shutdown in response. +An emergency executive vote that contains state change logic. For example, changing the DSR or removing a collateral type. These types of votes can in some cases be used to reduce risk in the system, help stabilize the peg, or fix critical technical issues. However, they are also very dangerous and must be used carefully as they can potentially be attacks that, for example, drain all the collateral from the system. + +Governance Facilitators can ignore an emergency state change, or either declare support for an emergency state change by adding it as an irregularly scheduled executive vote on their governance portals, or declare it a governance attack, potentially encouraging users to trigger an emergency shutdown in response. + --- diff --git a/mip6.md b/mip6.md index bbcd1bdbc..901c7997b 100644 --- a/mip6.md +++ b/mip6.md @@ -4,7 +4,8 @@ ``` MIP#: 6 Title: Collateral onboarding form/forum template -Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23), Leo Jsaraceno (Mitote), Helge Andreas Qvam (@planet_X) +Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) +Contributors: @LongForWisdom, Leo Jsaraceno (Mitote), Helge Andreas Qvam (@planet_X) Type: Process Status: Date Proposed: 2020-04-06 @@ -12,15 +13,25 @@ Dependencies: n/a Replaces: n/a ``` -### Components -**MIP6c1:** Process Overview -**MIP6c2:** Application Form Template -**MIP6c3:** Sub Proposal Framework +## Sentence Summary -## Summary +MIP6 provides an overview of defines a standardised application form used to kick off the process of onboarding a new collateral asset to the Maker Protocol. + +## Paragraph Summary The purpose of this proposal is to standardize the collateral onboarding form/forum template that community members and third-party projects can use to begin the process of getting their collateral onboarded to the Maker Protocol. +## Component Summary + +**MIP6c1: Process Overview** +Provides an overview of the collateral application form submission process which includes location, involved stakeholders and the next phase. + +**MIP6c2: Application Form Template** +Provides an collateral application form template to be used in the submission process defined in MIP6c1. + +**MIP6c3: Sub Proposal Framework** +A process component that defines a method and template to amend the collateral application form template defined in MIP6c2. + ## Motivation This proposal aims to layout one part of the generalized process for adding collateral types to the Maker Protocol. This will allow the community to get an idea of what the applying collateral is, an overview of the risks, and an understanding of the potential benefits to Maker. A consistent application form allows prospective collateral types to be compared by the community. The pitch materials allow the interested party to generate interest from the Maker community. @@ -35,14 +46,16 @@ Although this is only one component of the overall collateral onboarding process 1. Fill out the application/questions in as much detail as you’re willing. - - Once filled out, the application must be published on the official MakerDAO forum and should be posted within the Collateral Discussion subcategory within the Risk category. - - This post should have the tag ‘collateral-app’ + - Once filled out, the application must be published on the official MakerDAO forum and should be posted within the `Collateral Onboarding App` subcategory within the `Maker Improvement Proposals` category. + - This post should have the tag `collateral-app`. - Note that an 'interested party' refers to anybody willing to act as a stakeholder for this onboarding process. 2. After the submission on the forum, the community will likely have follow up questions. While not a requirement, answering questions about your project may help generate support or excitement for the proposed collateral type. Additionally, the interested party may organize an optional call to pitch their proposal as well as open up further discussion to the community. -3. Once the application has been submitted to the forum, it is eligible for Domain team review and can, therefore, move forward in the collateral onboarding process. +3. Once the application has been submitted to the forum, it is eligible for Domain Greenlight as defined in MIP8. + +4. After two weeks of discussion have passed, and Domain Greenlight (MIP8) has been completed, the application is eligible to move to the Community Greenlight poll defined in MIP9. ### Overall Process Overview Diagram @@ -57,16 +70,16 @@ Responses to these questions serve as an introduction to the community, this min **The suggested application questions are as follows:** 1. Who is the interested party for this collateral application? -2. Provide a brief high-level overview of the project, with a focus on the applying collateral token -3. Provide a brief history of the project +2. Provide a brief high-level overview of the project, with a focus on the applying collateral token. +3. Provide a brief history of the project. 4. Link the whitepaper, documentation portals, and source code for the system(s) that interact with the proposed collateral, and all relevant Ethereum addresses. If the system is complex, schematic(s) are especially appreciated. 5. Link any available audits of the project. Both procedural and smart contract focused audits. 6. Link to any active communities relating to your project. 7. How is the applying collateral type currently used? 8. Does one organization bear legal responsibility for the collateral? What jurisdiction does that organization reside in? 9. Where does exchange for the asset occur? -10. (Determined by Legal Domain Team) Has your project obtained any legal opinions or memoranda regarding the regulatory standing of the token or an explanation of the same from the perspective of any jurisdiction? If so, those materials should be provided for community review. -11. (Determined by Legal Domain Team) Describe whether there are any regulatory registrations for the token and provide related documentation (including an explanation of any past or existing interactions with any regulatory authorities, regardless of jurisdiction), if applicable. +10. (Optional) Has your project obtained any legal opinions or memoranda regarding the regulatory standing of the token or an explanation of the same from the perspective of any jurisdiction? If so, those materials should be provided for community review. +11. (Optional) Describe whether there are any regulatory registrations for the token and provide related documentation (including an explanation of any past or existing interactions with any regulatory authorities, regardless of jurisdiction), if applicable. 12. (Optional) List any possible oracle data sources for the proposed Collateral type. 13. (Optional) List any parties interested in taking part in liquidations for the proposed Collateral type. @@ -83,16 +96,11 @@ MIP6-SPs will be used to define changes to the required fields of this collatera In order to submit a MIP6-Subproposals, one must create a MIP from the provided template. **MIP6-SP Template:** - -- **Feedback Period**: 3 months - -- **Frozen Period**: 1 months - +- **Feedback Period**: 1 month +- **Frozen Period**: 1 week - **Sub Proposal Template**: - - ``` Introduction @@ -106,11 +114,9 @@ Introduction Specification - - Summary - - A short description of the proposed process improvement. - - Motivation - - Explain the motivation behind why this subproposal necessary. + - Explain the motivation behind the changes to the application questions. + + - List of changes to Application questions. - - Proposal Details - - Proposal details about why MIP6 needs to be changed. The specification section should highlight the Feedback Period of the proposal MIP and the scope of what the MIP should contain. It must also describe exactly what you will put in the SP based on the parent MIP. +``` diff --git a/mip7.md b/mip7.md index a0142e92a..85b1ea575 100644 --- a/mip7.md +++ b/mip7.md @@ -1,27 +1,39 @@ # MIP7: Onboarding and Offboarding Domain Teams (Collateral Onboarding) - ## Preamble ``` MIP#: 7 Title: Onboarding and Offboarding Domain Teams (Collateral Onboarding) -Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23), Leo Jsaraceno (Mitote), Helge Andreas Qvam (@planet_X) +Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) +Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Type: Process -Status: +Status: Request for Comments (RFC) Date Proposed: 2020-04-06 Dependencies: n/a Replaces: n/a ``` -### Components -**MIP7c1:** Domain Team Descriptions -**MIP7c2:** The Current Domain Roles List -**MIP7c3:** Domain Team onboarding -**MIP7c4:** Domain Team offboarding +## Sentence Summary + +MIP7 defines processes for onboarding and offboarding domain teams. -## Summary +## Paragraph Summary The Domain Teams Onboarding & Offboarding proposal provides a predictable framework for both onboarding and offboarding domain teams required for the collateral onboarding process. +## Component Summary + +**MIP7c1: Domain Team Descriptions** +Describes the various domain teams and their responsibilities as they relate to the collateral onboarding process. + +**MIP7c2: The Current Domain Roles List** +A list component that is kept up-to-date with the currently ratified domain teams. + +**MIP7c3: Domain Team onboarding** +A process component that defines a method and a template that allows the onboarding of domain teams. + +**MIP7c4: Domain Team offboarding** +A process component that defines a method and a template that allows the offboarding of domain teams. + ## Motivation The Maker Protocol requires a decentralized workforce in order to onboard new collateral assets. This MIP describes Domain Teams that are needed in the collateral onboarding process and highlights their special authority in the governance system to oversee critical processes and mitigate risk. @@ -30,10 +42,9 @@ The Maker Protocol requires a decentralized workforce in order to onboard new co ### MIP7c1: Domain Team Descriptions - -- **Risk Teams** are responsible for creating the risk construct for a collateral onboarding proposal. As a part of the collateral on-boarding process, they also need to get a general model ratified on which they can base their risk construct. -- **Smart Contracts Teams** are responsible for developing and deploying the collateral adapter for new collateral onboarding, and creating the technical work product for collateral onboarding proposals. - **Oracle Teams** are responsible for designing oracle feed mechanisms for new collateral types, compelling the oracles to upgrade their nodes with new price feeds for new collateral types via MIP10, and creating the oracle work product for collateral onboarding. +- **Smart Contracts Teams** are responsible for developing and deploying the collateral adapter for new collateral onboarding, and creating the technical work product for collateral onboarding proposals. +- **Risk Teams** are responsible for creating the risk construct for a collateral onboarding proposal. As a part of the collateral on-boarding process, they also need to get a general model ratified on which they can base their risk construct. - **Legal Teams** are in some cases necessary for collateral onboarding, when dealing with assets that have legal claims attached to them. They create the legal work product for collateral onboarding. @@ -43,15 +54,33 @@ The Maker Protocol requires a decentralized workforce in order to onboard new co This list can be amended through the onboarding (MIP7c3) and offboarding components (MIP7c4) of MIP7. -- Risk Team Names: -- Smart Contracts Team Names: -- Oracle Team Names: -- Legal Team Names: +**Entries into this list should follow the following template:** + +``` +- Team Name: The name of the onboarded domain team. +- Sub-proposal Number (MIP7c3-SP): # +- Domain: The domain in which the team operates. +- Date Added: +``` + +**Active Domain Teams List** + +**1. Oracle Domain Teams:** +- **Team Name:** Green Team + - **Sub-proposal Number (MIP7c3-SP):** n/a (Oracle Team was ratified prior to the MIPs process. Reference: [Mandate: Oracle Teams](https://forum.makerdao.com/t/mandate-oracle-teams/443)) + - **Domain:** Oracle + - **Date Added:** 2019-10-7 [Poll: Ratify the Interim Oracle Team Mandate](https://vote.makerdao.com/polling-proposal/qmas1bqrquo2h41qv4fa8hpek9ukb7dlwtpkpn62r5hhmq) + +**2. Smart Contracts Domain Teams:** + +**3. Risk Domain Teams:** + +**4. Legal Domain Teams:** --- ### MIP7c3: Domain Team Onboarding -- **Outcome:** Domain team is either onboarding successfully or is rejected. If onboarded, the Domain Team name is included in the MIP7c2 Domain Roles list. +- **Outcome:** Domain team is either onboarding successfully or is rejected. If onboarded, the domain team is added to the The Current Domain Team Roles list defined in MIP7c2 by the MIP Editor. - **Feedback Period**: 3 months - **Frozen Period**: 1 month - **Onboarding template:** @@ -61,38 +90,36 @@ Introduction - Domain: - Domain Team Name: - - Name of applicant: - - New or Existing Domain Team: Yes or No + - Author: - Date Applied: Application -- Domain Role / Team +- Domain Team Introduction - - The domain team that the applicant wants to join - - The domain team that the applicant wants to create + - Brief introduction / pitch of the team, why they want to work. -- Motivation to work +- Motivation - - Explanation of why and how you want to help the domain team you are applying to + - Why the team wants to join a certain domain. - Work Credentials - - Full name - - Past work experience + - Full names of members + - Past work experience of members - Relevant Information - - Github account - - Forum account + - Github accounts + - Forum accounts - Other ``` --- ### MIP7c4: Domain Team offboarding -- **Outcome:** The Domain team is offboarded and the Domain team name specified in MIP7c2 is removed from the MIP7c2 list. +- **Outcome:** The Domain team is offboarded and the Domain team is removed from the Current Domain Team Roles list defined in MIP7c2 by the MIP Editor. - **Feedback Period**: 0 days - **Frozen Period**: 0 days - **Offboarding template:** diff --git a/mip8.md b/mip8.md index e9f67e546..9a10e6b9e 100644 --- a/mip8.md +++ b/mip8.md @@ -11,13 +11,20 @@ Date Proposed: 2020-04-06 Dependencies: n/a Replaces: n/a ``` -### Components -**MIP8c1:** The Domain Greenlight Requirements and Process -## Summary +## Sentence Summary + +MIP8 defines the process by which domain teams signal that a potential collateral type is worth the time spent investigating its inclusion in the Maker Protocol. + +## Paragraph Summary This proposal aims to define the process where at least one domain team from each domain (Risk, Smart Contracts, Oracles, Legal, etc) "Greenlights" the collateral type (based on research) in order for the collateral onboarding process to proceed. +## Component Summary + +**MIP8c1: The Domain Greenlight Requirements and Process** +Defines the process, requirements and possible outcomes from the domain greenlight process. + ## Motivation The goal of this proposal is to inform the community about the pre-evaluation stage with the aim of identifying any show-stopping problems before time is spent on a full evaluation of the collateral type. diff --git a/mip9.md b/mip9.md index 5f78d2a01..2f64e09d3 100644 --- a/mip9.md +++ b/mip9.md @@ -1,11 +1,11 @@ # MIP9: Community Greenlight - ## Preamble ``` MIP#: 9 Title: Community Greenlight -Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL), Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) +Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Type: Process Status: Date Proposed: 2020-04-06 @@ -13,14 +13,22 @@ Dependencies: MIP6, MIP8 Replaces: n/a ``` -### Components -**MIP9c1:** The Community Greenlight Requirements and Process -**MIP9c2:** Governance Poll Template +## Sentence Summary + +MIP9 defines the process by which MKR Token Holders can signal their judgement on the value of a potential collateral type before domain teams spent time fully investigating its inclusion into the Maker Protocol. -## Summary +## Paragraph Summary This proposal aims to standardize the process for allowing MKR Token Holders to inform the Domain Teams of their preferences for collateral types that have been proposed through MIP6. The preferences of the MKR Token holders are expressed in the form of an on-chain governance poll. The governance poll (Greenlight poll) runs at the end of the governance cycle and will run for a period of two weeks. +## Component Summary + +**MIP9c1: The Community Greenlight Requirements and Process** +Defines the process, requirements and possible outcomes from Community Greenlight process and the Governance Facilitators responsibilities in its operation. + +**MIP9c2: Governance Poll Template** +Defines a governance poll template to be used in the on-chain Community Greenlight poll. + ## Motivation While domain teams are free to choose their own workload, an on-chain governance poll provides the Domain Teams key insights into the community's sentiment for each collateral type that has been proposed. In addition to this, it is important to gather the opinion of MKR Token Holders towards the proposed collateral asset before the full domain work takes place. This helps prevent work from being wasted on undesirable collateral types.