diff --git a/MIP0/General-MIP-Template.md b/MIP0/General-MIP-Template.md new file mode 100644 index 000000000..aa6fbbff2 --- /dev/null +++ b/MIP0/General-MIP-Template.md @@ -0,0 +1,38 @@ +# General MIP Template + +## Preamble +``` +MIP#: +Title: +Author(s): +Contributors: +Type: +Status: +Date Proposed: +Date Ratified: +Dependencies: +Replaces: +``` +## References + +- A list of supporting materials referenced by this MIP. + +## Sentence Summary + +- A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. + +## Paragraph Summary + +- 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 + +- A short description of the motivation behind the MIP. + +## Specification / Proposal Details + +- Proposed process standard details - describes the new process or feature and the problem it is solving. diff --git a/MIP0/MIP0c12-Subproposal-Template.md b/MIP0/MIP0c12-Subproposal-Template.md new file mode 100644 index 000000000..d14297c0d --- /dev/null +++ b/MIP0/MIP0c12-Subproposal-Template.md @@ -0,0 +1,28 @@ +# MIP0c12: Subproposal Template for Core Personnel Onboarding + +## Preamble + +``` +MIP0c12-SP#: # +Author(s): +Contributors: +Status: +Date Applied: +Date Ratified: +--- +Core Personnel Role: MIP Editor or Governance Facilitator +Proposed applicant: Name of applicant +``` + +## Application + +### Motivation +- Explanation of why and how you want to fulfil this role. + +### Credentials +- Past work experience. + +### Relevant Information +- Github Account +- MakerDAO Forum Account +- Other relevant Accounts diff --git a/MIP0/Subproposals for Core Personnel Onboarding (MIP0c12)/MIP0c12-SP1.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP1.md similarity index 100% rename from MIP0/Subproposals for Core Personnel Onboarding (MIP0c12)/MIP0c12-SP1.md rename to MIP0/MIP0c12-Subproposals/MIP0c12-SP1.md diff --git a/MIP0/MIP0c13-Subproposal-Template.md b/MIP0/MIP0c13-Subproposal-Template.md new file mode 100644 index 000000000..82bf4c468 --- /dev/null +++ b/MIP0/MIP0c13-Subproposal-Template.md @@ -0,0 +1,22 @@ +# MIP0c13: Subproposals Template for Core Personnel Offboarding + +## Preamble +``` +MIP0c13-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: +Date Removed: +--- +Core Personnel Role: MIP Editor or Governance Facilitator +Core Personnel to be removed: +``` + +## Removal Application and Supporting Evidence + +### Motivation +- The explanation behind the removal of the person from the role listed above. + +### Relevant Information +- Links to evidence further backing the motivation behind the removal of the person from the role listed above. diff --git a/MIP0/Subproposals for Core Personnel Offboarding (MIP0c13)/Placeholder b/MIP0/MIP0c13-Subproposals/Placeholder.md similarity index 100% rename from MIP0/Subproposals for Core Personnel Offboarding (MIP0c13)/Placeholder rename to MIP0/MIP0c13-Subproposals/Placeholder.md diff --git a/MIP0/Technical-MIP-Template.md b/MIP0/Technical-MIP-Template.md new file mode 100644 index 000000000..f0db421c1 --- /dev/null +++ b/MIP0/Technical-MIP-Template.md @@ -0,0 +1,67 @@ +# Technical MIP Template + +## Preamble +``` +MIP#: <# to be assigned> +Title: +Author(s): +Contributors: +Type: MIP Type +Status: +Date Proposed: +Date Ratified: +Dependencies: +Replaces: +License: +``` +## References + +- A list of supporting materials referenced by this MIP. + +## Sentence Summary + +- A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. + +## Paragraph Summary + +- 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 + +- A short description of the motivation behind the proposed technical solution. + +## Specification + +The details of the proposed technical solution. The specification should be detailed enough to allow an implementation team to begin development as well as testing. The specification for technical MIPs must include the following components: + + +### Proposed Code + - The final code that can be used directly in the executive vote to accept or reject the MIP. + + +### Test Cases + - For the implementation or testing of the proposed code + +### Security Considerations + + - This is one of the most important aspects of the Technical MIP proposal. The purpose of this section is to proactively document any security-relevant design information, decisions, potential failure modes, implementation details, and important discussions related to the proposed change. This section helps to optimize the MIP process by providing proactive guidance on security considerations when proposing a change that will affect the Maker Protocol. + - Backwards compatibility + +### Auditor Information and Report + + - This section includes the audit partner details and the final audit report for the proposed code. + +### Licensing + - Recommended licenses for developed code: + - MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT) + - BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause) + - BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) + - CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/) + - GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html) + - Apache-2.0: [Apache License, version 2.0](http://www.apache.org/licenses/LICENSE-2.0) + diff --git a/MIP0/Templates/General-MIP-Template.md b/MIP0/Templates/General-MIP-Template.md deleted file mode 100644 index 9ac34f5c0..000000000 --- a/MIP0/Templates/General-MIP-Template.md +++ /dev/null @@ -1,38 +0,0 @@ -# General MIP Template - -## Preamble -``` -MIP#: -Title: -Author(s): -Contributors: -Type: -Status: -Date Proposed: -Date Ratified: -Dependencies: n/a -Replaces: n/a -``` -## References - -A list of supporting materials referenced by this MIP. - -## Sentence Summary - -A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. - -## Paragraph Summary - -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 - -A short description of the motivation behind the MIP. - -## Specification / Proposal Details - -Proposed process standard details - describes the new process or feature and the problem it is solving. diff --git a/MIP0/Templates/Subproposal-Template-Core-Personnel-Offboarding.md b/MIP0/Templates/Subproposal-Template-Core-Personnel-Offboarding.md deleted file mode 100644 index 35c862ab9..000000000 --- a/MIP0/Templates/Subproposal-Template-Core-Personnel-Offboarding.md +++ /dev/null @@ -1,16 +0,0 @@ -# Subproposal Template for Core Personnel Offboarding - -## Preamble - - - Core Role: - - Personnel to be removed: - - Date of Proposed Removal: - - Date Removed: - -## Removal Form and Supporting Evidence - - - Motivation: - - The explanation behind the removal of the person from the role given above. - - - Relevant Information: - - Links to evidence further backing the motivation behind the removal of the person from the role given above. diff --git a/MIP0/Templates/Subproposal-Template-Core-Personnel-Onboarding.md b/MIP0/Templates/Subproposal-Template-Core-Personnel-Onboarding.md deleted file mode 100644 index 82962527a..000000000 --- a/MIP0/Templates/Subproposal-Template-Core-Personnel-Onboarding.md +++ /dev/null @@ -1,22 +0,0 @@ -# Subproposal Template for Core Personnel Onboarding - -## Preamble - -- Core Role: -- Name of applicant or proposed applicant: -- Date Applied: -- Date Onboarded: - - -## Application Form - -- Motivation: - - Explanation of why and how you want to fulfil this role. - -- Credentials: - - Past work experience - - Github account - - Forum account - -- Relevant Information: - - Links to forum posts, blog posts, or any other community contributions related to Maker. diff --git a/MIP0/Templates/Technical-MIP-Template.md b/MIP0/Templates/Technical-MIP-Template.md deleted file mode 100644 index de7bdb9b8..000000000 --- a/MIP0/Templates/Technical-MIP-Template.md +++ /dev/null @@ -1,67 +0,0 @@ -# Technical MIP Template - -## Preamble -``` -MIP#: <# to be assigned> -Title: -Author: -Contributors: -Type: MIP Type -Status: -Date Proposed: -Date Ratified: -Dependencies: -Replaces: -License: -``` -## References - -A list of supporting materials referenced by this MIP. - -## Sentence Summary - -A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. - -## Paragraph Summary - -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 - -A short description of the motivation behind the proposed technical solution. - -## Specification - -The details of the proposed technical solution. The specification should be detailed enough to allow an implementation team to begin development as well as testing. The specification for technical MIPs must include the following components: - - -- **Proposed Code:** - - The final code that can be used directly in the executive vote to accept or reject the MIP. - - -- **Test Cases:** - - For the implementation or testing of the proposed code - -- **Security Considerations** - - - This is one of the most important aspects of the Technical MIP proposal. The purpose of this section is to proactively document any security-relevant design information, decisions, potential failure modes, implementation details, and important discussions related to the proposed change. This section helps to optimize the MIP process by providing proactive guidance on security considerations when proposing a change that will affect the Maker Protocol. - - Backwards compatibility - -- **Auditor Information and Report** - - - This section includes the audit partner details and the final audit report for the proposed code. - -- **Licensing** - - Recommended licenses for developed code: - - MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT) - - BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause) - - BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) - - CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/) - - GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html) - - Apache-2.0: [Apache License, version 2.0](http://www.apache.org/licenses/LICENSE-2.0) - diff --git a/MIP0/mip0.md b/MIP0/mip0.md index b34c100af..f492bb554 100644 --- a/MIP0/mip0.md +++ b/MIP0/mip0.md @@ -7,14 +7,17 @@ Title: The Maker Improvement Proposal Framework Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[General-MIP-Template.md](General-MIP-Template.md)** +**[Technical-MIP-Template.md](Technical-MIP-Template.md)** +**[MIP0c12-Subproposal-Template.md](MIP0c12-Subproposal-Template.md)** +**[MIP0c13-Subproposal-Template.md](MIP0c13-Subproposal-Template.md)** ## Sentence Summary @@ -72,7 +75,6 @@ MakerDAO is evolving into an organization that is trustless, fully decentralized The purpose of the MIPs Framework is to open up the ability to improve Maker Governance and the Maker Protocol to anyone in the community. - By empowering the participation of the community and other stakeholders to have a standard approach to proposing improvements, specifications, or process and state changes, the goal is to enable organic growth that will in turn bring MakerDAO closer to self-sustainability. In order for MIPs to be functional they need to comply with a basic standard outlining their internal structure and external dependencies. This standard is MIPs described in MIP0, the Maker Improvement Proposal Framework. @@ -119,7 +121,6 @@ In order for MIPs to be functional they need to comply with a basic standard out **MIP Status Criteria** - **1. Conception:** The lifecycle of a MIP begins when the MIP proposal is posted on the Maker forum. However, in order for a MIP to move to the next stage, it needs to satisfy the transition criteria (1) described below: @@ -138,14 +139,12 @@ In order for MIPs to be functional they need to comply with a basic standard out - MIP Author finalizes changes of the MIP, based on community feedback. - MIPs have a Feedback Period of 3 months. The RFC phase lasts at least 3 months before the MIP can move to the next phase. - MIPs have a Frozen Period of 1 month. MIPs must not have had any changes for the last 1 month before they move to the next phase. - **4. Fulfilled Feedback Period Requirements:** This status is given once the MIP has fulfilled the defined Feedback Period and Frozen Period. After the MIP has waited out its Feedback Period and Frozen Period, it’s ready for Formal Submission. Note that the Feedback Period and Frozen Period can overlap. **5. Formal Submission (FS):** This phase is when MIP Authors submit their complete MIP(s) to the Governance cycle by posting it to the formal submission forum category within the formal submission window of a governance cycle. - A MIP can be re-submitted to the formal submission process a maximum of 2 additional times (3 total), without having to go through phase 1- 4 again, if it failed to pass due to legitimate external reasons (e.g. got bundled in a governance poll or executive vote with a controversial proposal - subject to the governance facilitators judgement). - **6. Approved by the Governance Facilitator(s):** This phase is when the MIP must be formally approved by the Governance Facilitators. - Once approved by the Governance Facilitator, the MIP will be included in the inclusion poll of the Governance cycle. @@ -159,7 +158,6 @@ In order for MIPs to be functional they need to comply with a basic standard out **9. Accepted/Rejected:** The Executive vote results in either acceptance or rejection of the MIP. If passed, the MIP is officially accepted and is given the accepted status. If the executive vote fails to pass before expiring, the MIP is rejected. - As described in phase 5, a rejected MIP, can be resubmitted, and in some cases (if it was rejected for provable extraneous explanation) may be allowed to enter the next Governance cycle immediately. - **Other MIP Statuses:** @@ -212,11 +210,12 @@ A status change for a MIP is requested by the MIP Author and will be reviewed by -- **Sub Proposals** +- **Subproposals** - **Summary:** A MIP component creates a bespoke process that is engaged by submitting sup proposals according to the framework specified in the process MIP component. - - - The subproposal component naming convention is `MIP#c#-SP#`. This is important in order to delineate between different SPs under the same MIP. + **Summary:** A subproposal is an expedited process that is defined within a MIP to serve as a definition of how to run a given process within the MIPs framework. + +- Subproposals require a template, a feedback period and a frozen period and are submitted using that template. Subproposals go through the MIPs process in the same way that full MIPs do. The template, feedback period and frozen period for a set of subproposals are defined using a MIP component known as a Process component. Any MIP containing a Process Component gains the Process type. +- The subproposal naming convention is MIPXcY-SPZ where Y is the Process Component that contains the subproposal template and X is the MIP containing that component. This is important in order to delineate between different types of subproposal defined in the same MIP under different Process components. **Special Template:** N/A @@ -232,123 +231,21 @@ Due to the fact that the dependencies carry over, a MIP with defined replacement ### MIP0c6: Supporting Materials -MIPs can optionally refer to external materials. External Materials must be added to the MIPs github in the same folder as the MIP which references them. +MIPs can optionally refer to external materials. External materials must be added to the MIPs github in the same folder as the MIP which references them. Externally referenced materials are not MIP content, and are not ratified when a MIP becomes Accepted unless it is explicitly stated otherwise in a MIP Component specification. -MIP References are named according to their parent MIP. The convention MIPXrY is used to refer to external materials. When referenced inline the reference should include both the reference code and the title and it should be bolded. For example: **MIPXrY - My Important Supporting Material** - --- ### MIP0c7: MIP Templates **General MIP Template** +- The General MIP Template should be used for MIPs whenever a more specific ratified template is not more appropriate. +- The General MIP Template is located at **[General-MIP-Template.md](General-MIP-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -**Preamble** -``` -MIP#: -Title: -Author(s): -Contributors: -Type: -Status: -Date Proposed: -Date Ratified: -Dependencies: n/a -Replaces: n/a -``` -**References** - -A list of supporting materials referenced by this MIP. - -**Sentence Summary** - -A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. - -**Paragraph Summary** - -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** - -A short description of the motivation behind the MIP. - -**Specification / Proposal Details** - -Proposed process standard details - describes the new process or feature and the problem it is solving. - ---- - **Technical MIP Template** - -**Preamble** -``` -MIP#: <# to be assigned> -Title: -Author: -Contributors: -Type: MIP Type -Status: -Date Proposed: -Date Ratified: -Dependencies: -Replaces: -License: -``` -**References** - -A list of supporting materials referenced by this MIP. - -**Sentence Summary** - -A description of what the Maker Improvement Proposal (MIP) is focused on. Suggest 30 words max. - -**Paragraph Summary** - -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** - -A short description of the motivation behind the proposed technical solution. - -**Specification** - -The details of the proposed technical solution. The specification should be detailed enough to allow an implementation team to begin development as well as testing. The specification for technical MIPs must include the following components: - - -- **Proposed Code:** - - The final code that can be used directly in the executive vote to accept or reject the MIP. - - -- **Test Cases:** - - For the implementation or testing of the proposed code -- **Security Considerations** - - - This is one of the most important aspects of the Technical MIP proposal. The purpose of this section is to proactively document any security-relevant design information, decisions, potential failure modes, implementation details, and important discussions related to the proposed change. This section helps to optimize the MIP process by providing proactive guidance on security considerations when proposing a change that will affect the Maker Protocol. - - Backwards compatibility - -- **Auditor Information and Report** - - - This section includes the audit partner details and the final audit report for the proposed code. - -- **Licensing** - - Recommended licenses for developed code: - - MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT) - - BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause) - - BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) - - CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/) - - GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html) - - Apache-2.0: [Apache License, version 2.0](http://www.apache.org/licenses/LICENSE-2.0) - +- The Technical MIP Template should be used for MIPs whenever a MIP proposes changes to the smart contract code within the Maker Protocol. +- The Technical MIP Template is located at **[Technical-MIP-Template.md](Technical-MIP-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. --- ### MIP0c8: MIP0 Domain Role Dependencies @@ -393,7 +290,11 @@ Entries into this list should follow the following template: - **Date Added:** 2019-09-09 ([Poll: Ratify the Interim Governance Facilitator Mandate](https://vote.makerdao.com/polling-proposal/qmvh4z3l5ymqgtfs6tifq3jpjx5mxgdfnjy6alewnwwvba)) 2. **MIP Editors:** -- There are no active MIP Editors at this point in time. + +- **Person Name:** Charles St.Louis + - **Sub-proposal Number (MIP0c12-SP):** 1 + - **Core Role:** MIP Editor + - **Date Added:** 2020-05-02 ([Ratification Vote](https://vote.makerdao.com/executive-proposal/lower-usdc-sf-add-wbtc-ratify-the-initial-mips-and-subproposals)) --- @@ -527,61 +428,21 @@ The removal process begins once the community has agreed on the reasoning for re ### MIP0c12: Core Personnel Onboarding -**A MIP0 Sub Proposal is required to onboard core personnel** +MIP0c12 is a Process MIP component that allows the onboarding of core personnel using a subproposal. MIP0c12 subproposals have the following parameters: +- **Feedback Period**: 3 months +- **Frozen Period**: 1 month -- **Subproposal Feedback Period**: 3 months -- **Sub proposal Frozen Period**: 1 month -- **Sub proposal template**: +MIP0c12 subproposals must use the template located at **[MIP0c12-Subproposal-Template.md](MIP0c12-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -``` - -Introduction - -- Role: - -- Name of applicant or proposed applicant: - -- Date Applied: - - -Application Form - -- Motivation: - - Explanation of why and how you want to fulfil this role. - -- Credentials: - - Past work experience - - Github account - - Forum account - -- Relevant Information: - - Links to forum posts, blog posts, or any other community contributions related to Maker. -``` --- ### MIP0c13: Core Personnel Offboarding -**A MIP0 Sub Proposal is required to remove core personnel** - -- **Sub proposal Feedback Period**: 0 days -- **Sub proposal Frozen Period**: 0 days -- **Sub proposal template**: - -``` -Introduction - - - Role: +MIP0c13 is a Process MIP component that allows the removal of core personnel using a subproposal. MIP0c13 subproposals have the following parameters: - - Person to be removed: +- **Feedback Period**: 0 days +- **Frozen Period**: 0 days - - Date of Proposed Removal: - -Removal Form and Supporting Evidence - - - Motivation: - - The explanation behind the removal of the person from the role given above. +MIP0c13 subproposals must use the template located at **[MIP0c13-Subproposal-Template.md](MIP0c13-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. - - Relevant Information: - - Links to evidence further backing the motivation behind the removal of the person from the role given above. -``` --- diff --git a/MIP1/MIP1c4-Subproposal-Template.md b/MIP1/MIP1c4-Subproposal-Template.md new file mode 100644 index 000000000..80ba38b04 --- /dev/null +++ b/MIP1/MIP1c4-Subproposal-Template.md @@ -0,0 +1,19 @@ +# MIP1c4: Subproposal for changing the Problem Space + +## Preamble +``` +MIP1c4-SP#: # +Titlle of problem Space Item to be Added or Deleted: +Author(s): +Contributors: +Status: +Date of Submission: +Date of Ratification: +``` +## Specification + +### Motivation +- Explanation behind the addition or deletion to the Problem Space list. + +### Relevant Information +- Links to evidence further backing the motivation. diff --git a/MIP1/MIP1c4-Subproposals/placeholder.md b/MIP1/MIP1c4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP1/MIP1c4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP1/mip1.md b/MIP1/mip1.md index 30d7282bd..3ccca4717 100644 --- a/MIP1/mip1.md +++ b/MIP1/mip1.md @@ -7,15 +7,15 @@ Title: Governance Paradigms Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: +Date Ratified: 2020-05-2 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[MIP1c4-Subproposal-Template.md](MIP1c4-Subproposal-Template.md)** ## Sentence Summary @@ -27,17 +27,16 @@ A Governance Paradigm is a complete and specific group of MIP Sets that solve an ## Component Summary -**MIP1c1: Definitions** +**MIP1c1: Definitions** Defines what is meant by a problem space and a Governance Paradigm. -**MIP1c2: The Initial Problem Space** +**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** +**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** +**MIP1c4: Changing the Problem Space** A process component that provides a method and a template for adjusting the problem space. ## Motivation @@ -117,27 +116,11 @@ An individual MIP or MIP Set in the active Governance Paradigm cannot be replace 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. - +MIP1c4 is a Process MIP component that allows the creation of subproposals that can add or delete items in the Governance Paradigm Problem Space. MIP1c4 subproposals have the following parameters: - **Feedback Period**: 3 months - **Frozen Period**: 1 month -- **Template**: - -``` -Introduction - - Problem Space Item to be Added or Deleted: +MIP1c4 subproposals must use the template located at **[MIP1c4-Subproposal-Template.md](MIP1c4-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. - - Author: - - Date of Submission: - -Specification - - - Motivation: - - Explanation behind the addition or deletion to the Problem Space list. - - - Relevant Information: - - Links to evidence further backing the motivation. - - ``` +--- diff --git a/MIP10/MIP10c10-Subproposal-Template.md b/MIP10/MIP10c10-Subproposal-Template.md new file mode 100644 index 000000000..68b800ed9 --- /dev/null +++ b/MIP10/MIP10c10-Subproposal-Template.md @@ -0,0 +1,30 @@ +# MIP10c10: Subproposal to Whitelist Oracle Access + +## Preamble +``` +MIP10c10-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction + +### Oracle Name +- What is the name of the Oracle(s) in MIP10c5? + +### Customer(s) +- < customer name > < point of contact email > + +### Removal Type +- < voluntary/involuntary > + +### Reason for Removal + +### Whitelist +- < Oracle Name > - < address(es) whitelisted > - < Medianizer/OSM > \ No newline at end of file diff --git a/MIP10/MIP10c10-Subproposals/placeholder.md b/MIP10/MIP10c10-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c10-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c11-List-of-Oracle-Whitelists.md b/MIP10/MIP10c11-List-of-Oracle-Whitelists.md new file mode 100644 index 000000000..a72a05cdd --- /dev/null +++ b/MIP10/MIP10c11-List-of-Oracle-Whitelists.md @@ -0,0 +1,68 @@ +# MIP10c11: Subproposal for List of Oracle Whitelists + +## Glossary + +- **Oracle Name:** The name of the Oracle as indicated in MIP10c5 +- **Oracle Classification:** The type of Oracle, can be Medianizer or Oracle Security Module (OSM) +- **Contract Address:** The Ethereum address of the Oracle contract +- **Customer** The whitelisted entity +- **Date Joined:** Date the customer was added to the whitelist +- **Email:** The point of contact with the customer for all issues relating to Oracles. +- **Fee (Dai):** The monthly whitelisting fee in Dai. +- **Whitelisted Contract:** The Ethereum address of the whitelisted contract +- **Origin:** A link to the Governance Vote that added the customer to the Oracle whitelist. + +## Template Spec + +**Oracle Name:** < name in MIP10c5 > +**Oracle Classification:** | < yyyy-mm-dd > | < email > | < # > | < address > | < link to MIP10c3/MIP10c9 > | + +## Oracle Whitelists + +**Oracle Name:** BAT/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0x18B4633D6E39870f398597f3c1bA8c4A41294966 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | + +**Oracle Name:** BAT/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :------------- | :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | + +**Oracle Name:** BTC/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0xe0F30cb149fAADC7247E953746Be9BbBB6B5751f +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :-------------------------- | +| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0xbf63446ecF3341e04c6569b226a57860B188edBc | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmealoapl7e1yzabsobg9wckj3bs8hb8pgquc5jx7r8qpo) | +| dYdX | 2020-04-25 | contact@dydx.exchange | ROMP | 0x538038E526517680735568f9C5342c6E68bbDA12 | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmealoapl7e1yzabsobg9wckj3bs8hb8pgquc5jx7r8qpo) | + +**Oracle Name:** ETH/BTC +**Oracle Classification:** Medianizer +**Contract Address:** 0x81A679f98b63B3dDf2F17CB5619f4d6775b3c5ED +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | +| tBTC | 2020-04-25 | N/A | ROMP | TBD | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmeymkw5rhenzsevpvnhequj9glvq6n5buzapyrvestcdg) | + +**Oracle Name:** ETH/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0x64DE91F5A373Cd4c28de3600cB34C7C6cE410C85 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :--------------| :------------- | :------------------- | :-------- | :----------------------------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | +| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0x97C3e595e8f80169266B5534e4d7A1bB58BB45ab | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmzfpgr8hwabpycsq6vnnzp2cebh8uzxjpor8rtzenhkop) | + +**Oracle Name:** ETH/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | +| :------------- | :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | \ No newline at end of file diff --git a/MIP10/MIP10c12-Subproposal-Template.md b/MIP10/MIP10c12-Subproposal-Template.md new file mode 100644 index 000000000..7bac6ff64 --- /dev/null +++ b/MIP10/MIP10c12-Subproposal-Template.md @@ -0,0 +1,54 @@ +# MIP10c12: Subproposal to Update Oracle Access Fee + +## Preamble +``` +MIP10c12-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- What is the problem with our current Oracle Access Fee? +- Why do we need a new Oracle Access Fee? + +### Oracle Access Fee Model Strategy +- How does the proposed model work? + - Is it based on a strategy to grow the customer base? + - Is it based on a strategy to reign in costs to a more sustainable business model? + - Is it based on a loss-leader strategy to strengthen the brand of the Maker Protocol? + - How are prices applied across different Oracles and different customers? + - Is it a flat-fee applied uniformly across every Oracle and customer? + - Is it applied to how much value a customer derives from the Oracle? + - Is it dependent on how many Oracles a customer is whitelisted on? + - Is it dependent on how many customers use a particular Oracle? + - Is it dependent on how long a customer has used our Oracles? + - Is it dependent on the type of data the Oracle is broadcasting? + - Is it dependent on the Oracle Spread / Oracle Expiration Time of the Oracle? + - Does the price differ if the customer is also a Light Feed? + - Does the price differ between the Medianizer and Oracle Security Module? What if a customer wants both? + - Are fees waived for certain classes of customers? Why? + - Are prices dependent on what our competitors charge? +- How many customers are expected to be lost or gained due to this change in pricing? + +### Supporting Data +- Empirical data supporting your Model Strategy + +### Material Changes Template +- Use state of [MIP10c11-List-of-Oracle-Whitelists](MIP10c11-Subproposal-Template.md) to get all customers per Oracle. +- Only customers whose Fees are being updated need be included in the template. + +**Oracle Name:** +**Oracle Classification:** | < yyyy-mm-dd > | < # > | < address > | < data > | < data > | + +### Changelog +- List of updates diff --git a/MIP10/MIP10c12-Subproposals/placeholder.md b/MIP10/MIP10c12-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c12-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c13-Subproposal-Template.md b/MIP10/MIP10c13-Subproposal-Template.md new file mode 100644 index 000000000..cbcd7c6da --- /dev/null +++ b/MIP10/MIP10c13-Subproposal-Template.md @@ -0,0 +1,55 @@ +# MIP10c13: Subproposal to Appoint Dark Feed + +## Preamble +``` +MIP10c13-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- Motivation for running a Dark Feed +- Do not disclose any personally identifiable information. + +### Experience Template + +| Role | Network | Began Role | Role Duration | Public Key | Tokens Staked | Max Stake Value (USD) | Max Network Value (USD) | Can Sign Message w/ Key? | +| :------------ | :--------| :------------ |:------------- | :---------- | :------------ | :-------------------- | :---------------------- | :----------------------- | +| < validator > | < name > | | < # months > | < address > | < # token > | < $# > | < # > | < bool > | + +| Role | Network | Began Role | Role Duration | Public Key | Tokens Staked | Max Hash Power (MH/s) | Max Network Hash Power (MH/s) | Can Sign Message w/ Key? | +| :------------ | :--------| :------------ |:------------- | :---------- | :------------ | :-------------------- | :---------------------------- | :----------------------- | +| < miner > | < name > | | < # months > | < address > | < # token > | < $# > | < # > | < bool > | + +### Experience +- What experience does the proposer have running a miner or validator? +- For which blockchain or similar decentralized network? +- For what length of time did/does the proposer run a miner or validator? +- When did they begin running the miner and/or validator? +- What are the public keys for the miner(s)/validator(s). +- Can the proposer sign a custom message using their private keys to prove their identity? +- Was there any stake put up to punish bad behavior? +- How much value was the miner/validator securing? +- What proportion of the hash power/validator stake did/does the miner/validator have? +- How can the Oracle Team(s) and community best verify the claims made? +- Are there reputable block explorers that can be referenced? + +### Evidence +- Empirical evidence supporting the experience listed above. +- The more, the better. + +### Identity +- Is there any personally indentifiable information linked to the previous experience of running a miner / validator? +- Could the proposer be doxed given extensive effort investigating their past experience? +- If yes, please list the type of information that is available. +- Are there any individuals who are aware of the proposer's miner / validator experienc and their identity? +- If the proposer ceased to run their miner / validator why did they cease operation? Was this voluntary or involuntary? + +### Changelog +- List of updates diff --git a/MIP10/MIP10c13-Subproposals/placeholder.md b/MIP10/MIP10c13-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c13-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c14-Subproposal-Template.md b/MIP10/MIP10c14-Subproposal-Template.md new file mode 100644 index 000000000..658c46de3 --- /dev/null +++ b/MIP10/MIP10c14-Subproposal-Template.md @@ -0,0 +1,39 @@ +# MIP10c14: Subproposal to Appoint Light Feed + +## Preamble +``` +MIP10c14-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Organization +- Name +- Website +- Github +- Number of Employees +- Email < domain must be organization > +- Incorporated +- Domiciled +- Number of employees +- When was the organization founded? +- Who are the major investors in your organization? +- How much funding has the organization raised either privately or through a token sale? +- Please provide public references for the above where possible. + +### Introduction +- Motivation for running a Light Feed + +### Community +- What has your organization contributed to the crypto community? +- Successful products, services, tools, libraries, thought-leadership +- How will the Maker Community benefit from your inclusion as a Light Feed? + +### Changelog +- List of updates diff --git a/MIP10/MIP10c14-Subproposals/placeholder.md b/MIP10/MIP10c14-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c14-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c15-Subproposal-Template.md b/MIP10/MIP10c15-Subproposal-Template.md new file mode 100644 index 000000000..03b3e673c --- /dev/null +++ b/MIP10/MIP10c15-Subproposal-Template.md @@ -0,0 +1,64 @@ +# MIP10c15: Subproposal to Appoint Feed (OT) + +## Preamble +``` +MIP10c15-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction + +### Dark Feeds +**Experience** + +*include revised experience template from MIP10c13 for all info that could be verified by the Oracle Team* + +- Of the claims made, which ones could be verified, which ones could not? +- Was the proposer able to sign a message with their private key for their roles? +- Could the start date and role duration be verified through an immutable blockchain? +- Is/are the role duration(s) significant enough in length to point to a theme of longstanding responsible behavior? +- Is there a way to analyse the historic uptime of the miner / validator? +- Was the hash rate or tokens staked significant enough in magnitude to require significant investment? +- What is the relationship between the fractional stake or hash power relative to the total stake / hash power of the network. +- Is there any evidence this individual ever participated in malicious behavior in their role(s)? + +**Identity** +- Was the Oracle Team able to find any personally identifiable information linking the applicant to their roles? +- Is it likely given the information provided that there are individuals who could identify this person? What order of magnitude? + +### Light Feeds +**Reputation* +- Does the organization have a strong reputation in the crypto community? +- What contributions has this organization made to the crypto ecosystem? +- Would including the organization as a Light Feed instill a sense of trust in the Oracles? +- Are there any public accussations of misconduct? How severe and numerous are they? Have they been confirmed? + +**Verification** +- Were sufficient public-facing resources provided or found that confirm the information in the application? +- Was the applicant honest with respect to: + - the investors + - how much funding was raised + - the number of employees + - the location of incorporation & domicile +- Given the applicant's major investors, is there a risk adding this Light Feed would give a single investor too much influence over the Oracle protocol? +- Given the incorporation and domicile location of the organization, is there a risk adding this Light Feed would give a single jurisdiction too much influence over the Oracle protocol? + +**Identity* +- Did the Oracle Team get in contact with the organization to confirm their application? + +### Cost-Benefit +- Given the ratio of Dark Feeds : Light Feeds, does the Maker Protocol benefit from adding another Dark/Light Feed at this time? +- Given the extra cost of appointing a new Feed, does the benefit of the marginal security / marginal trust in the protocol exceed the cost? + +### Oracle Team Reccomendation +- was the applicant honest with the data they provided? + +### Changelog +- List of updates diff --git a/MIP10/MIP10c15-Subproposals/placeholder.md b/MIP10/MIP10c15-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c15-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c16-Subproposal-Template.md b/MIP10/MIP10c16-Subproposal-Template.md new file mode 100644 index 000000000..983befc75 --- /dev/null +++ b/MIP10/MIP10c16-Subproposal-Template.md @@ -0,0 +1,35 @@ +# MIP10c16: Subproposal to Remove Feed + +## Preamble +``` +MIP10c16-SP#: +Author(s): +Contributors: +Type: Process Component +Oracle Team Name: +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Feed Name +- What is the name of this Feed in MIP10c16? + +### Feed Type +- Is this a Dark or a Light Feed? + +### Removal Motivation +- An explanation behind the motivation for the removal of the Feed. Possible reasons include: + - Feed endangering Maker Protocol due to excessive downtime + - Feed endagering Maker Protocol due to missing update deadlines on multiple occassions + - Feed is proven to engage in malicious behavior + - Feed is proven to engage in behavior not coinciding with the Data Models and Tools ratified by governance. + - Feed is proven to engage in a conspiracy to commit malicious behavior + - Feed is proven to attempt or succeeded in buying / selling the Feed. + - Institution backing a Light Feed is proven to engage in dishonest behavior + - A Dark Feed's identity is doxed in the public domain + +### Relevant Information +- Links to evidence further backing the motivation behind the removal of the Oracle. \ No newline at end of file diff --git a/MIP10/MIP10c16-Subproposals/placeholder.md b/MIP10/MIP10c16-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c16-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c17-List-of-Feeds.md b/MIP10/MIP10c17-List-of-Feeds.md new file mode 100644 index 000000000..c779f5f8c --- /dev/null +++ b/MIP10/MIP10c17-List-of-Feeds.md @@ -0,0 +1,57 @@ +# MIP10c17: Subproposal for List of Feeds + +## Number of Feeds +- **Dark Feeds =** 15 +- **Light Feeds =** 5 +- **Total Feeds =** 20 + +## Glossary + +- **Feed:** Bots run by individuals and institutions that push prices to the Oracles +- **Dark Feed:** An anonymous individual or institution running a Feed +- **Light Feed:** A public institution running a Feed +- **Type:** Feeds can be classified as either Dark or Light Feeds +- **Date Added:** The date a Feed began operating +- **Organization:** The institution running a Light Feed +- **Feed Stipends:** The monthly stipend Feeds are paid for their service +- **MIP:** Maker Improvement Proposal to trace the origin of Feed onboarding +- **Governance Vote:** Ratified governance proposals to onboard Feeds to confirm authorization + +## Template Spec + +| Feed | Type | Date Added | Organization | Feed Stipend | MIP/Subproposal | +| :---------- | :------------- | :---------- | :----------- | :----------- | :-------------------- | +| < address > | < Light/Dark > | < yyyy-mm > | < name > | < amount > | < link > | + + + +## Feed List + +**Dark Feeds** +| Feed | Type | Date Added | Feed Stipend | MIP/Subproposal | +| :----------------------------------------- | :------ | :----------- | :----------- | :------------------ | +| 0xaC8519b3495d8A3E3E44c041521cF7aC3f8F63B3 | Dark | 2017-06 | 1000 DAI | N/A | +| 0x238A3F4C923B75F3eF8cA3473A503073f0530801 | Dark | 2017-06 | 1000 DAI | N/A | +| 0xC9508E9E3Ccf319F5333A5B8c825418ABeC688BA | Dark | 2017-08 | 1000 DAI | N/A | +| 0xA8EB82456ed9bAE55841529888cDE9152468635A | Dark | 2017-08 | 1000 DAI | N/A | +| 0xDA1d2961Da837891f43235FddF66BAD26f41368b | Dark | 2017-08 | 1000 DAI | N/A | +| 0x4b0E327C08e23dD08cb87Ec994915a5375619aa2 | Dark | 2017-08 | 1000 DAI | N/A | +| 0xfeEd00AA3F0845AFE52Df9ECFE372549B74C69D2 | Dark | 2017-09 | 1000 DAI | N/A | +| 0x8aFBD9c3D794eD8DF903b3468f4c4Ea85be953FB | Dark | 2017-11 | 1000 DAI | N/A | +| 0x8de9c5F1AC1D4d02bbfC25fD178f5DAA4D5B26dC | Dark | 2017-11 | 1000 DAI | N/A | +| 0xE6367a7Da2b20ecB94A25Ef06F3b551baB2682e6 | Dark | 2017-12 | 1000 DAI | N/A | +| 0xFbaF3a7eB4Ec2962bd1847687E56aAEE855F5D00 | Dark | 2017-12 | 1000 DAI | N/A | +| 0x83e23C207a67a9f9cB680ce84869B91473403e7d | Dark | 2017-12 | 1000 DAI | N/A | +| 0x16655369Eb59F3e1cAFBCfAC6D3Dd4001328f747 | Dark | 2018-01 | 1000 DAI | N/A | +| 0x4f95d9B4D842B2E2B1d1AC3f2Cf548B93Fd77c67 | Dark | 2018-06 | 1000 DAI | N/A | +| 0xd94BBe83b4a68940839cD151478852d16B3eF891 | Dark | 2018-06 | 1000 DAI | N/A | + + +**Light Feeds** +| Feed | Type | Date Added | Organization | Feed Stipend | MIP/Subproposal | +| :----------------------------------------- | :------- | :----------- | :--------------- | :------------ | :--------------- | +| 0xa580BBCB1Cee2BCec4De2Ea870D20a12A964819e | Light | 2019-11 | Maker Foundation | 1000 DAI | N/A | +| 0xc00584B271F378A0169dd9e5b165c0945B4fE498 | Light | 2019-11 | Set Protocol | 1000 DAI | N/A | +| 0x75ef8432566A79C86BBF207A47df3963B8Cf0753 | Light | 2019-11 | dYdX | 1000 DAI | N/A | +| 0xD27Fa2361bC2CfB9A591fb289244C538E190684B | Light | 2019-11 | 0x | 1000 DAI | N/A | +| 0x60da93D9903cb7d3eD450D4F81D402f7C4F71dd9 | Light | 2019-11 | Gnosis | 1000 DAI | N/A | diff --git a/MIP10/MIP10c18-Subproposal-Template.md b/MIP10/MIP10c18-Subproposal-Template.md new file mode 100644 index 000000000..e4785df02 --- /dev/null +++ b/MIP10/MIP10c18-Subproposal-Template.md @@ -0,0 +1,38 @@ +# MIP10c18: Subproposal to Update Feed Stipend + +## Preamble +``` +MIP10c18-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- What is the problem with the current Feed Stipend? +- Why is a new Feed Stipend needed? + +### Feed Stipend Model +- How does the proposed model work? + - Is the Feed Stipend static or dynamic? + - Is it a flat amount for all Feeds? + - Do Dark Feeds and Light Feeds get paid different amounts? + - Is the amount based on seniority? + - Should the amount be raised to increase security? + - Should the amount be lowered to reduce costs? + - Is the Feed Stipend higher for Feeds exhibiting higher than average uptime and lower for Feeds exhibiting lower than average uptime? + - Is the Feed Stipend proportional to the Dai supply? + - Is the Feed Stipend proportional to the value of locked collateral? + - Is the Feed Stipend inversely proportional to the number of Feeds? + - Is the Feed Stipend proportional to the amount of stability fees? + +### Supporting Data +- Empirical data supporting your Feed Stipend Model + +### Changelog +- List of updates \ No newline at end of file diff --git a/MIP10/MIP10c18-Subproposals/placeholder.md b/MIP10/MIP10c18-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c18-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c19-Subproposals/placeholder.md b/MIP10/MIP10c19-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c19-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c2-Subproposal-Template.md b/MIP10/MIP10c2-Subproposal-Template.md new file mode 100644 index 000000000..565d68571 --- /dev/null +++ b/MIP10/MIP10c2-Subproposal-Template.md @@ -0,0 +1,33 @@ +# MIP10c2: Subproposal for Oracle Onboarding Request + +## Preamble +``` +MIP10c2-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- What data should this Oracle provide? +- What will this Oracle be used for? +- General comments by proposer + +### Customer(s) +- < customer name > < point of contact email > + +### Whitelist +- < customer name > - < address(es) to whitelist > - < Medianizer/OSM s> + +### Requirements +For each address to be whitelisted: + - Is contract source code verified on etherscan? + - Is Oracle data used in a permissioned manner that would prevent parasitic behavior? + - Is Oracle data written to storage? + - If Oracle data is stored, is it stored in a private variable? + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? \ No newline at end of file diff --git a/MIP10/MIP10c2-Subproposals/placeholder.md b/MIP10/MIP10c2-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c2-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c20-Subproposals/placeholder.md b/MIP10/MIP10c20-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c20-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c21-Subproposals/placeholder.md b/MIP10/MIP10c21-Subproposals/placeholder.md new file mode 100644 index 000000000..48cdce852 --- /dev/null +++ b/MIP10/MIP10c21-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder diff --git a/MIP10/MIP10c3-Subproposal-Template.md b/MIP10/MIP10c3-Subproposal-Template.md new file mode 100644 index 000000000..0f3affba9 --- /dev/null +++ b/MIP10/MIP10c3-Subproposal-Template.md @@ -0,0 +1,61 @@ +# MIP10c3: Subproposal to Onboard Oracle + +## Preamble +``` +MIP10c3-SP#: +Author(s): +Contributors: +Type: Process Component +Oracle Team Name: +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- What data would this Oracle provide? +- What would this Oracle be used for? +- General comments by Oracle Team + +### Oracle Data Model + +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :-------------- | :------------ | :----: | :---------: | :----------: | +| < data source > | < param > | < # > | < model > | < model > | + + +### Oracle Supporting Data Model(s) + + | Source | Asset Pair | Feed Model | + | :-------------- | :------------ | :----------: | + | < data source > | < param > | < model > | + + +### Oracle Address +- Medianizer +- Oracle Security Module (OSM) + +### Customer(s) +- < customer name > < point of contact email > + +### Whitelist +- < customer name > - < address(es) to whitelist > - < Medianizer/OSM > + +### Requirements +For each customer address to be whitelisted: + - Is the contract source code verified on etherscan? + - Isther Oracle data used in a permissioned manner that would prevent parasitic behavior? + - Is Oracle data written to storage? + - If Oracle data is stored, is it stored in a private variable? + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? + +### Fee +- < customer name > - < amount in Dai > + +### Supported Tools +- < tool name > < version commit hash > < link to github repo > + +### Changelog +- List of updates \ No newline at end of file diff --git a/MIP10/MIP10c3-Subproposals/placeholder.md b/MIP10/MIP10c3-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c3-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c4-Subproposal-Template.md b/MIP10/MIP10c4-Subproposal-Template.md new file mode 100644 index 000000000..61e7be12f --- /dev/null +++ b/MIP10/MIP10c4-Subproposal-Template.md @@ -0,0 +1,37 @@ +# MIP10c4: Subproposal for Oracle Offboarding + +## Preamble +``` +MIP10c4-SP#: +Author(s): +Contributors: +Type: Process Component +Oracle Team Name: +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Oracle Name +- What is the name of this Oracle in MIP10c5? + +### Oracle Type +- What type of data does this Oracle provide? + +### Customers +- Which customers (if any) use this Oracle? + +### Oracle Address +- Medianizer +- Oracle Security Module (OSM) + +### Removal Motivation +- An explanation behind the motivation for the removal of the Oracle. Possible reasons include: + - An asset ceasing to exist + - Removal of a collateral type from the Maker Protocol + - Oracle not being utilized by neither the Maker Protocol nor a 3rd party + +### Relevant Information +- Links to evidence further backing the motivation behind the removal of the Oracle. \ No newline at end of file diff --git a/MIP10/MIP10c4-Subproposals/placeholder.md b/MIP10/MIP10c4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c5-List-of-Active-Oracles.md b/MIP10/MIP10c5-List-of-Active-Oracles.md new file mode 100644 index 000000000..3eb49b2c0 --- /dev/null +++ b/MIP10/MIP10c5-List-of-Active-Oracles.md @@ -0,0 +1,32 @@ +# MIP10c5: List of Active Oracles + +## Glossary + +- **Oracle Name:** The name of the Oracle that is indicative of the data is broadcasts +- **Type:** The type of data that this Oracle broadcasts +- **Collateral(?):** Is the Asset Pair a collateral type in the Maker Protocol +- **Feeds** The number of Feeds submitting prices to the Oracle +- **Quorum:** The number of Feeds needed to reach consensus on a price +- **Data Model:** The model that defines where data is sourced and how it is processed +- **Oracle Spread:** The maximum difference in price before an Oracle price is updated +- **Oracle Expiration:** The maximum time interval before an Oracle price is updated +- **Medianizer:** The address of the Medianizer smart contract +- **OSM:** The address of the Oracle Security Module smart contract +- **OSM Delay** The amount of time before an Oracle price is utilized by the Maker Protocol + + +## Template Spec + +| Oracle Name | Type | Is Collateral? | Feeds | Quorum | Data Model | Oracle Spread (%) | Oracle Expiration (s) | Medianizer | OSM | OSM Delay (s) | +| :------------- | :------------ | :------------- |:----- | :----- |:----------- | :---------------- | :-------------------- | :----------- | :---------- | :------------ | +| < name > | < data > | < bool > | < # > | < # > | < model > | < # > | < # > | < address > | < address > | < # > | + +## Active Oracle List + +| Oracle | Type | Is Collateral? | Feeds | Quorum | Data Model | Oracle Spread (%) | Oracle Expiration (s) | Medianizer | OSM | OSM Delay (s) | +| :------------- | :------------ | :------------- |:----- | :----- |:----------- | :---------------- | :-------------------- | :----------- | :---------- | :------------ | +| BAT/USD | Price | Yes | 20 | 13 | BAT/USD | 1 | 15500 | 0x18B4633D6E39870f398597f3c1bA8c4A41294966 | 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 | 3600 | +| BTC/USD | Price | No | 20 | 13 | BTC/USD | 0.5 | 15500 | 0xe0F30cb149fAADC7247E953746Be9BbBB6B5751f | | N/A | +| ETH/BTC | Price | No | 20 | 13 | ETH/BTC | 0.5 | 15500 | 0x81A679f98b63B3dDf2F17CB5619f4d6775b3c5ED | | N/A | +| ETH/USD | Price | Yes | 20 | 13 | ETH/USD | 0.5 | 15500 | 0x64DE91F5A373Cd4c28de3600cB34C7C6cE410C85 | 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 | 3600 | +| USDC/USD | Price | Yes | N/A | N/A | USDC/USD | N/A | N/A | 0x77b68899b99b686F415d074278a9a16b336085A0 | | N/A | \ No newline at end of file diff --git a/MIP10/MIP10c6-Subproposal-Template.md b/MIP10/MIP10c6-Subproposal-Template.md new file mode 100644 index 000000000..b9d30a46e --- /dev/null +++ b/MIP10/MIP10c6-Subproposal-Template.md @@ -0,0 +1,39 @@ +# MIP10c6: Subproposal for Update Oracle Data Model Request + +## Preamble +``` +MIP10c6-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction + +### Oracle Data Model + +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :-------------- | :------------ | :----: | :---------: | :----------: | +| < data source > | < param > | < # > | < model > | < model > | + + +### Oracle Supporting Data Model(s) + + | Source | Asset Pair | Feed Model | + | :-------------- | :------------ | :----------: | + | < data source > | < param > | < model > | + +### Supporting Evidence +- What is wrong with the current Data Model? +- What is better about the new Data Model? +- If possible provide empirical evidence showing the superiority of the new data model. + - data + - graphs + +### Changelog +- List of updates \ No newline at end of file diff --git a/MIP10/MIP10c6-Subproposals/placeholder.md b/MIP10/MIP10c6-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c6-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c7-Subproposal-Template.md b/MIP10/MIP10c7-Subproposal-Template.md new file mode 100644 index 000000000..7ecfede02 --- /dev/null +++ b/MIP10/MIP10c7-Subproposal-Template.md @@ -0,0 +1,47 @@ +# MIP10c7: Subproposal to Update Oracle Data Model + +## Preamble +``` +MIP10c7-SP#: +Author(s): +Contributors: +Type: Process Component +Oracle Team Name: +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction + +### Oracle Data Model + +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :-------------- | :------------ | :----: | :---------: | :----------: | +| < data source > | < param > | < # > | < model > | < model > | + + +### Oracle Supporting Data Model(s) + + | Source | Asset Pair | Feed Model | + | :-------------- | :------------ | :----------: | + | < data source > | < param > | < model > | + +### Supporting Evidence +- What is wrong with the current Data Model? +- What is better about the new Data Model? +- If possible provide empirical evidence showing the superiority of the new data model. + - data + - graphs + +### Oracle Address +- Medianizer +- Oracle Security Module (OSM) + +### Supported Tools +- < tool name > < version commit hash > < link to github repo > + +### Changelog +- List of updates \ No newline at end of file diff --git a/MIP10/MIP10c7-Subproposals/placeholder.md b/MIP10/MIP10c7-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c7-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/MIP10c8-List-of-Oracle-Data-Models.md b/MIP10/MIP10c8-List-of-Oracle-Data-Models.md new file mode 100644 index 000000000..e6b686ae3 --- /dev/null +++ b/MIP10/MIP10c8-List-of-Oracle-Data-Models.md @@ -0,0 +1,73 @@ +# MIP10c8: Subproposal for List of Oracle Data Models + +## Glossary + +- **Source:** The data source for the Oracle Feed +- **Asset Pair:** The asset pair is a price quote of the exchange rate for two different assets traded on the market. +- **Quorum:** The number of Feeds you need to reach a consensus on a price. +- **Feed Model:** Model for how a Feed processes all sourced data into a singular price +- **Oracle Model:** Model for how an Oracle processes all Feed data into a singular price + +## Template Spec + +**Data Model Name:** < name > +**Data Model Origin:** < link to MIP10c1/MIP10c7 governance vote> +**Data Model Discussion:** < link to MIP10c1/MIP10c7 forum discussion > +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :-------------- | :------------ | :-----: | :---------: | :----------: | +| < data source > | < param > | < # > | < model > | < model > | + + +## Oracle Data Model List + +**Data Model Name:** BAT/USD Data Model +**Data Model Origin:** N/A +**Data Model Discussion** N/A +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :----: | :---------: | :----------: | +| Binance | BAT/BTC | 13 | Median | Median | +| Bittrex | BAT/BTC | +| Coinbase | BAT/USDC | +| Upbit | BAT/KRW | + +**Data Model Name:** BTC/USD Data Model +**Data Model Origin:** [Governance Portal](https://vote.makerdao.com/polling-proposal/qmealoapl7e1yzabsobg9wckj3bs8hb8pgquc5jx7r8qpo) +**Data Model Discussion:** [Maker Forum](https://forum.makerdao.com/t/proposal-btcusd-oracle-set-protocol-dydx/2011/14) +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :----: | :---------: | :----------: | +| Bitstamp | BTC/USD | 13 | Median | Median | +| Bittrex | BTC/USD | +| Coinbase | BTC/USD | +| Gemini | BTC/USD | +| Kraken | BTC/USD | + +**Data Model Name:** ETH/BTC Data Model +**Data Model Origin:** [Governance Portal](https://vote.makerdao.com/polling-proposal/qmeymkw5rhenzsevpvnhequj9glvq6n5buzapyrvestcdg) +**Data Model Discussion:** [Maker Forum](https://forum.makerdao.com/t/proposal-ethbtc-oracle-tbtc/2010/10) +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :----: | :---------: | :----------: | +| Binance | ETH/BTC | 13 | Median | Median | +| BitFinex | ETH/BTC | +| Coinbase | ETH/BTC | +| Huobi | ETH/BTC | +| Kraken | ETH/BTC | +| Poloniex | ETH/BTC | + +**Data Model Name:** ETH/USD Data Model +**Data Model Origin:** N/A +**Data Model Discussion:** N/A +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :----: | :---------: | :----------: | +| Binance | ETH/BTC | 13 | Median | Median | +| Bitstamp | ETH/USD | +| Coinbase | ETH/USD | +| Gemini | ETH/USD | +| Kraken | ETH/USD | + + +**Data Model Name:** USDC/USD Data Model +**Data Model Origin:** [Maker Governance](https://vote.makerdao.com/executive-proposal/proposal-for-collateral-onboarding-of-usdc) +**Data Model Discussion:** [Maker Forum](https://forum.makerdao.com/t/proposal-for-collateral-onboarding-of-usdc/1588) +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :-----------: | :----: | :---------: | :----------: | +| 1 | N/A | N/A | N/A | N/A | diff --git a/MIP10/MIP10c9-Subproposal-Template.md b/MIP10/MIP10c9-Subproposal-Template.md new file mode 100644 index 000000000..fd92edc96 --- /dev/null +++ b/MIP10/MIP10c9-Subproposal-Template.md @@ -0,0 +1,37 @@ +# MIP10c9: Subproposal to Whitelist Oracle Access + +## Preamble +``` +MIP10c9-SP#: +Author(s): +Contributors: +Type: Process Component +Status: +Date Proposed: +Date Ratified: +``` + +## Specification + +### Introduction +- What would this Oracle be used for? + +### Oracle Name +- What is the name of this Oracle in MIP10c5? + +### Customer(s) +- < customer name > < point of contact email > + +### Whitelist + - < customer name > - < address(es) to whitelist > - < Medianizer/OSM > + +### Requirements +For each customer address to be whitelisted: + - Is the contract source code verified on etherscan? + - Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? + - Is Oracle data written to storage? + - If Oracle data is stored, is it stored in a private variable? + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? + +### Fee +- < customer name > - < amount in Dai > diff --git a/MIP10/MIP10c9-Subproposals/placeholder.md b/MIP10/MIP10c9-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP10/mip10.md b/MIP10/mip10.md index 51ef94e1a..75ddd0f99 100644 --- a/MIP10/mip10.md +++ b/MIP10/mip10.md @@ -1,43 +1,133 @@ # MIP10: Oracle Management - ## Preamble - - MIP#: 10 - Title: Oracle Management - Author(s): Niklas Kunkel (@NiklasKunkel), Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) - Type: Process - Status: Request for Comments (RFC) - Date Proposed: 2020-04-06 - Date Ratified: - Dependencies: n/a - Replaces: n/a - +``` +MIP#: 10 +Title: Oracle Management +Author(s): Niklas Kunkel (@NiklasKunkel), Charles St.Louis (CPSTL), Rune Christensen (@Rune23) +Type: Process +Status: Accepted +Date Proposed: 2020-04-06 +Date Ratified: 2020-05-02 +Dependencies: n/a +Replaces: n/a +``` ## References -No referenced materials. +**[MIP10c2-Subproposal-Template.md](MIP10c2-Subproposal-Template.md)** +**[MIP10c3-Subproposal-Template.md](MIP10c3-Subproposal-Template.md)** +**[MIP10c4-Subproposal-Template.md](MIP10c4-Subproposal-Template.md)** +**[MIP10c5-List-of-Active-Oracles.md](MIP10c5-List-of-Active-Oracles.md)** +**[MIP10c6-Subproposal-Template.md](MIP10c6-Subproposal-Template.md)** +**[MIP10c7-Subproposal-Template.md](MIP10c7-Subproposal-Template.md)** +**[MIP10c8-List-of-Oracle-Data-Models.md](MIP10c8-List-of-Oracle-Data-Models.md)** +**[MIP10c9-Subproposal-Template.md](MIP10c9-Subproposal-Template.md)** +**[MIP10c10-Subproposal-Template.md](MIP10c10-Subproposal-Template.md)** +**[MIP10c11-List-of-Oracle-Whitelists.md](MIP10c11-List-of-Oracle-Whitelists.md)** +**[MIP10c12-Subproposal-Template.md](MIP10c12-Subproposal-Template.md)** +**[MIP10c13-Subproposal-Template.md](MIP10c13-Subproposal-Template.md)** +**[MIP10c14-Subproposal-Template.md](MIP10c14-Subproposal-Template.md)** +**[MIP10c15-Subproposal-Template.md](MIP10c15-Subproposal-Template.md)** +**[MIP10c16-Subproposal-Template.md](MIP10c16-Subproposal-Template.md)** +**[MIP10c17-List-of-Feeds.md](MIP10c17-List-of-Feeds.md)** +**[MIP10c18-Subproposal-Template.md](MIP10c18-Subproposal-Template.md)** +**[MIP10c19-Subproposal-Template.md](MIP10c19-Subproposal-Template.md)** +**[MIP10c20-Subproposal-Template.md](MIP10c20-Subproposal-Template.md)** +**[MIP10c21-Subproposal-Template.md](MIP10c21-Subproposal-Template.md)** ## Sentence Summary -MIP10 defines how oracles are onboarded, offboarded and managed in order to support the collateral onboarding process. +MIP10 defines how oracles are onboarded, offboarded and managed in order to support the Maker Protocol. ## Paragraph Summary -This proposal defines the process for onboarding, offboarding and managing oracles. +This proposal defines the processes for onboarding, offboarding and managing Oracles. This encompasses a diverse array of components. Beginning with selecting Data Models for assets which are used for computing aggregated data into a canonical price. Continuing onward, processes are defined for adding and removing Feeds, agents who run Data Models and publish the resulting prices. Furthermore, it describes the governance procedures for creating new Oracles for new asset classes, whether they be collateral in the Maker Protocol or request by 3rd parties. Governance controls access to read prices from the Oracles through a whitelist, enabling MKR token holders to earn revenue through regulating whitelist access. It is the responsibility of governance to administer a host of risk parameters including the Oracle Seucrity Module Delay, Oracle Expiration Time, and Oracle Spread to ensure the proper operation of the Oracle infrastructure. ## Component Summary -**MIP10c1: Oracle Onboarding** +### Oracles + +**Description** +The Maker Protocol utilizes the Oracles to obtain a real-time stream of the price of the collateral assets. This price is utilized to ensure positions are sufficiently capitalized and liquidate positions below the collateralization ratio. It also limits the maximum amount of Dai a user can generate against their collateral. Given the widespread effects the Oracles have on the Maker Protocol, it is imperative that the Data Models used in their implementations are refined to mitigate risk and optimize performance. These Data Models define where data is sourced from and how it is filtered into a canonical price. + +**MIP10c1: Oracle Onboarding (OT)** 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. +**MIP10c2: Process for Oracle Onboarding Request** +A process component that defines the method and template to request a new Oracle. + +**MIP10c3: Process to Onboard Oracle (OT)** +A process component that defines the method and template for the Oracle Team to onboard a new Oracle. + +**MIP10c4: Process to Offboard Oracle** +A process component that defines the method and template to offboard an Oracle in the case it has become obsolete or otherwise undesireable. + +**MIP10c5: List of Active Oracles** +A list component that is kept-up-to-date with the currently active Oracles and their properties. + +**MIP10c6: Process for Data Model Update Request** +A process component that defines the method and template to request to update a Data Model. + +**MIP10c7: Process to Update Oracle Data Model (OT)** +A process component that defines the method and template for the Oracle Team to update the Data Model of an asset pair. + +**MIP10c8: List of Oracle Data Models** +A list component that is kept up-to-date with the ratified Oracle Data Models. + +### Whitelist + +**Description** +The ability to read data from the Oracles is regulated by a whitelist. This enables awareness of who is using the Oracle, and how, which helps mitigate fallout from migrations. Additionally it empowers governance to monetize the Oracle infrastructure as a service, the proceeds of which are funneled to MKR holders to help offset the cost of maintaining the Oracle infrastructure. + +**MIP10c9: Process to Whitelist Oracle Access** +A process component that defines the method and template to whitelist access for a specific Oracle. + +**MIP10c10: Process to Remove Oracle Access** +A process component that defines the method and template to remove whitelist access for a specific Oracle. + +**MIP10c11: List of Oracle Whitelists** +A list component that is kept up-to-date with the whitelist for each Oracle. + +**MIP10c12: Process to Update Oracle Access Fee** +A process component that defines the method and template to update the Oracle Access Fee. + +### Feeds: + +**Description** +Feeds are bots run by individuals and organizations that submit data to the Oracles. There are two types of Feeds; Dark Feeds run by anonymous individuals, and Light Feeds run by public organizations. This hybrid model preserves the hardness properties of Dark Feeds but benefits from the reputation of Light Feeds who are stakeholders in the ecosystem and are effectively staking their reputation. Feeds are paid a monthly Feed Stipend for the service they provide that is determined by governance. + +**MIP10c13: Process to Appoint Dark Feed** +A process component that defines the method and template to appoint a Dark Feed. + +**MIP10c14: Process to Appoint Light Feed** +A process component that defines the method and template to appoint a Light Feed. + +**MIP10c15: Process to Appoint Feed (OT)** +A process component that defines the method and template for the Oracle Team to appoint a Feed. + +**MIP10c16: Process to Remove Feed** +A process component that defines the method and template to remove a Feed. + +**MIP10c17: List of Feeds** +A list component that is kept up-to-date with the current Feeds. + +**MIP10c18: Process to Update Feed Stipend** +A process component that defines the method and template to update the Feed Stipend. + + +### Oracle Parameters: -**MIP10c3: Process for onboarding** -A process component that defines the method and template to be used to onboard new oracles for collateral assets. +**Description** +The Oracle system has several parameters that determine how frequently the Oracles are updated. Updating more frequently leads to a more sensitive Oracle, at the expense of higher costs. The Oracle Security Module (OSM) is the watchdog between the Oracle and the Maker Protocol. It delays prices by a delay interval before the price is utilizied by the Maker Protocol. This delay protects the Maker Protocol from Oracle attacks by enabling Governance to take emergency action during the delay period. -**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. +**MIP10c19: Process to Update Oracle Expiration Time** +A process component that defines the method and template to update the Oracle Expiration Time. + +**MIP10c20: Process to Update Oracle Spread** +A process component that defines the method and template to update the Oracle Spread. + +**MIP10c21: Process to Update Oracle Security Module Delay** +A process component that defines the method and template to update the Oracle Security Module Delay. ## Motivation @@ -45,133 +135,427 @@ In the Maker Protocol, every collateral type has a corresponding Oracle that pub ## Specification / Proposal Details -### MIP10c1: Oracle Onboarding +### MIP10c1: Oracle Onboarding (OT) **The Oracle Onboarding process is as follows:** +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days + +1. An Oracle Team publishes the [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) to the Oracle section of the Maker Forum for community review as well as submitting a PR to the MIPs Github repo. +2. Feedback is incorporated into the [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) with changes logged in the changelog section. Changes are reflected both in the Forum thread as well as in the Github PR. +3. The Oracle Team submits a Polling Vote to the Governance Portal. If the Oracle is being onboarded as part of the collateral onboarding process, this proposal may be bundled up with other deliverables necessary for collateral onboarding. +4. If the Polling Vote passes, the Oracle Team will alert the Feeds to update their Oracle clients. If the Polling Vote fails the Oracle Team may make changes to the [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) and resubmit a new Polling Vote. If the Oracle Team does not, and no other Oracle Team decides to take up this responsibility, the process ends here. +5. Oracle Team Notifies the Feeds to update their Oracle clients + - Alert sent out on the official Feeds Keybase channels + - Timeline: 1 week to deploy and 1 week to confirm stability + - Feeds who do not deploy within the given timeline are given a warning. Given enough warnings, governance may opt to remove the Feed through MIP10c15. +6. If on-chain changes are necessary, the actions are bundled up in the subsequent Executive Vote. + +7. The Oracle Team(s) update [MIP10c5: List of Active Oracles](MIP10c5-List-of-Active-Oracles.md) to append the new Oracle and submit a PR to the MIPS Github repo. +8. The Oracle Team(s) update [MIP10c8: List of Oracle Data Models](MIP10c8-List-of-Oracle-Data-Models.md) to append the new Data Model and submit a PR to the MIPS Github repo. +9. The Oracle Team(s) update [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to append all whitelist entries and submit a PR to the MIPS Github repo. + +--- + +### MIP10c2: Process for Oracle Onboarding Request + +Used by the community to signal demand for onboarding new Oracles for non-collateral assets. + +MIP10c2 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days + +MIP10c2 subproposals must use the template located at **[MIP10c2-Subproposal-Template.md](MIP10c2-Subproposal-Template.md)**. + +**An Oracle Team may opt to skip this step and submit MIP10c3** -1. Oracle Team(s) find and select data sources +1. A community member or other 3rd party publishes the [MIP10c2-Subproposal-Template.md](MIP10c2-Subproposal-Template.md) in the Oracle section of the Maker Forum. Typically this will be a 3rd party with a desire to consume the requested Oracle's data. + +2. At this point the proposal is in limbo until an Oracle Team commits to doing the work required to submit [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) and continue the Oracle Onboarding process. + +--- + +### MIP10c3: Process to Onboard Oracle (OT) + +Used by the Oracle Team(s) to onboard new Oracles for collateral assets or assets requested by 3rd parties. + +MIP10c3 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c3 subproposals must use the template located at **[MIP10c3-Subproposal-Template.md](MIP10c3-Subproposal-Template.md)**. + +1. The Oracle Team verifies for each customer whitelisted contract: + - contract is verified on etherscan + - contract uses Oracle data in a permissioned manner so as to prohibit on-chain parasitic behavior by 3rd parties. + - If Oracle data is saved to storage, it is stored in a private variable accessible exclusively by the protocol. +2. The Oracle Team finds and selects data sources - Exchange options - - Pair selection -2. The Oracle Team(s) select an appropriate Data Model (a model detailing how the data is processed to get the desired output) based on the specific asset type and what data is available. -3. The Oracle Team(s) complete the following technical deliverables: + - Pair options +3. The Oracle Team selects an appropriate Data Model (a model detailing how the data is processed to get the desired output) based on the specific asset type and what data is available. +4. The Oracle Team completes the following technical deliverables: - Update price querying tool(s) to pull from the selected data sources and implement the Data Model for that specific asset - - Update the Oracle client(s) to integrate the latest version of the price querying tool(s) and incorporate technical changes -4. Deploy new instances of previously audited smart contracts for the asset type. This includes two smart contracts: + - Update the Oracle client(s) to integrate the latest version of the price querying tool(s) and incorporate technical changes to publish the data. + - Update Relayers with contract address(es) +5. The Oracle Team deploys and configures new instances of previously audited smart contracts for the asset type. This includes two smart contracts: - Medianizer - - Oracle Security Module (OSM) -5. Notify the Feeds to update their Oracle clients - - Alert sent out on the official Keybase channel - - Timeline: 1 to 2 weeks to monitor deployment and confirm stability -6. The Oracle Team publishes the Medianizer and OSM smart contract addresses in the onboarding proposal (MIP10c3) itself. + - Oracle Security Module (OSM) - only required for collateral assets +6. The Oracle Team publishes the [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) to the Oracle section of the Maker Forum for community review as well as submitting a PR to the MIPs Github repo. + --- -### MIP10c2: List of Active Oracle Data Models +### MIP10c4: Process to Offboard Oracle -**Oracle Data Model Template Explanation:** -- **Source:** The data source for the Oracle Feed -- **Asset Pair:** The asset pair is a price quote of the exchange rate for two different assets traded on the market. -- **Quorum:** The number of Feeds you need to reach a consensus on a price. -- **Feed Model:** Model for how a Feed processes all sourced data into a singular price -- **Oracle Model:** Model for how an Oracle processes all Feed data into a singular price -- **Example Template**: +Allow anyone to remove an Oracle using a MIP10c4 subproposal. -| Source | Asset Pair | Quorum | Feed Model | Oracle Model | -| :------------ | :------------ | :----: | :---------: | :----------: | -| < data source > | < param > | < # > | < mode > | < model > | +MIP10c4 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days -**Active Oracle Data Models:** +MIP10c4 subproposals must use the template located at **[MIP10c4-Subproposal-Template.md](MIP10c4-Subproposal-Template.md)**. -**ETH/USD Data Model** +1. A community member or other 3rd party publishes the [MIP10c4-Subproposal-Template.md](MIP10c4-Subproposal-Template.md) in the Oracle section of the Maker Forum for community review as well as submitting a PR to the MIPs Github repo. +2. After a period for the community to review and give feedback on the proposal, an Oracle Team may choose to commit to the work required to continue the Oracle Offboarding process. +3. The Oracle Team submits a Polling Vote to the Governance Portal. +4. If the Polling Vote passes, the Oracle Team gives 30 day notice to any customers whitelisted on the Oracle that the Oracle is shutting down. + - Notice is sent to each customer via the email provided in MIP10c9. +5. The Oracle Team completes the following technical deliverables: + - Update price querying tool(s) to cease collecting data for the Oracle. + - Update the Oracle client(s) to integrate the latest version of the price querying tool(s) and cease publishing data for the Oracle. +6. After the 30-day period has elapsed, the Oracle Team Notifies the Feeds to update their Oracle clients + - Alert sent out on the official Feeds Keybase channels + - Timeline: 1 week to deploy + - Feeds who do not deploy within the given timeline are given a warning. Given enough warnings, governance may opt to remove the Feed through MIP10c16. +7. If on-chain changes are necessary, the actions are bundled up in the subsequent Executive Vote. +8. The Oracle Team updates [MIP10c5: List of Active Oracles](MIP10c5-List-of-Active-Oracles.md) to remove the Oracle and submits a PR to the MIPS Github repo. +9. The Oracle Team updates [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to remove all whitelist entries and submits a PR to the MIPS Github repo. - | Source | Asset Pair |Quorum | Feed Model | Oracle Model | - | :------------ | :------------ | :---: | :---------: | :----------: | - | Binance | ETH/BTC | 13 | Median | Median | - | BitFinex | ETH/USDT | - | Bitstamp | ETH/USD | - | Coinbase | ETH/USD | - | Gemini | ETH/USD | - | Kraken | ETH/USD | +--- -**BAT/USD Data Model** +### MIP10c5: List of Active Oracles +A canonical record of the Oracles in active operation by the Maker Protocol. - | Source | Asset Pair | Quorum | Feed Model | Oracle Model | - | :------------ | :------------ | :----: | :---------: | :----------: | - | Binance | BAT/BTC | 13 | Median | Median | - | Bittrex | BAT/BTC | - | Coinbase | BAT/USDC | - | Upbit | BAT/KRW | +The active list is located at **[MIP10c5-List-of-Active-Oracles.md](MIP10c5-List-of-Active-Oracles.md)**. -**USDC/USD Data Model** +MIP10c5 must be updated when an Oracle is onboarded or offboarded by governance via MIP10c3 and MIP10c4. +It is the responsibility of the Oracle Team(s) to ensure MIP10c5 is kept up to date. - | Source | Asset Pair | Quorum | Feed Model | Oracle Model | - | :------------ | :-----------: | :----: | :---------: | :----------: | - | 1 | N/A | N/A | N/A | N/A | +--- + +### MIP10c6: Process for Data Model Update Request + +Used by the community to request to update an Oracle Data Model. + +MIP10c6 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days + +MIP10c6 subproposals must use the template located at **[MIP10c6-Subproposal-Template.md](MIP10c6-Subproposal-Template.md)**. + +**An Oracle Team may opt to skip this step and submit MIP10c7** + +1. A community member publishes the [MIP10c4-Subproposal-Template.md](MIP10c4-Subproposal-Template.md) in the Oracle section of the Maker Forum for community review as well as submitting a PR to the MIPs Github repo. +2. Feedback is incorporated into the [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) with changes logged in the changelog section. Changes are reflected both in the Forum thread as well as in the Github PR. +3. At this point the proposal is in limbo until an Oracle Team commits to doing the work required to submit [MIP10c7-Subproposal-Template](MIP10c7-Subproposal-Template.md) and continue the Oracle Data Model Update process. --- -### MIP10c3: Process for Onboarding +### MIP10c7: Process to Update Oracle Data Model (OT) -This process MIP component is used by the Oracle Team(s) to onboard new oracles for collateral assets as well as compel the Feeds to update their Data Models in preparation for deploying a new Oracle. +Used by the Oracle Team(s) to update an Oracle Data Model. +MIP10c7 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days + +MIP10c7 subproposals must use the template located at **[MIP10c7-Subproposal-Template.md](MIP10c7-Subproposal-Template.md)**. + +1. The Oracle Team completes the following technical deliverables: + - Update price querying tool(s) to implement the Data Model for the Oracle. + - Update the Oracle client(s) to integrate the latest version of the price querying tool(s) and implement technical changes to utilize the new Data Model. +2. The Oracle Team publishes the [MIP10c7-Subproposal-Template.md](MIP10c7-Subproposal-Template.md) in the Oracle section of the Maker Forum for community review as well as submitting a PR to the MIPs Github repo. +3. Feedback is incorporated into the [MIP10c7-Subproposal-Template](MIP10c7-Subproposal-Template.md) with changes logged in the changelog section. Changes are reflected both in the Forum thread as well as in the MIPS Github repo. +4. The Oracle Team submits a Polling Vote to the Governance Portal. +5. If the Polling Vote passes, the Oracle Team gives 30 day notice to any customers whitelisted on the Oracle that the Oracle Data Model is changing. + - Notice is sent to each customer via the email provided in MIP10c9. +6. After the 30-day period has elapsed, the Oracle Team notifies the Feeds to update their Oracle clients + - Alert sent out on the official Feeds Keybase channels + - Timeline: 1 week to deploy + - Feeds who do not deploy within the given timeline are given a warning. Given enough warnings, governance may opt to remove the Feed through MIP10c16. +7. The Oracle Team updates [MIP10c8: List of Oracle Data Models](MIP10c8-List-of-Oracle-Data-Models.md) to update the Data Model and submits a PR to the MIPS Github repo. +8. The Oracle Team updates [MIP10c5: List of Active Oracles](MIP10c5-List-of-Active-Oracles.md) to update the Active Oracle record with the updated Data Model and submits a PR to the MIPS Github repo. + +--- + +### MIP10c8: List of Oracle Data Models + + +A canonical record of the ratified Data Models actively being used by the Oracles. + +The ratified list of Oracle Data Models is located at [MIP10c8-List-of-Oracle-Data-Models.md](MIP10c8-List-of-Oracle-Data-Models.md). + +MIP10c8 must be updated when a new Data Model is ratified as part of Oracle onboarding via MIP10c1 as well as when an Oracle Data Model is updated via MIP10c7. + +It is the responsibility of the Oracle Team(s) to ensure MIP10c8 is kept up to date. + +--- + +### MIP10c9: Process to Whitelist Oracle Access + +Used by the community to request whitelist access to an Oracle. + +MIP10c9 subproposals have the following parameters: - **Feedback Period:** 0 days - **Frozen period:** 0 days -- **Update Interval:** Feeds have a period of 2 weeks during which to upgrade their systems to include the Oracle type and data models. Any Feeds not upgraded during this interval are presumed to be in breach of their responsibilities and potentially subject to removal. -**Subproposal Template:** +MIP10c9 subproposals must use the template located at **[MIP10c9-Subproposal-Template.md](MIP10c9-Subproposal-Template.md)**. + +1. A community member publishes the [MIP10c9-Subproposal-Template](MIP10c9-Subproposal-Template.md) in the Oracle section of the Maker Forum and submits a PR to the MIPs Github repo. Typically this will be the 3rd party with a desire to consume the requested Oracle's data. An Oracle Team may also submit such a proposal on behalf of the interested party. + +2. At this point the proposal is in limbo until an Oracle Teams commits to doing the work required to submit [MIP10c3-Subproposal-Template](MIP10c3-Subproposal-Template.md) and continue the Whitelist Oracle Access process. + +3. The Oracle Team verifies for each proposed contract to whitelist: + - contract is verified on etherscan + - contract uses Oracle data in a permissioned manner so as to prohibit on-chain parasitic behavior by 3rd parties. + - If Oracle data is saved to storage, it is stored in a private variable accessible exclusively by the protocol. + +4. The Oracle Team submit a Polling Vote to the Governance Portal. + +5. If the Polling Vote passes the Oracle Team will bundle the proposal in the subsequent Executive Vote. + +6. The Oracle Team updates [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to update the Whitelist for the Oracle(s) and submit a PR to the MIPS Github repo. - Introduction - - - Oracle Team Name: - - Oracle Data model Name: - - Oracle Data Model: - - | Source | Asset Pair | Quorum | Feed Model | Oracle Model | - | :------------ | :------------ | :----: | :---------: | :----------: | - | | | <#> | | - - - Supported Tools: - - - - - Specification - - - Communication Medium(s) - - Oracle Team Posting the MIP on the Maker Forum - - Oracle Team posting the MIP in the Keybase Feeds channel - - - Update Interval - - Feeds have a period of 2 weeks during which to upgrade their systems to include the Oracle type and data models. Any Feeds not upgraded during this interval are presumed to be in breach of their responsibilities and potentially subject to removal. - --- -### MIP10c4: Process for Offboarding +### MIP10c10: Process to Remove Oracle Access -If an Oracle has been made obsolete, anyone can make a proposal to remove it, in order to reduce unnecessary costs such as gas fees. +Used by a customer or Oracle Team to remove customer's access to Oracle data. + +MIP10c10 subproposals have the following parameters: - **Feedback Period:** 0 days -- **Frozen Period:** 0 days -- **Subproposal Template:** -``` +- **Frozen period:** 0 days -Introduction - - - Oracle Team Name: - - Oracle Type Name: - - Date of Proposed Removal: - -Specification - - - Removal Motivation: - - An explanation behind the motivation for the removal of the Oracle. Possible reasons include: - - An asset ceasing to exist - - Removal of a collateral type from the Maker Protocol - - Oracle not being utilized by neither the Maker Protocol nor a 3rd party - - Failure to upgrade their systems to include an Oracle type and data models. - - - Relevant Information: - - Links to evidence further backing the motivation behind the removal of the Oracle +MIP10c10 subproposals must use the template located at **[MIP10c10-Subproposal-Template.md](MIP10c10-Subproposal-Template.md)**. + +1. A customer, community member, or Oracle Team publishes the [MIP10c10-Subproposal-Template](MIP10c10-Subproposal-Template.md) in the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo. + +2. At this point the proposal is in limbo until an Oracle Teams commits to doing the work required and continue the Oracle Removal process. + +If voluntary: + 3. The Oracle Team contacts the customer via the email provided in MIP10c3/MIP10c9 to verify this action. + 4. The Oracle Team bundles the proposal into the next Executive Vote. + 5. The Oracle Team updates [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to update the Whitelist for the Oracle(s) and submits a PR to the MIPS Github repo. + +If involuntary: + 3. The Oracle Team gives the customer 30 days notice via the email the customer provided in MIP10c3/MIP10c9. + 4. After the 30 day period has elapsed, the Oracle Team bundles the proposal into the next Executive Vote. + 5. The Oracle Team updates [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to update the Whitelist for the Oracle(s) and submits a PR to the MIPS Github repo. + +--- + +### MIP10c11: List of Oracle Whitelists + +A canonical record of the whitelist for each Oracle. + +The whitelist for each oracle is located at [MIP10c11-List-of-Oracle-Whitelists.md](MIP10c11-List-of-Oracle-Whitelists.md) + +MIP10c11 must be updated when an entity is added or removed from the whitelist for an Oracle via MIP10c3/MIP10c9/MIP10c10. +It is the responsibility of the Oracle Team(s) to ensure MIP10c11 is kept up to date. -``` --- + +### MIP10c12: Process to Update Oracle Access Fee + +Used by the community to update the Oracle Access Fee for an Oracle. + +MIP10c13 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +The MIP10c12 template is located at **[MIP10c12-Subproposal-Template.md](MIP10c12-Subproposal-Template.md)**. + +1. A community member publishes the [MIP10c12-Subproposal-Template](MIP10c12-Subproposal-Template.md) in the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo. + +2. Feedback is incorporated into the [MIP10c12-Subproposal-Template](MIP10c12-Subproposal-Template.md) with changes logged in the changelog section. Changes are reflected both in the Forum thread as well as in the MIPS Github repo. + +3. An Oracle Team submits a Polling Vote to the Governance Portal. + +4. If the Polling Vote passes the Oracle Team gives affected customers 30 days notice via the email stored in [MIP10c12](MIP10c12-Subproposal-Template.md). + +5. The Oracle Team updates [MIP10c11: List of Oracle Whitelists](MIP10c11-List-of-Oracle-Whitelists.md) to update the fees for each modified entry and submit a PR to the MIPS Github repo. + +--- + +### MIP10c13: Process to Appoint Dark Feed Reqest + +Used by the community to appoint a Dark Feed. + +MIP10c13 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c13 subproposals must use the template located at **[MIP10c13-Subproposal-Template.md](MIP10c13-Subproposal-Template.md)**. + +1. An anon uses VPN/TOR/I2C to post [MIP10c13-Subproposal-Template](MIP10c13-Subproposal-Template.md) to the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo using a fresh Github Account registered with a throwaway email. + +2. At this point the proposal is in limbo until an Oracle Teams commits to doing the work required to validate the information provided. The Oracle Team may ask follow-up questions or request more data from the proposer. + +3. The Oracle Team prepares the assesment of the information provided by the proposed Light Feed to prepare MIP10c15. + +--- + +### MIP10c14: Process to Appoint Light Feed Request + +Used by the community to appoint a Light Feed. + +MIP10c14 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c14 subproposals must use the template located at **[MIP10c14-Subproposal-Template.md](MIP10c14-Subproposal-Template.md)**. + +1. An institution publishes [MIP10c14-Subproposal-Template](MIP10c14-Subproposal-Template.md) to the Oracle section of the Maker FOrum and submits a PR to the MIPS Github repo. + +2. At this point the proposal is in limbo until an Oracle Team commits to doing the work required to validate the information provided. The Oracle Team may ask follow-up questions or request more data from the proposer. + +3. The Oracle Team verifies the identity of the individual purporting to represent the institution using the domain bonded email provided in MIP10c14 as well their network of contacts in the industry. + +4. The Oracle Team prepares the assessment of the information provided by the proposed Light Feed to prepare MIP10c15. + +--- + +### MIP10c15: Process to Appoint Feed (OT) + +Used by an Oracle Team to validate submitted Feed appointments. + +MIP10c15 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c15 subproposals must use the template located at **[MIP10c15-Subproposal-Template.md](MIP10c15-Subproposal-Template.md)**. + +1. The Oracle Team compiles and asseses the information provided in MIP10c13/MIP10c14. The Oracle Team compiles and publishes [MIP10c15-Subproposal-Template](MIP10c15-Subproposal-Template) to the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo. + +2. The community reviews and gives feedback on the proposal. + +3. The Oracle Team submits a Polling Vote to the Governance Portal. + +4. If the Polling Vote passes, the Oracle Team requests the proposer to provide a fresh Ethereum public key that will be used to to sign Feed data. + +5. The Oracle Team submits the proposal to include the Feed into the subsequent Executive Vote. + +6. If the Executive Vote passes, the Oracle Team assists the newly appointed Feed to set up their Feed infrastructure and communication channels. + +7. The Oracle Team updates [MIP10c17: List of Feeds](MIP10c17-List-of-Feeds.md) + +8. The Oracle Team updates [MIP10c5: List of Active Oracles](MIP10c5-List-of-Active-Oracles.md) + +9. The Oracle Team updates [MIP10c8: List of Oracle Data Models](MIP10c8-List-of-Oracle-Data-Models.md) + +-- + +### MIP10c16: Process to Remove Feed + +Used by the community to remove a Feed. + +MIP10c16 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c16 subproposals must use the template located at **[MIP10c16-Subproposal-Template](MIP10c16-Subproposal-Template.md)**. + +1. A community member publishes the [MIP10c16-Subproposal-Template](MIP10c16-Subproposal-Template.md) in the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo. + +2. At this point the proposal is in limbo until an Oracle Team commits to doing the work required to review and validate the evidence. + +3. The Oracle Team submits a Polling Vote to the Governance Portal. + +4. If the Polling Vote succeeds, the Oracle Team bundles the proposal into the subsequent Executive Vote. + +5. The Oracle Team updates [MIP10c17: List of Feeds](MIP10c17-List-of-Feeds.md) + +6. The Oracle Team updates [MIP10c5: List of Active Oracles](MIP10c5-List-of-Active-Oracles.md) + +7. The Oracle Team updates [MIP10c8: List of Oracle Data Models](MIP10c8-List-of-Oracle-Data-Models.md) + + +--- + +### MIP10c17: List of Feeds + +A canonical record of the list of feeds. + +The list of feeds is located at **[MIP10c17-List-of-Feeds.md](MIP10c17-List-of-Feeds.md)**. + +MIP10c17 must be updated when a Feed is added or removed via MIP10c15/MIP10c16. +It is the responsibility of the Oracle Team(s) to ensure MIP10c17 is kept up to date. + +--- + +### MIP10c18: Process to Update Feed Stipend + +Used by the community to update the Feed Stipend amount that is paid monthly to each Feed. + +MIP10c18 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c18 subproposals must use the template located at **[MIP10c18-Subproposal-Template](MIP10c18-Subproposal-Template.md)**. + +**MIP10c18 is currently frozen until governance takes over the funding of Feed Stipends** + +1. A community member publishes the [MIP10c18-Subproposal-Template](MIP10c18-Subproposal-Template.md) in the Oracle section of the Maker Forum and submits a PR to the MIPS Github repo. + +2. The community reviews the details of the proposal and gives feedback. + +3. Feedback is incorporated into the [MIP10c18-Subproposal-Template](MIP10c18-Subproposal-Template.md) with changes logged in the changelog section. Changes are reflected both in the Forum thread as well as in the Github PR. + +4. An Oracle Team submits a Polling Vote to the Governance Portal. + +5. The Oracle Team updates [MIP10c17: List of Feeds](MIP10c17-List-of-Feeds.md) + +--- + +### MIP10c19: Process to Update Oracle Expiration Time + +Used by the community to update an Oracle's Expiration Time. This is the maximum period of time the Oracle will not update its price. + +MIP10c19 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c19 subproposals must use the template located at **[MIP10c19-Subproposal-Template](MIP10c19-Subproposal-Template.md)**. + +**Placeholder MIP component** + +--- + +### MIP10c20: Process to Update Oracle Spread + +Used by the community to update an Oracle's Spread. This is the minimum percentage difference between the current Oracle's price and the new price that will trigger the Oracle to update its price. + +MIP10c18 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c20 subproposals must use the template located at **[MIP10c20-Subproposal-Template](MIP10c20-Subproposal-Template.md)**. + +**Placeholder MIP component** + +--- + +### MIP10c21: Process to Update Oracle Security Module Delay + +Used by the community to update an Oracle's Oracle Security Module delay. The delay is the amount of time between the Oracle updating and the Maker Protocol utilizing the new price. + +MIP10c21 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +MIP10c21 subproposals must use the template located at **[MIP10c21-Subproposal-Template](MIP10c21-Subproposal-Template.md)**. + +**Placeholder MIP component** + +--- + diff --git a/MIP11/MIP11c3-Subproposal-Template.md b/MIP11/MIP11c3-Subproposal-Template.md new file mode 100644 index 000000000..20074c630 --- /dev/null +++ b/MIP11/MIP11c3-Subproposal-Template.md @@ -0,0 +1,26 @@ +# MIP11c3: Subproposal for Onboarding General Risk Models + +## Preamble +``` +MIP11c3-SP: # +Author(s): +Contributors: +Risk Team Name: +General Risk Model Name: +Status: +Date Proposed: +Date ratified: +``` +## Specification + +### Motivation: + - A detailed explanation advocating the need for the addition of the general risk model. + +### General Model Details + - The full details of the proposed general model. This includes the following requirements (as highlighted in **MIP11c1 - General Model Requirements)** + 1. A framework for quantitative risk methodology, fundamental analysis or due diligence. + 2. A scoring framework for collateral assets that enables a standardized approach for converting qualitative analysis into numerical outputs. This is achieved through a ratings-based methodology. + 3. A quantitative model that describes the process for computing risk parameters such as the Stability Fee, Liquidation Ratio, DSR, etc. + +### Relevant Information: + - Links to any further discussions related to the onboarding of the proposed general model. diff --git a/MIP11/MIP11c3-Subproposals/placeholder.md b/MIP11/MIP11c3-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP11/MIP11c3-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP11/MIP11c4-Subproposal-Template.md b/MIP11/MIP11c4-Subproposal-Template.md new file mode 100644 index 000000000..0bccf90a3 --- /dev/null +++ b/MIP11/MIP11c4-Subproposal-Template.md @@ -0,0 +1,21 @@ +# MIP11c4: Subproposal for Offboarding General Risk Models + +## Preamble +``` +MIP11c4-SP: # +Author(s): +Contributors: +Risk Team Name: +General Risk Model Name: +Status: +Date Proposed: +Date ratified: +Date of Proposed Removal: +``` +## Specification + +### Removal Motivation + - An explanation behind the motivation for the removal of the general risk model. + +### Relevant Information + - Links to evidence further backing the motivation behind the removal of the general risk model. diff --git a/MIP11/MIP11c4-Subproposals/placeholder.md b/MIP11/MIP11c4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP11/MIP11c4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP11/mip11.md b/MIP11/mip11.md index 6a9887aa9..7c1cb9c48 100644 --- a/MIP11/mip11.md +++ b/MIP11/mip11.md @@ -6,19 +6,20 @@ MIP#: 11 Title: Collateral Onboarding General Risk Model Management Author(s): Cyrus Younessi (@DonutJr), Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: +Date Ratified: 2020-05-02 Dependencies: MIP0, MIP3, MIP7 Replaces: n/a ``` ## References -No referenced materials. +**[MIP11c3-Subproposal-Template.md](MIP11c3-Subproposal-Template.md)** +**[MIP11c4-Subproposal-Template.md](MIP11c4-Subproposal-Template.md)** ## Sentence Summary -MIP11 defines the requirements of general risk models and how they are onboarded to and offboarded from the Maker Protocol. +MIP11 defines the requirements of general risk models and how they are onboarded and offboarded from the Maker Protocol. ## Paragraph Summary @@ -73,50 +74,29 @@ Risk models are a crucial element of the Maker Protocol's maintenance and growth ### MIP11c3: Process for Onboarding -- **Outcome:** The General Risk Model specified in the MIP11c3 Sub Proposal is appended to MIP11c2. +MIP11c3 is a Process MIP component that allows the onboarding of a general risk model using a subproposal. + +If a MIP11c3 subproposal is Accepted, The General Risk Model specified in the MIP11c3 subproposal is appended to the list in MIP11c2 by a MIP Editor. + +MIP11c3 subproposals have the following parameters: - **Feedback Period:** 0 days - **Frozen period:** 0 days -- **Subproposal Template:** -``` - Introduction - - MIP11c3-SP: # - - Risk Team Name: - - General Risk Model Name: - - Date Proposed: - - Specification - - - Motivation: - - A detailed explanation advocating the need for the addition of the general risk model. - - General Model Details - - The full details of the proposed general model. This includes the following requirements (as highlighted in **MIP11c1 - General Model Requirements)** - 1. A framework for quantitative risk methodology, fundamental analysis or due diligence. - 2. A scoring framework for collateral assets that enables a standardized approach for converting qualitative analysis into numerical outputs. This is achieved through a ratings-based methodology. - 3. A quantitative model that describes the process for computing risk parameters such as the Stability Fee, Liquidation Ratio, DSR, etc. - - Relevant Information: - - Links to any further discussions related to the onboarding of the proposed general model. -``` + +MIP11c3 subproposals must use the template located at **[MIP11c3-Subproposal-Template.md](MIP11c3-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + --- ### MIP11c4: Process for Offboarding -- **Outcome:** The General Risk Model specified in the MIP11c4 Sub Proposal is removed from MIP11c2. +MIP11c4 is a Process MIP component that allows the removal of an active general risk model using a subproposal. + +If a MIP11c4 subproposal is Accepted, The General Risk Model specified in the MIP11c4 Sub Proposal is removed from the list in MIP11c2 by a MIP Editor. + +MIP11c4 subproposals have the following parameters: + - **Feedback Period:** 0 days - **Frozen Period:** 0 days -- **Subproposal Template:** -``` - Introduction - - MIP11c4-SP: # - - Risk Team Name: - - General Risk Model Name: - - Date of Proposed Removal: - - Specification - - - Removal Motivation: - - An explanation behind the motivation for the removal of the general risk model. - - - Relevant Information: - - Links to evidence further backing the motivation behind the removal of the general risk model. -``` + +MIP11c4 subproposals must use the template located at **[MIP11c4-Subproposal-Template.md](MIP11c4-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + --- diff --git a/MIP12/MIP12c2-Subproposal-Template.md b/MIP12/MIP12c2-Subproposal-Template.md new file mode 100644 index 000000000..c7b763f72 --- /dev/null +++ b/MIP12/MIP12c2-Subproposal-Template.md @@ -0,0 +1,29 @@ +# MIP12c2: Subproposal for proposing new Risk Parameters, Oracles, and Collateral Adapters + +## Preamble +``` +MIP12c2-SP: # +Title: +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date ratified: <yyyy-mm-dd> +``` + +## Specification + +### Summary + +- A short description of the proposed improvement. + +### Proposal Details +- The three required deliverables + +### Motivation + +- Explanation as to why the sub proposal is necessary. + +### Relevant Information: + +- Links to evidence further backing the motivation behind the proposal for adding new Risk Parameters, Oracle, or Collateral Adapter. diff --git a/MIP12/MIP12c2-Subproposals/placeholder.md b/MIP12/MIP12c2-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP12/MIP12c2-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP12/mip12.md b/MIP12/mip12.md index 6b4bccbe7..20c950be1 100644 --- a/MIP12/mip12.md +++ b/MIP12/mip12.md @@ -6,15 +6,15 @@ MIP#: 12 Title: Collateral and Risk Parameter Management Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Type: Technical, Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: MIP0, MIP3, MIP7, MIP10, MIP11 Replaces: n/a ``` ## References -No referenced materials. +**[MIP12c2-Subproposal-Template.md](MIP12c2-Subproposal-Template.md)** ## Sentence Summary @@ -52,42 +52,19 @@ This proposal will focus on the collateral onboarding process blueprint for subm ### MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters -**Description:** This is a technical process MIP component for submitting **MIP12c2-SPs** that allows any community member to propose new risk parameters, oracles, and adapters for a new, or existing collateral type, based on the work products of domain teams. MIP12-Subproposals (MIP12c2-SPs) MUST contain the following **three** deliverables in the specification section: +MIP12c2 is a Process MIP component that allows the any community member to propose new risk parameters, oracles, and adaptors for a new, or existing collateral type based on the work products of domain teams using a subproposal. +MIP12c2 subproposals must contain the following three deliverables in the specification section: 1. A risk construct based on an active general risk model by a ratified risk team and the results of polls that define all risk parameters for the collateral type. 2. A security audit and risk assessment of a deployed and operational collateral adapter, medianizer, oracle security module and executive vote code by a smart contracts domain team. 3. A security audit and risk assessment of the current status of the oracle price feeds for supporting the new collateral type by an oracle domain team. + MIP12c2 subproposals have the following parameters: +- **Feedback Period:** 0 days +- **Frozen Period:** 0 days + +MIP12c2 subproposals must use the template located at **[MIP12c2-Subproposal-Template.md](MIP12c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -**Feedback Period:** 0 days - -**Frozen Period:** 0 days - -**Subproposal Template:** - - Introduction - - MIP12c2-SP: # - Title: <Title> - Name: <Name and/or Github handle> - Date Proposed: <date created on, in (yyyy-mm-dd) format> - - Specification - - - Summary - - - A short description of the proposed improvement. - - - Proposal Details - - The three required deliverables - - - Motivation - - - Explanation as to why the sub proposal is necessary. - - Relevant Information: - - - Links to evidence further backing the motivation behind the proposal for adding n**ew Risk Parameters, Oracle, or Collateral Adapter** --- diff --git a/MIP2/mip2.md b/MIP2/mip2.md index 5382a1e36..37c3ca9dc 100644 --- a/MIP2/mip2.md +++ b/MIP2/mip2.md @@ -4,12 +4,12 @@ ``` MIP#: 2 Title: Launch Period -Author(s): Rune Christensen (@Rune23) and Charles St.Louis (@CPSTL) +Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: MIP0, MIP1 Replaces: n/a ``` @@ -32,7 +32,7 @@ Lastly, the proposal states that MIP2 itself will become obsolete when the Probl ## 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. +Defines the first interim phase, in which the feedback period and freeze period for MIPs are ignored until 3 months after 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. @@ -61,8 +61,8 @@ As a result, the community should prioritize getting the initial processes in pl - 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 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. +1. A single vote approves or rejects all MIPs and Subproposals during phase 1. +2. 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 3 months after there is a formal a core governance framework in place and a functional collateral onboarding process. @@ -86,5 +86,3 @@ Interim Phase 2 ends when the Problem Space has been addressed. More specificall ### MIP2c3: MIP2 Obsolescence Once the Problem space has been addressed, MIP2 stops having an effect and the Feedback Period and Frozen Period defined in MIP0 take effect immediately. Furthermore, MIP2 is immediately granted the `Obsolete` status, meaning anything defined within MIP2 should no longer be considered to be the active standard. - ---- diff --git a/MIP3/MIP3c2-Subproposal-Template.md b/MIP3/MIP3c2-Subproposal-Template.md new file mode 100644 index 000000000..4d91d81c0 --- /dev/null +++ b/MIP3/MIP3c2-Subproposal-Template.md @@ -0,0 +1,22 @@ +# MIP3c2: Subproposal Template for Default Inclusion Threshold Modification + +## Preamble +``` +MIP3c2-SP#: +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date Ratified: <yyyy-mm-dd> +``` + +## Specification + +### Summary +Proposal to modify the Default Inclusion Threshold + +### Motivation +Input the motivation and reasoning behind the proposed change of the default inclusion threshold. + +### Proposal Details +The new default inclusion threshold amount (number). diff --git a/MIP3/MIP3c2-Subproposals/placeholder.md b/MIP3/MIP3c2-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP3/MIP3c2-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP3/mip3.md b/MIP3/mip3.md index c6f2e8f6f..27945637f 100644 --- a/MIP3/mip3.md +++ b/MIP3/mip3.md @@ -1,5 +1,6 @@ # MIP3: Governance Cycle + ## Preamble ``` MIP#: 3 @@ -7,15 +8,15 @@ Title: Governance Cycle Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[MIP3c2-Subproposal-Template.md](MIP3c2-Subproposal-Template.md)** ## Sentence Summary @@ -27,10 +28,16 @@ This proposal formally introduces a Governance Cycle. The Governance Cycle provi ## Component Summary -**MIP3c1: Governance Cycle Breakdown** +**MIP3c1: Governance Cycle Definitions** + +Defines key terms related to the Governance cycle. + +**MIP3c2: 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** +**MIP3c3: Default Inclusion Threshold Modification Subproposals** + A process component that defines a method and template for the modification of the default inclusion threshold. @@ -42,7 +49,16 @@ The structure of the governance cycle enables active governance participants to ## Specification / Proposal Details -### MIP3c1: Governance Cycle Breakdown +### MIP3c1: Governance Cycle Definitions + +- **Default Inclusion Threshold** is a variable amount that can be changed by MIP3c3 subproposals. The default inclusion threshold value is automatically counted towards the no vote tally of each item in the inclusion poll. The default inclusion threshold is set at 3000 MKR but can be changed with [MIP3c2 subproposals](MIP3c2-Subproposal-Template.md). +- **Inclusion Poll** When governance users decide what they want to bundle together into the governance poll. The inclusion poll also serves as the threshold to necessitate the attention of a governance poll. An important aspect of the inclusion poll is that it allows MKR holders to have a big impact early on in the governance cycle. +- **Governance Poll** The Governance Poll is a yes/no MKR poll that accepts or rejects the combination of all MIPs that passed the inclusion poll stage, including acceptance of any executive vote code from Technical MIP components or subproposals. +- **Executive Vote** The final vote to determine if proposals ultimately gets accepted or rejected. + +--- + +### MIP3c2: Governance Cycle Breakdown Each monthly governance cycle begins on the first Monday of the month, with Maker Improvement Proposals (MIPs) submitted by community members (defined within the MIP0 Framework). These proposals will be considered for inclusion at the end of the month's Executive vote. The governance cycle ends with an Executive vote that begins on the 4th Monday of the month. @@ -55,56 +71,52 @@ Proposals submitted must follow the guidelines defined in MIP0. *Time is inclusive and in based on UTC (Coordinated Universal Time) and the Gregorian calendar* -**Week 1** -- **1st Monday-Wednesday of the month:** - - The **Formal submission** (Phase 5 described in MIP0c2) of proposals that are to be included in the new governance cycle. - - The formal submission is done on the formal submission category on the MIPs Discourse forum (as defined in Phase 5 in MIP0c2) -- **1st Thursday of the month:** - - **Inclusion Poll Review (Governance Meeting):** Discussion surrounding which proposals are in accordance with guidelines (defined in the MIP0 Framework), which proposals are inadequate (even if technically following the guidelines) +**Week 1, Monday** +- The **Formal Submission** (Phase 5 described in [MIP0c3](https://github.com/makerdao/mips/blob/master/MIP0/mip0.md#mip0c3-the-mip-lifecycle)) of proposals that are to be included in the new governance cycle by the MIP Authors. This phase lasts for 3 days. +- The formal submission of MIPs are done on the formal submission category on the MakerDAO forums under the Maker Improvement Proposal subcategory (as defined in Phase 5 in [MIP0c3](https://github.com/makerdao/mips/blob/master/MIP0/mip0.md#mip0c3-the-mip-lifecycle)). + +**Week 1, Thursday** +- Governance Facilitators do the **Submission Review** as part of the governance meeting and determine which of the proposed MIPs are in accordance with guidelines (defined in the MIP0 Framework) and should be included in the inclusion poll. -**Week 2** +**Week 2, Monday** +- The Governance facilitators publish the set of **Inclusion Polls**, one per proposal. Each poll has two options: + - Yes or no. + - Where the `no` votes simply increase the barrier of the proposal to pass. +- If the Yes votes for a given option in the inclusion poll are higher than the combination of No votes and the `default inclusion threshold` at the end of the Inclusion Poll, the proposal will be included in the **Governance Poll**. + - The default inclusion threshold is set to 3000 MKR. + - If votes: `yes` > (`no` + `default inclusion threshold`) = inclusion in governance poll. -- **2nd Monday of the month**: - - The Governance facilitators publish an inclusion poll. The proposals that the specific Governance Facilitators' have general consensus on are included, but each Governance Facilitator, in their own can add their own individual short description and list order (which is critical for voter heuristic behaviour and important power of a governance facilitator in times of dispute or uncertainty). - - The **Default Inclusion Threshold** is a variable amount that can be changed by MIP3c3 sub proposals. The default inclusion threshold value is automatically counted towards the no vote tally of each item in the inclusion poll. The default inclusion threshold is changed with MIP3c2 subproposals. - - **An MKR voter has 2 options for each proposal in an inclusion poll:** - - Yes or no. - - Where the `no` votes simply increase the barrier of the proposal to pass. - - **Outcomes:** If the Yes votes for a given option in the inclusion poll are higher than the combination of No votes and the `default inclusion threshold`, the proposal will be included in the governance poll. - - If votes: `yes` > (`no` + `default inclusion threshold`) = inclusion in governance poll. +**Week 2, Thursday** -- **2nd Thursday of the month:** - - **The Governance Poll Review (Governance Meeting)**: occurs, covering the general risk and governance topics at hand and without any MIP decision making discussion. +- The Governance facilitators do the **Inclusion Review** as part of the governance meeting in which they confirm the inclusions in the **Governance Poll**. -**Week 3** - +**Week 3, Monday** +- The **Governance Poll** is submitted by the Governance Facilitators. This poll runs for 3 days. -- **3rd Monday-Wednesday of the month:** - - The Governance poll submitted by the Governance Facilitator. - - The Governance poll will run from Monday until Wednesday. - - The Governance Poll is a yes/no MKR poll that accepts or rejects the combination of all MIPs that passed the inclusion poll stage, including any executive vote code from Technical MIP components or sub proposals. -- **3rd Thursday of the month:** - - **Executive Vote Review (Governance Meeting)** - this public meeting will focus on either future proposals or controversy around the current governance poll and the future upcoming executive vote. - - In case there are too many `no` votes in the governance poll, and there is evidence that there is an effort to silence legitimate concerns in the community this meeting provides opportunities for compromise and the community and governance facilitators must consider whether it is creating a risk of governance split. If a governance facilitator believes that the proposed executive vote will result in a governance split, the Governance Facilitator should not deploy the executive vote and must instead work with the community to resolve the problem. Thus, if all governance facilitators are in consensus that the executive vote creates a significant risk of a community split, the executive vote will not happen and the MIPs that were supposed to be up for an executive vote, instead have their status changed to deferred. + +**Week 3,Thursday** +- The Governance Facilitators do the **Governance Poll Review** as part of the governance meeting in which they confirm the outcome of the **Governance Poll**. +- The Governance Facilitators must come to consensus on whether the results of the governance poll warrant moving forward to the executive vote. + - This responsibility is intended to be used in the case in which the Governance Facilitators believe that moving forward to an **Executive Vote** would negatively affect community cohesion. + - If the Governance Facilitators oppose the **Governance Poll** outcome, they must clearly communicate their reasons for disregarding the poll results. + - In the event the Governance Faciltiators abuse this power, they should be removed using a [MIP0c13 subproposal](https://github.com/makerdao/mips/blob/templates/MIP0/MIP0c13-Subproposal-Template.md). -**Week 4** - -- **4th Monday of the month:** - - The Executive vote is submitted if the governance poll has passed and the `no` votes are not too high to deem it a threat to consensus. - - Regular Executive votes must have an expiration of 7 days, meaning they blank themselves after 7 days. - - MIPs and Sub Proposals only get the accepted status if the executive vote they are included in passes within the 7-day limit. If the executive vote fails to pass within the 7-day limit, the MIPs and Sub Proposals have their status changed to rejected. -- **4th Thursday of the month:** - - The **Retro & Planning Meeting** occurs, covering the general risk and governance topics at hand and without any MIP decision making discussion. Discussion around the governance poll outcomes (for proposed collateral types) and proposals for next month, or retrospective on current governance cycle controversy. - - MIP3 sub proposals focus on modifying the default inclusion threshold for the inclusion polls. - - They are submitted to the governance cycle like any other proposal and their modified default inclusion threshold takes effect from the governance cycle following the successful passing of their governance cycle’s executive vote. +**Week 4, Monday** +- The **Executive Vote** is submitted if the Governance Facilitators confirm the 'yes' outcome of the **Governance Poll**. +- The **Executive Vote** must have an expiration of 4 days, after which is has no effect. +- MIPs and subproposals only move to the 'Accepted' status if the executive vote they are included in passes within the 4-day limit. If the executive vote fails to pass within the 4-day limit, the MIPs and subproposals have their status changed to 'Rejected'. + +**Week 4, Thursday** +- The Governance Facilitators do the **Governance Cycle Review** as part of the governance meeting in which they summarize and discuss the Governance Cycle with the community. +- The Governance Facilitators also discuss the upcoming governance cycle and potential submissions with the community. -### Governance Cycle Overview Diagram +### Governance Cycle Overview -![Gov Cycle (1)](https://user-images.githubusercontent.com/32653033/79087199-8acd2080-7d0c-11ea-8978-178aa61f52b9.png) +![Gov Cycle](https://user-images.githubusercontent.com/32653033/80249627-2f6e2d00-8640-11ea-8b56-6163276ded4c.png) ### MIP Life Cycle Overview ![mip_life_cycle](https://user-images.githubusercontent.com/32653033/79087211-8e60a780-7d0c-11ea-833a-70d12cad56aa.png) @@ -112,31 +124,16 @@ Proposals submitted must follow the guidelines defined in MIP0. --- -### MIP3c2: Default Inclusion Threshold Modification Subproposals - -The Default Inclusion Threshold can be modified with subproposals. The subproposals will follow the logic below: -- **Default Feedback Period**: 3 months -- **Frozen Period**: 1 month -- **Subproposal Template**: +### MIP3c3: Default Inclusion Threshold Modification Subproposals -``` -Introduction +MIP3c2 is a Process MIP component that allows the Default Inclusion Threshold to be modified for the Inclusion poll. This is done through a subproposal. The subproposals are submitted to the governance cycle like any other proposal and if ratified, their modified default inclusion threshold takes effect from the governance cycle following the successful passing of their governance cycle’s executive vote. -- MIP3c2-SP#: -- Author(s): -- Date Proposed: <date created on, in (yyyy-mm-dd) format> +MIP3c2 subproposals have the following parameters: +- **Default Feedback Period**: 3 months +- **Frozen Period**: 1 month -Specification - -Summary -- Proposal to modify the Default Inclusion Threshold - -Motivation -- Input the motivation and reasoning behind the proposed change of the default inclusion threshold. -Specification / Proposal Details -- The new default inclusion threshold amount (number). -``` +MIP3c2 subproposals must use the template located at **[MIP3c2-Subproposal-Template.md](MIP3c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. --- diff --git a/MIP4/MIP4c2-Subproposal-Template.md b/MIP4/MIP4c2-Subproposal-Template.md new file mode 100644 index 000000000..92b633ef6 --- /dev/null +++ b/MIP4/MIP4c2-Subproposal-Template.md @@ -0,0 +1,27 @@ +# MIP4c2: MIP Amendment Subproposals + +## Preamble +``` +MIP4c2-SP#: # +MIP to be amended: <MIP#> +Author(s): +Contributors: +Status: +Date of Amendment Submission: <yyyy-mm-dd> +Date of ratification: <yyyy-mm-dd> +``` +## Specification + +### Motivation + - Explanation behind the amendment of the MIP + - Explanation of why this change is valid for an amendment rather than a replacement. + - Any impact this has on other MIPs that interact with the MIP in question. + +### Amended Components + - A list of the components that have been amended. + +### Amendment Pull Request (PR) + - A link to the PR containing the amendment. This PR must have remained unchanged for the Frozen Period. + +### Relevant Information + - Links to evidence further backing the motivation. diff --git a/MIP4/MIP4c2-Subproposals/placeholder.md b/MIP4/MIP4c2-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP4/MIP4c2-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP4/MIP4c3-Subproposal-Template.md b/MIP4/MIP4c3-Subproposal-Template.md new file mode 100644 index 000000000..752d9de73 --- /dev/null +++ b/MIP4/MIP4c3-Subproposal-Template.md @@ -0,0 +1,20 @@ +# MIP4c3: MIP Removal Subproposals + +## Preamble +``` +MIP4c3-SP#: # +MIP to be removed: <MIP#> +Author(s): +Contributors: +Status: +Date of Removal Submission: <yyyy-mm-dd> +Date of ratification: <yyyy-mm-dd> +``` +## Specification + +### Motivation + - Explanation behind the removal of the MIP. + - Any impact this has on other MIPs that interact with the MIP in question. + +### Relevant Information +- Links to evidence further backing the motivation. diff --git a/MIP4/mip4.md b/MIP4/mip4.md index f03258ab8..c000228dd 100644 --- a/MIP4/mip4.md +++ b/MIP4/mip4.md @@ -7,15 +7,16 @@ Title: MIP Amendment and Removal Process Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[MIP4c2-Subproposal-Template.md](MIP4c2-Subproposal-Template.md)** +**[MIP4c3-Subproposal-Template.md](MIP4c3-Subproposal-Template.md)** ## Sentence Summary @@ -62,61 +63,19 @@ MIP4 also enables the removal of MIPs that are no longer useful. If there are ot --- ### MIP4c2: MIP Amendment Process - This component details the process of making amendments. -- **Feedback Period:** 1 month -- **Frozen Period:** 1 week -- **Template:** +MIP4c2 is a Process MIP component that allows the amendment of an Accepted MIP using a subproposal. MIP4c2 subproposals have the following parameters: +- **Default Feedback Period**: 3 months +- **Frozen Period**: 1 month -``` -Introduction - - - MIP to be amended: <MIP#> - - - Amendment Author: +MIP4c2 subproposals must use the template located at **[MIP4c2-Subproposal-Template.md](MIP4c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. - - Date of Amendment Submission: <date created on, in (yyyy-mm-dd) format> - -Specification - - - Motivation: - - Explanation behind the amendment of the MIP - - Explanation of why this change is valid for an amendment rather than a replacement. - - Any impact this has on other MIPs that interact with the MIP in question. - - - Amended Components: - - A list of the components that have been amended. - - - Amendment PR: - - A link to the PR containing the amendment. This PR must have remained unchanged for the Frozen Period. - - - Relevant Information: - - Links to evidence further backing the motivation. -``` --- ### MIP4c3: MIP Removal Process +MIP4c3 is a Process MIP component that allows the removal of an Accepted MIP using a subproposal. MIP4c3 subproposals have the following parameters: +- **Default Feedback Period**: 3 months +- **Frozen Period**: 1 month -- This component details the process of removing MIPs. -- **Feedback Period:** 3 months -- **Frozen Period:** 1 month -- **Template:** +MIP4c3 subproposals must use the template located at **[MIP4c3-Subproposal-Template.md](MIP4c3-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -``` -Introduction - - - MIP to be removed: <MIP#> - - - Author: - - - Date of Submission: <date created on, in (yyyy-mm-dd) format> - -Specification - - - Motivation: - - Explanation behind the removal of the MIP - - Any impact this has on other MIPs that interact with the MIP in question. - - - Relevant Information: - - Links to evidence further backing the motivation. -``` --- diff --git a/MIP5/mip5.md b/MIP5/mip5.md index 661410987..d8d92acdc 100644 --- a/MIP5/mip5.md +++ b/MIP5/mip5.md @@ -7,9 +7,9 @@ Title: Emergency Voting System Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` diff --git a/MIP6/MIP6c2-Collateral-Application-Template.md b/MIP6/MIP6c2-Collateral-Application-Template.md new file mode 100644 index 000000000..d46558cca --- /dev/null +++ b/MIP6/MIP6c2-Collateral-Application-Template.md @@ -0,0 +1,15 @@ +# Collateral Application Template + +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. +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. (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. \ No newline at end of file diff --git a/MIP6/MIP6c3-Subproposal-Template.md b/MIP6/MIP6c3-Subproposal-Template.md new file mode 100644 index 000000000..f1268fac9 --- /dev/null +++ b/MIP6/MIP6c3-Subproposal-Template.md @@ -0,0 +1,19 @@ +# MIP6c3: Subproposal for changing the collateral application form + +## Preamble +``` +MIP6c3-SP: # +Title: +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date Ratified: <yyyy-mm-dd> +``` +## Specification + +### Motivation + - Explain the motivation behind the changes to the application questions. + +### List of changes to Application questions + - < List > diff --git a/MIP6/MIP6c3-Subproposals/placeholder.md b/MIP6/MIP6c3-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP6/MIP6c3-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP6/mip6.md b/MIP6/mip6.md index 372145217..fbcbd9f45 100644 --- a/MIP6/mip6.md +++ b/MIP6/mip6.md @@ -7,19 +7,20 @@ Title: Collateral onboarding form/forum template Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: @LongForWisdom, Leo Jsaraceno (Mitote), Helge Andreas Qvam (@planet_X) Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[MIP6c2-Collateral-Application-Template.md](MIP6c2-Collateral-Application-Template.md)** +**[MIP6c3-Subproposal-Template.md](MIP6c3-Subproposal-Template.md)** ## Sentence 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. +MIP6 defines a standardized application form used to kick off the process of onboarding a new collateral asset to the Maker Protocol. ## Paragraph Summary @@ -30,10 +31,10 @@ The purpose of this proposal is to standardize the collateral onboarding form/fo **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** +**MIP6c2: Application Template** Provides an collateral application form template to be used in the submission process defined in MIP6c1. -**MIP6c3: Sub Proposal Framework** +**MIP6c3: Application Template Amendment Process** A process component that defines a method and template to amend the collateral application form template defined in MIP6c2. ## Motivation @@ -67,60 +68,21 @@ Although this is only one component of the overall collateral onboarding process <img width="649" alt="mip6" src="https://user-images.githubusercontent.com/32653033/79087563-ad136e00-7d0d-11ea-89b2-679747275ecf.png"> --- -### MIP6c2: Application Form Template +### MIP6c2: Application Template -Responses to these questions serve as an introduction to the community, this minimum set of information helps intrigued community members research the project on their own. Other pitch materials of all sorts are encouraged if the applicant believes it will help them garner support and excitement for the collateral. +MIP6c2 defines a template for collateral applications as described in MIP6c1. This template is located at **[MIP6c2-Collateral-Application-Template.md](MIP6c2-Collateral-Application-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -**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. -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. (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. +Responses to these questions serve as an introduction to the community, this minimum set of information helps intrigued community members research the project on their own. Other pitch materials of all sorts are encouraged if the applicant believes it will help them garner support and excitement for the collateral. --- -### MIP6c3: Sub Proposal Framework - -In addition to the standardized template for submitting collateral types to be reviewed, this MIP also introduces MIP6-Subproposal (MIP6-SPs). - -**Requirements** +### MIP6c3: Application Template Amendment Process -MIP6-SPs will be used to define changes to the required fields of this collateral application form/forum post. However, there is a lot of flexibility, both when it comes to omitting certain data, but more importantly when it comes to adding extra data. It is expected that the community will often have a backlog of the additional de-facto standard required data fields in proposals that aren’t yet added to the official required fields via MIP6-SPs. - -In order to submit a MIP6-Subproposals, one must create a MIP from the provided template. - -**MIP6-SP Template:** -- **Feedback Period**: 1 month +MIP6c3 is a Process MIP component that allows the modification of the template defined in MIP6c2 using a subproposal. MIP6c3 subproposals have the following parameters: +- **Default Feedback Period**: 1 month - **Frozen Period**: 1 week -- **Sub Proposal Template**: - - -``` -Introduction - - - MIP6c3-SP: # - - - Title: <Title> - - - Author(s): <Name>, <Github handle> - - Date Proposed: year-month-day +MIP6c3 subproposals must use the template located at **[MIP6c3-Subproposal-Template.md](MIP6c3-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -Specification - - Motivation - - Explain the motivation behind the changes to the application questions. - - - List of changes to Application questions. - -``` +--- diff --git a/MIP7/MIP7c3-Subproposal-Template.md b/MIP7/MIP7c3-Subproposal-Template.md new file mode 100644 index 000000000..28d5bca8f --- /dev/null +++ b/MIP7/MIP7c3-Subproposal-Template.md @@ -0,0 +1,36 @@ +# MIP7c3: Subproposal Template for Domain Team Onboarding (MIP7c3) + +## Preamble +``` +MIP7c3-SP#: # +Author(s): +Contributors: +Status: +Date Applied: <yyyy-mm-dd> +Date Ratified: <yyyy-mm-dd> +--- +Domain Role: <Ex: Smart Contract Domain Team> +Proposed Applicant: +``` +## Application Form + +### Domain Team Introduction + +- Brief introduction / pitch of the team, why they want to work. + + +### Motivation + +- Why the team wants to join a certain domain. + + +### Work Credentials + +- Full names of team members +- Past work experience of members + +### Relevant Information + +- Github Accounts +- Forum Accounts +- Other diff --git a/MIP7/MIP7c3-SP1.md b/MIP7/MIP7c3-Subproposals/MIP7c3-SP1.md similarity index 75% rename from MIP7/MIP7c3-SP1.md rename to MIP7/MIP7c3-Subproposals/MIP7c3-SP1.md index ccc9d0841..cd0ffc846 100644 --- a/MIP7/MIP7c3-SP1.md +++ b/MIP7/MIP7c3-Subproposals/MIP7c3-SP1.md @@ -8,7 +8,7 @@ MIP7c3-SP#: 1 Author: Mariano Conti Contributors: n/a -Status: Conception +Status: Request for Comments (RFC) Date Applied: 2020-04-22 Date Ratified: <yyyy-mm-dd> --- @@ -26,8 +26,6 @@ Proposed Applicant: Mariano Conti - **Motivation** - A Smart Contracts domain team is needed in order to help maintain the Maker Protocol. Additionally, a Smart Contracts domain team is needed to get collateral types onboarded to the Protocol, specifically to build and approve collateral type adapters as well as deploy the other necessary smart contracts. This includes the medianizer and oracle security module (OSM). Also, the Smart Contracts domain team is required to create the executive vote code and provide the technical risk assessments for the required smart contracts. - - As the Ethereum blockchain continues to improve and change via EIPs and hard forks, the Smart Contracts domain team will monitor these changes to make sure the Maker Protocol can continue to function correctly, proposing and making changes to it should they be needed. - - Should MIPs be voted in that would change the functionality of the Maker Protocol in any way that requires changes to the underlying smart contracts, the Smart Contracts domain team would be tasked with building, testing and deploying this new functionality. - **Work Credentials** diff --git a/MIP7/MIP7c4-Subproposal-Template.md b/MIP7/MIP7c4-Subproposal-Template.md new file mode 100644 index 000000000..c310ca67e --- /dev/null +++ b/MIP7/MIP7c4-Subproposal-Template.md @@ -0,0 +1,20 @@ +# MIP7c4: Subproposal Template for Domain Team Offboarding (MIP7c4) + +## Preamble +``` +MIP7c4-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date Removed: <yyyy-mm-dd> +--- +Domain Team Name: <Ex: Smart Contract Domain Team> +``` +## Specification + +### Removal Motivation + - An explanation behind the motivation for the removal of the domain team. + +### Relevant Information + - Links to evidence further backing the motivation behind the removal of the domain team. diff --git a/MIP7/MIP7c4-Subproposals/placeholder.md b/MIP7/MIP7c4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP7/MIP7c4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP7/mip7.md b/MIP7/mip7.md index 9d93c78a2..70f88fe03 100644 --- a/MIP7/mip7.md +++ b/MIP7/mip7.md @@ -7,15 +7,16 @@ Title: Onboarding and Offboarding Domain Teams (Collateral Onboarding) Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` ## References -No referenced materials. +**[MIP7c3-Subproposal-Template.md](MIP7c3-Subproposal-Template.md)** +**[MIP7c4-Subproposal-Template.md](MIP7c4-Subproposal-Template.md)** ## Sentence Summary @@ -62,10 +63,10 @@ This list can be amended through the onboarding (MIP7c3) and offboarding compone **Entries into this list should follow the following template:** ``` -- Team Name: The name of the onboarded domain team. +Team Name: The name of the onboarded domain team. - Sub-proposal Number (MIP7c3-SP): # - Domain: The domain in which the team operates. -- Date Added: <date in (yyyy-mm-dd) format> +- Date Added: (yyyy-mm-dd) ``` **Active Domain Teams List** @@ -78,69 +79,40 @@ This list can be amended through the onboarding (MIP7c3) and offboarding compone **2. Smart Contracts Domain Teams:** +- **Team Name:** Blue Team + - **Sub-proposal Number (MIP7c3-SP):** 1 + - **Domain:** Smart Contracts + - **Date Added:** 2020-05-02 [Ratification Vote](https://vote.makerdao.com/executive-proposal/lower-usdc-sf-add-wbtc-ratify-the-initial-mips-and-subproposals) + **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 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:** -``` -Introduction - - - Domain: <Ex: Risk> - - Domain Team Name: <Ex: Risk Team A> - - Author: <Person creating this proposal> - - Date Applied: <date created on, in (yyyy-mm-dd) format> +MIP7c3 is a Process MIP component that allows the onboarding of a domain team using a subproposal. -Application +If onboarded through a MIP7c3 subproposal, the domain team is added to the The Current Domain Team Roles list defined in MIP7c2 by a MIP Editor. -- Domain Team Introduction +MIP7c3 subproposals have the following parameters: +- **Feedback Period**: 3 months +- **Frozen Period**: 1 month - - Brief introduction / pitch of the team, why they want to work. - +MIP7c3 subproposals must use the template located at **[MIP7c3-Subproposal-Template.md](MIP7c3-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. -- Motivation +--- - - Why the team wants to join a certain domain. - +### MIP7c4: Domain Team offboarding -- Work Credentials +MIP7c4 is a Process MIP component that allows the removal of a domain team using a subproposal. - - Full names of members - - Past work experience of members - -- Relevant Information - - - Github accounts - - Forum accounts - - Other -``` ---- +If offboarded through a MIP7c4 subproposal the domain team is removed from the Current Domain Team Roles list defined in MIP7c2 by a MIP Editor. -### MIP7c4: Domain Team offboarding -- **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. + MIP7c4 subproposals have the following parameters: - **Feedback Period**: 0 days - **Frozen Period**: 0 days -- **Offboarding template:** -``` -Introduction - - - Domain Team Name: - - Date of Proposed Removal: <date created on, in (yyyy-mm-dd) format> - -Specification - - - Removal Motivation: - - An explanation behind the motivation for the removal of the domain team. - - - Relevant Information: - - Links to evidence further backing the motivation behind the removal of the domain team. -``` +MIP7c4 subproposals must use the template located at **[MIP7c4-Subproposal-Template.md](MIP7c4-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + --- diff --git a/MIP8/mip8.md b/MIP8/mip8.md index a70eed62d..fd4c6b9ee 100644 --- a/MIP8/mip8.md +++ b/MIP8/mip8.md @@ -7,9 +7,9 @@ Title: Domain Greenlight Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: n/a Replaces: n/a ``` diff --git a/MIP9/mip9.md b/MIP9/mip9.md index 3b40cf6ac..75d94d967 100644 --- a/MIP9/mip9.md +++ b/MIP9/mip9.md @@ -7,9 +7,9 @@ Title: Community Greenlight Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Type: Process -Status: Request for Comments (RFC) +Status: Accepted Date Proposed: 2020-04-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-02 Dependencies: MIP6, MIP8 Replaces: n/a ``` @@ -19,7 +19,7 @@ No referenced materials. ## 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. +MIP9 defines the process by which MKR Token Holders can signal their judgment on the value of a potential collateral type before domain teams spend time thoroughly investigating its inclusion into the Maker Protocol. ## Paragraph Summary diff --git a/README.md b/README.md index b3dc1eb75..ea60ecc63 100644 --- a/README.md +++ b/README.md @@ -11,22 +11,24 @@ Furthermore, MIPs will provide a mechanism for any community member to define ke - [Announcement: Kickstarting the Self-Sustaining MakerDAO Initiative](https://forum.makerdao.com/t/announcement-kickstarting-the-self-sustaining-makerdao-initiative/1864) - [The Maker Foundation’s Vision of a Self-sustaining MakerDAO: Initiation of Maker Improvement Proposals (MIPs) Framework](https://forum.makerdao.com/t/the-maker-foundation-s-vision-of-a-self-sustaining-makerdao-initiation-of-maker-improvement-proposals-mips-framework/1882) - [The Release of the 13 Initial Maker Improvement Proposals (MIPs)](https://forum.makerdao.com/t/the-release-of-the-13-initial-maker-improvement-proposals-mips/1915) - - [MIP0: The Maker Improvement Proposal Framework](https://forum.makerdao.com/t/mip0-the-maker-improvement-proposal-framework/1902) + - [MIP0: The Maker Improvement Proposal Framework](https://github.com/makerdao/mips/blob/templates/MIP0/mip0.md) - After reading through the above materials, prospective MIP Authors should first propose their proposal on the [MakerDAO Forums](https://forum.makerdao.com/c/MIPS/14) as well as complete the other criteria laid out in the `Conception` phase of the MIPs Lifecycle (described below). - **Important Notes:** - - When creating a MIP, clone the MIPs repository from GitHub, and start by filling out the appropriate [MIP template](https://github.com/makerdao/mips/blob/master/mip0.md#mip0c6-mip-templates). + - When creating a General or Technical MIP, clone the MIPs repository from GitHub, and start by filling out the appropriate [MIP template](https://github.com/makerdao/mips/tree/templates/MIP0). - When submitting a Pull Request (PR) for a MIP proposal, be sure to include the following details: - Pull Request Title:`MIP#: MIP Title` - In the PR comment box, please include the MIP's premable. This includes the following: ``` MIP#: - Title: - Author(s): - Type: - Status: Conception - Date Proposed: <year-month-day> - Dependencies: n/a - Replaces: n/a + Title: + Author(s): + Contributors: + Type: + Status: <Assigned by MIP Editor> + Date Proposed: <yyyy-mm-dd> + Date Ratified: <yyyy-mm-dd> + Dependencies: + Replaces: ``` - In the **RFC Phase**, community members may propose changes to proposed MIPs. When proposing changes to MIPs in the RFC Phase, clone the MIPs repository from GitHub, and then make a Pull Request (PR) for the respetive MIP with the following details: - PR title: `Add/Change/Delete <details> to MIP#` @@ -110,20 +112,46 @@ A status change for a MIP is requested by the MIP Author and will be reviewed by |MIP № |Date Proposed | Proposal Link |Description/Title | Status | |------|--------------|-----------------------------------|---------------------------------------------------|-----------| -| 0 | 2020-04-06 | [MIP0](https://github.com/makerdao/mips/tree/master/MIP0) |Maker Improvement Proposals Framework | RFC | -| 1 | 2020-04-06 | [MIP1](https://github.com/makerdao/mips/tree/master/MIP1) |Maker Governance Paradigms | RFC | -| 2 | 2020-04-06 | [MIP2](https://github.com/makerdao/mips/tree/master/MIP2) |Launch Period | RFC | -| 3 | 2020-04-06 | [MIP3](https://github.com/makerdao/mips/tree/master/MIP3) |Governance Cycle | RFC | -| 4 | 2020-04-06 | [MIP4](https://github.com/makerdao/mips/tree/master/MIP4) |MIP Amendment and Removal Process | RFC | -| 5 | 2020-04-06 | [MIP5](https://github.com/makerdao/mips/tree/master/MIP5) |Emergency Voting System | RFC | -| 6 | 2020-04-06 | [MIP6](https://github.com/makerdao/mips/tree/master/MIP6) |Collateral Onboarding Form/Forum Template | RFC | -| 7 | 2020-04-06 | [MIP7](https://github.com/makerdao/mips/tree/master/MIP7) |Domain Teams (Collateral Onboarding) | RFC | -| 8 | 2020-04-06 | [MIP8](https://github.com/makerdao/mips/tree/master/MIP8) |Domain Greenlight (Collateral Onboarding) | RFC | -| 9 | 2020-04-06 | [MIP9](https://github.com/makerdao/mips/tree/master/MIP9) |Community Greenlight (Collateral Onboarding) | RFC | -| 10 | 2020-04-06 | [MIP10](https://github.com/makerdao/mips/tree/master/MIP10) |Oracle Management | RFC | -| 11 | 2020-04-06 | [MIP11](https://github.com/makerdao/mips/tree/master/MIP11) |General Risk Model Management (Collateral Onboarding) | RFC | -| 12 | 2020-04-06 | [MIP12](https://github.com/makerdao/mips/tree/master/MIP12) |Collateral and Risk Parameter Management | RFC | - +| 0 | 2020-04-06 | [MIP0](https://github.com/makerdao/mips/tree/master/MIP0) |Maker Improvement Proposals Framework | Accepted | +| 1 | 2020-04-06 | [MIP1](https://github.com/makerdao/mips/tree/master/MIP1) |Maker Governance Paradigms | Accepted | +| 2 | 2020-04-06 | [MIP2](https://github.com/makerdao/mips/tree/master/MIP2) |Launch Period | Accepted | +| 3 | 2020-04-06 | [MIP3](https://github.com/makerdao/mips/tree/master/MIP3) |Governance Cycle | Accepted | +| 4 | 2020-04-06 | [MIP4](https://github.com/makerdao/mips/tree/master/MIP4) |MIP Amendment and Removal Process | Accepted | +| 5 | 2020-04-06 | [MIP5](https://github.com/makerdao/mips/tree/master/MIP5) |Emergency Voting System | Accepted | +| 6 | 2020-04-06 | [MIP6](https://github.com/makerdao/mips/tree/master/MIP6) |Collateral Onboarding Form/Forum Template | Accepted | +| 7 | 2020-04-06 | [MIP7](https://github.com/makerdao/mips/tree/master/MIP7) |Domain Teams (Collateral Onboarding) | Accepted | +| 8 | 2020-04-06 | [MIP8](https://github.com/makerdao/mips/tree/master/MIP8) |Domain Greenlight (Collateral Onboarding) | Accepted | +| 9 | 2020-04-06 | [MIP9](https://github.com/makerdao/mips/tree/master/MIP9) |Community Greenlight (Collateral Onboarding) | Accepted | +| 10 | 2020-04-06 | [MIP10](https://github.com/makerdao/mips/tree/master/MIP10) |Oracle Management | Accepted | +| 11 | 2020-04-06 | [MIP11](https://github.com/makerdao/mips/tree/master/MIP11) |General Risk Model Management (Collateral Onboarding) | Accepted | +| 12 | 2020-04-06 | [MIP12](https://github.com/makerdao/mips/tree/master/MIP12) |Collateral and Risk Parameter Management | Accepted | + +## Active MIPs Sets + +### Core Governance Framework + + +|MIP № |Date Ratified | Proposal Link |Description/Title +|------|--------------|-----------------------------------|---------------------------------------------------| +| 1 | 2020-05-02 | [MIP1](https://github.com/makerdao/mips/tree/master/MIP1) |Maker Governance Paradigms | +| 2 | 2020-05-02 | [MIP2](https://github.com/makerdao/mips/tree/master/MIP2) |Launch Period | +| 3 | 2020-05-02 | [MIP3](https://github.com/makerdao/mips/tree/master/MIP3) |Governance Cycle | +| 4 | 2020-05-02 | [MIP4](https://github.com/makerdao/mips/tree/master/MIP4) |MIP Amendment and Removal Process | +| 5 | 2020-05-02 | [MIP5](https://github.com/makerdao/mips/tree/master/MIP5) |Emergency Voting System | + + +### Collateral Onboarding Framework + + +|MIP № |Date Ratified | Proposal Link |Description/Title +|------|--------------|-----------------------------------|---------------------------------------------------| +| 6 | 2020-05-02 | [MIP6](https://github.com/makerdao/mips/tree/master/MIP6) |Collateral Onboarding Form/Forum Template | +| 7 | 2020-05-02 | [MIP7](https://github.com/makerdao/mips/tree/master/MIP7) |Domain Teams (Collateral Onboarding) | +| 8 | 2020-05-02 | [MIP8](https://github.com/makerdao/mips/tree/master/MIP8) |Domain Greenlight (Collateral Onboarding)| +| 9 | 2020-05-02 | [MIP9](https://github.com/makerdao/mips/tree/master/MIP9) |Community Greenlight (Collateral Onboarding) | +| 10 | 2020-05-02 | [MIP10](https://github.com/makerdao/mips/tree/master/MIP10) |Oracle Management | +| 11 | 2020-05-02 | [MIP11](https://github.com/makerdao/mips/tree/master/MIP11) |General Risk Model Management (Collateral Onboarding) | +| 12 | 2020-05-02 | [MIP12](https://github.com/makerdao/mips/tree/master/MIP12) |Collateral and Risk Parameter Management | ## Join the conversation