From 246e0f117efce36baa14c82ef2157041e9c4e493 Mon Sep 17 00:00:00 2001 From: LongForWisdom Date: Mon, 4 May 2020 01:43:23 +0100 Subject: [PATCH 01/50] Created MIP0c13-SP2 to onboard myself as Governance Facilitator. --- MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md | 54 ++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md diff --git a/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md b/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md new file mode 100644 index 000000000..86c9419f8 --- /dev/null +++ b/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md @@ -0,0 +1,54 @@ +# MIP0c13-SP2: Subproposal for Core Personnel Onboarding (Governance Facilitator) + +## Preamble +``` +MIP0c13-SP#: 2 +Author: LongForWisdom +Contributors: n/a +Status: Conception +Date Applied: 2020-05-04 +Date Ratified: +--- +Core Personnel Role: Governance Facilitator +Proposed applicant: LongForWisdom +``` + +## Application Form + +### Motivation + +My first impressions of this when Rich suggested it were ‘your job is horrible, why would I want to do it?’ That said, there are some fairly compelling reasons why I feel like I should do it. +- It’s a concrete step towards decentralization of the DAO. +- Rich is overworked, and is often not able to give the role his full attention (though to be fair, he does a great job of balancing it with his other responsibilities.) Having a second facilitator should help to increase coverage. +- At this stage, there don’t appear to be viable alternative candidates (this is not meant to throw shade on anyone/everyone, if you disagree, please make yourself known.) + +The plan has always been to have multiple facilitators sharing the work and representing different geographic groups. My hope is that we can get there as quickly as possible, but ultimately someone has to be first. + +So, with all this in mind, I’d be willing to take the role, if you’ll all have me. Once we have other Facilitators in place, I may re-evaluate and either decide to step down or aim to move into a different role. + +To mitigate slightly the whole 'this job is horrible' thing above: that's a rather over-exaggerated view. I expect to enjoy the role in the general case (or I wouldn't be agreeing to it), and I am completely happy to take on the responsibility for the foreseeable future. + +### Credentials +- Long(ish) standing member of the MakerDAO community. +- Started several initiatives with the aim to improve the long-term prospects of MakerDAO. + - [Producing a Collateral Onboarding Document](https://forum.makerdao.com/t/governance-initiative-collateral-on-boarding-process/1344) + - [Bringing SourceCred to Maker for a trial](https://forum.makerdao.com/t/governance-initiative-experimenting-with-sourcecred/1345) + - [Governance at a Glance](https://forum.makerdao.com/t/governance-at-a-glance/84) + - [Maintaining Forums](https://forum.makerdao.com/t/forum-navigation-index/648) + - [Governance Documentation](https://community-development.makerdao.com/governance/common-topics) + - [Collateral Status Index](https://forum.makerdao.com/t/collateral-status-index/2231) + - [Signal Requests](https://forum.makerdao.com/t/meta-governance-signal-requests/55) + +- Worked on several initiatives meant to improve the long-term prospects of MakerDAO. + - [Project Managing Mkrgov.science](https://forum.makerdao.com/t/governance-initiative-maker-governance-analytics-dashboard/1346) + - [Cleaning up Executive Audit documentation](https://community-development.makerdao.com/governance/executive-audit) + - [The MIPs Framework](https://github.com/LongForWisdom/mips) + +- This thread produced by current governance facilitator Rich Brown: https://forum.makerdao.com/t/its-time-for-a-second-governance-facilitator/1998 + +### Relevant Information +- GitHub Account: [@LongForWisdom](https://github.com/LongForWisdom) +- MakerDAO Forum Account: [@LongForWisdom](https://forum.makerdao.com/u/longforwisdom/) +- Reddit Account: [@LongForWisdom](https://www.reddit.com/user/LongForWisdom) + +--- \ No newline at end of file From 212c6bb52f593fc320c2fa1df3b4f23c17c32d0b Mon Sep 17 00:00:00 2001 From: LongForWisdom Date: Mon, 4 May 2020 01:44:50 +0100 Subject: [PATCH 02/50] Added horizontal lines. --- MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md b/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md index 86c9419f8..45d5ac72e 100644 --- a/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md +++ b/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md @@ -28,6 +28,8 @@ So, with all this in mind, I’d be willing to take the role, if you’ll all ha To mitigate slightly the whole 'this job is horrible' thing above: that's a rather over-exaggerated view. I expect to enjoy the role in the general case (or I wouldn't be agreeing to it), and I am completely happy to take on the responsibility for the foreseeable future. +--- + ### Credentials - Long(ish) standing member of the MakerDAO community. - Started several initiatives with the aim to improve the long-term prospects of MakerDAO. @@ -46,6 +48,8 @@ To mitigate slightly the whole 'this job is horrible' thing above: that's a rath - This thread produced by current governance facilitator Rich Brown: https://forum.makerdao.com/t/its-time-for-a-second-governance-facilitator/1998 +--- + ### Relevant Information - GitHub Account: [@LongForWisdom](https://github.com/LongForWisdom) - MakerDAO Forum Account: [@LongForWisdom](https://forum.makerdao.com/u/longforwisdom/) From 3617ca0d09e4e89f681daa57bd0d5fa89402667c Mon Sep 17 00:00:00 2001 From: LongForWisdom Date: Mon, 4 May 2020 01:48:51 +0100 Subject: [PATCH 03/50] Fixed component numbering (stupid git branches) --- .../MIP0c13-SP2.md => MIP0c12-Subproposals/MIP0c12-SP2.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename MIP0/{MIP0c13-Subproposals/MIP0c13-SP2.md => MIP0c12-Subproposals/MIP0c12-SP2.md} (97%) diff --git a/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md similarity index 97% rename from MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md rename to MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md index 45d5ac72e..003cf2888 100644 --- a/MIP0/MIP0c13-Subproposals/MIP0c13-SP2.md +++ b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md @@ -1,8 +1,8 @@ -# MIP0c13-SP2: Subproposal for Core Personnel Onboarding (Governance Facilitator) +# MIP0c12-SP2: Subproposal for Core Personnel Onboarding (Governance Facilitator) ## Preamble ``` -MIP0c13-SP#: 2 +MIP0c12-SP#: 2 Author: LongForWisdom Contributors: n/a Status: Conception From 2363f49cd9c9f20e625cd0ea970be1f407978ce8 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Mon, 4 May 2020 00:46:20 -0400 Subject: [PATCH 04/50] Update status of MIP0c12-SP2 to RFC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Approved by the MIP Editor 👍 --- MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md index 003cf2888..06e36b421 100644 --- a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md +++ b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md @@ -5,7 +5,7 @@ MIP0c12-SP#: 2 Author: LongForWisdom Contributors: n/a -Status: Conception +Status: Request for Comments (RFC) Date Applied: 2020-05-04 Date Ratified: --- @@ -55,4 +55,4 @@ To mitigate slightly the whole 'this job is horrible' thing above: that's a rath - MakerDAO Forum Account: [@LongForWisdom](https://forum.makerdao.com/u/longforwisdom/) - Reddit Account: [@LongForWisdom](https://www.reddit.com/user/LongForWisdom) ---- \ No newline at end of file +--- From 9df381b8c5b1388f174deea3b8392d4827239422 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Tue, 5 May 2020 12:31:40 -0400 Subject: [PATCH 05/50] Update status of MIP0c12-SP2 --- MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md index 06e36b421..cdd8eda59 100644 --- a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md +++ b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md @@ -5,7 +5,7 @@ MIP0c12-SP#: 2 Author: LongForWisdom Contributors: n/a -Status: Request for Comments (RFC) +Status: Formal Submission Date Applied: 2020-05-04 Date Ratified: --- From 04b11c7c9ced4d57184bd69810bf918dc19a143f Mon Sep 17 00:00:00 2001 From: LongForWisdom Date: Wed, 6 May 2020 18:05:35 +0100 Subject: [PATCH 06/50] Declarations of Intent MIP. First-draft(ish, lost some history due to my screwing around with branches.) --- MIPX/MIPXc3-Subproposal-Template.md | 33 +++++ MIPX/MIPXc3-Subproposals/placeholder.md | 1 + MIPX/MIPXc4-Subproposal-Template.md | 22 +++ MIPX/MIPXc4-Subproposals/placeholder.md | 1 + MIPX/MIPXc5-Subproposal-Template.md | 35 +++++ MIPX/MIPXc5-Subproposals/placeholder.md | 1 + MIPX/mipX.md | 177 ++++++++++++++++++++++++ 7 files changed, 270 insertions(+) create mode 100644 MIPX/MIPXc3-Subproposal-Template.md create mode 100644 MIPX/MIPXc3-Subproposals/placeholder.md create mode 100644 MIPX/MIPXc4-Subproposal-Template.md create mode 100644 MIPX/MIPXc4-Subproposals/placeholder.md create mode 100644 MIPX/MIPXc5-Subproposal-Template.md create mode 100644 MIPX/MIPXc5-Subproposals/placeholder.md create mode 100644 MIPX/mipX.md diff --git a/MIPX/MIPXc3-Subproposal-Template.md b/MIPX/MIPXc3-Subproposal-Template.md new file mode 100644 index 000000000..30929cba6 --- /dev/null +++ b/MIPX/MIPXc3-Subproposal-Template.md @@ -0,0 +1,33 @@ +# MIPXc3: Subproposal Template for Declaration of Intent + +## Preamble +``` +MIPXc3-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: +Date Ratified: +--- +Declaration Statement: +Declaration to Replace: MIPXc3-SP# or n/a +Bounty: +``` +## Specification + +### Context and Motivation + +- Why is this statment of intent being proposed? + +### Declaration Detail + +- As clear a description as possible of the intent that Maker Governance wishes to declare. +- How flexible is this intent in terms of implementation? + +### Justification of Bounty Amount + +- Why has this declaration been given the bounty it has? + +### Relevant Links + +- Forum Discussions, etc diff --git a/MIPX/MIPXc3-Subproposals/placeholder.md b/MIPX/MIPXc3-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIPX/MIPXc3-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIPX/MIPXc4-Subproposal-Template.md b/MIPX/MIPXc4-Subproposal-Template.md new file mode 100644 index 000000000..431eda9f2 --- /dev/null +++ b/MIPX/MIPXc4-Subproposal-Template.md @@ -0,0 +1,22 @@ +# MIPXc4: Subproposal Template for Revocation of Intent + +## Preamble +``` +MIPXc4-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: +Date Ratified: +--- +Declaration to Revoke: MIPXc3-SP# +``` +## Specification + +### Context and Motivation + +- Why is this statment of intent being revoked? + +### Relevant Links + +- Forum Discussions, etc diff --git a/MIPX/MIPXc4-Subproposals/placeholder.md b/MIPX/MIPXc4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIPX/MIPXc4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIPX/MIPXc5-Subproposal-Template.md b/MIPX/MIPXc5-Subproposal-Template.md new file mode 100644 index 000000000..5a317aab6 --- /dev/null +++ b/MIPX/MIPXc5-Subproposal-Template.md @@ -0,0 +1,35 @@ +# MIPXc5: Subproposal Template for Acceptance of Work + +## Preamble +``` +MIPXc5-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: +Date Ratified: +--- +Declaration to Fulfil: MIPXc3-SP# +``` +## Specification + +### Description of Implemented Work +- Describe the implementation, and how it fulfils the linked Declaration of Intent. + +### Bounty Dispensation +- How should the bounty be distributed? +- CLEARLY list any addresses and the amount of DAI to be distributed to each. The total amount should not exceed the bounty listed on the declaration of intent that has been fulfilled. + +### Relevant Information +- Links to evidence that proves the fulfilment of the intent. + +### Proposed Executive Code +The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team when the executive spell is written. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. + +``` +VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * daiAmountToTransfer); +VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer, daiAmountToTransfer); +``` + +This template can be used by a Smart Contracts domain team as many times as necessary (once per target address.) Variables `targetAddressToTransfer` and `daiAmountToTransfer` should be modified according to the Bounty Dispensation section above. \ No newline at end of file diff --git a/MIPX/MIPXc5-Subproposals/placeholder.md b/MIPX/MIPXc5-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIPX/MIPXc5-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIPX/mipX.md b/MIPX/mipX.md new file mode 100644 index 000000000..7a457035a --- /dev/null +++ b/MIPX/mipX.md @@ -0,0 +1,177 @@ +# MIPX: Declarations of Intent + +## Preamble +``` +MIP#: X +Title: Declarations of Intent +Author(s): @LongForWisdom +Contributors: n/a +Type: Process +Status: +Date Proposed: +Date Ratified: +Dependencies: MIP0 +Replaces: n/a +``` +## References +**[MIPXc3-Subproposal-Template.md](MIPXc3-Subproposal-Template.md)** +**[MIPXc4-Subproposal-Template.md](MIPXc4-Subproposal-Template.md)** +**[MIPXc5-Subproposal-Template.md](MIPXc5-Subproposal-Template.md)** + +## Sentence Summary + +MIPX introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help convert that intention into reality. + +## Paragraph Summary + +MIPX introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help make that intention into reality. MIPX defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. Additionally, Maker Governance is able to optionally attach bounties to these declarations in order to incentivise actors to work on making them a reality. + +## Component Summary + +**MIPXc1: What is a Declaration of Intent?** +Describes the desireable properties of a Declaration of Intent, and the considerations that should be made when creating or modifying one. + +**MIPXc2: List of Active Declarations** +A list component which contains a list of the currently active declarations of intent. + +**MIPXc3: Declaration of Intent Process** +A process component that allows Maker Governance to create, replace or amend-through-replace a declaration of intent. + +**MIPXc4: Revocation of Intent Process** +A process component that allows Maker Governance to revoke a declaration of intent. + +**MIPXc5: Acceptance of Work Process** +A process component that allows Maker Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. + +**MIPXc6: Considerations for Bounty Hunters** +Lays out a set of considerations for Bounty Hunters that wish to earn bounties through working on declared intents. + +## Motivation + +MIPX is designed to formalize and expand on a pattern of behavior that has appeared consistently in the Maker Governance community. This pattern of behaviour tends to look like this: +1. Recognise that something should be done. +2. Discuss the problem. +3. Vote in some form to ensure that a majority wants to do something. +4. Hope someone does the thing. + +We've seen this pattern come up multiple times, across multiple different subjects. Three examples that come to mind are: +1. The shutdown of SCD. +2. The introduction of ranked on-chain voting. +3. Compensation of vaults that lost money on Black Thursday. + +In each of these cases, there was no formal record of the declaration of intent beyond an on-chain poll and the various forum threads that led to the decision. By formalizing this process in MIPs, anyone wishing to interact with Maker Governance can easily discover what has been agreed on various topics in one place. In addition there will be a record of when each declaration took place, and the described reasons for it to have been declared. + +The inclusion of bounties helps to deal directly with point 4 listed above, in that after Maker Governance declares the intent to do something (regards of the method used to do so), it is currently unable to incentivise that thing to take place without relying in some way on the Maker Foundation. + + +## Specification / Proposal Details + +### MIPXc1: What is a Declaration of Intent? + +**Definition** + +A declaration of intent is a statement that declares an intention Maker Governance has to the wider ecosystem. Such declarations should be made with the aim of prompting action in a certain area. + +There may be other ways to use 'Declarations' outside of intention, this system could be generalized to declaring other concepts, such as beliefs, or goals. However, based on the principles of specificity and brevity, it is suggested that these variations are defined as separate MIPs if they are determined to be needed. + +**Specificity** + +Declarations should be worded carefully to capture the intention of Maker Governance as precisely as possible, however, that does not mean that declarations *must* always be specific and precise. + +There may be times when Maker Governance does not care about the implementation details used to solve a problem, only that the problem is solved. There may also be times where Maker Governance has already discussed possible solutions to a problem and already aligned on an implementation to a point where they would accept *only that specific implementation.* + +Declarations of both types (and anything inbetween) should be considered legitimate, but Maker Governance should take care to make it clear where each declaration lies on the scale between these two extremes. + +**With relation to bounties** + +While it's perfectly acceptable to declare intent in vague terms, it is suggested that Governance consider the vagueness of the declaration as a factor when determining if a bounty is released. Vague intentions may result in implementations that match the intention as written, but are not what Maker Governance expected, this should not be used as an excuse to deny bounty payments. + +--- + +### MIPXc2: List of Active Declarations + +This list can be amended through subproposals created under MIPXc3, MIPXc4 and MIPXc5. + +**Entries into this list should follow the following template:** + +``` +Declaration Statement: +Sub-proposal Number: # +Date Ratified: (yyyy-mm-dd) +Bounty: +``` + +Note that the subproposal code should link to the relevant subproposal. + + +**Active Declarations List** +There are currently no active declarations. Below is an example declaration which should be removed (as should this paragraph) when the first ratified declaration is added to this list . + +``` +Declaration Statement: All Governance Facilitators should be given chocolate on the 30th of February each year. +Sub-proposal Number: MIPXc3-SP0 +Date Ratified: 2020-02-30 +Bounty: 1,000,000 DAI +``` + +--- + +### MIPXc3: Declaration of Intent Process +MIPXc3 is a Process MIP component that allows MKR Governance to create, replace or amend-through-replace a declaration of intent through a subproposal. + +Note that Declarations of Intent can be assigned bounties as part of this process. Bounties are always denominated and provided in DAI. + +If a declaration of intent is ratified through a MIPXc3 subproposal, it should be added to the MIPXc2 list by a MIP Editor. + +If the subproposal defines a declaration to be replaced then: +- That declaration should be removed from the MIPXc2 list by a MIP Editor +- The replaced declarations subproposal status should be changed to 'revoked' by a MIP Editor + +MIPXc3 subproposals have the following parameters: +- **Feedback Period**: 1 month +- **Frozen Period**: 1 week + +MIPXc3 subproposals must use the template located at **[MIPXc3-Subproposal-Template.md](MIPXc3-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. + +--- + +### MIPXc4: Revocation of Intent Process + +MIPXc4 is a Process MIP component that allows MKR Governance to revoke a declaration of intent through a subproposal. + +If a declaration of intent is revoked through a MIPXc4 subproposal then: +- That declaration should be removed from the MIPXc2 list by a MIP Editor. +- The revoked declarations subproposal status should be changed to 'revoked' by a MIP Editor + +MIPXc4 subproposals have the following parameters: +- **Feedback Period**: 1 month +- **Frozen Period**: 1 week + +MIPXc4 subproposals must use the template located at **[MIPXc4-Subproposal-Template.md](MIPXc4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. + +--- + +### MIPXc5: Acceptance of Work Process +MIPXc5 is a Process MIP component that allows MKR Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. Note that MIPXc5 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to the producer(s) of the accepted work. + +If work is accepted that fulfils a declared intention then: +- The fulfilled declaration should be removed from the MIPXc2 list by a MIP Editor. +- The fulfilled declarations subproposal status should be changed to 'fulfilled' by a MIP Editor. + +MIPXc5 subproposals have the following parameters: +- **Feedback Period**: 1 month +- **Frozen Period**: 1 week + +MIPXc5 subproposals must use the template located at **[MIPXc5-Subproposal-Template.md](MIPXc5-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. The 'Proposed Executive Code' section of this template should be left unchanged by subproposal authors. + +--- + +### MIPXc6: Considerations for Bounty Hunters +This component is included to provided guidance to Bounty Hunters that wish to fulfil declared intentions and recieve DAI as bounty. + +1. Payment is contingent on demonstrating to Maker Governance that the intention has been satisfied. +2. Once the work has been completed, the party responsible for the work should submit a MIPXc5 subproposal to claim the bounty. +3. Work with Maker Governance as much as possible for each step of the process, make sure that you have a full understanding of the intention described in the declaration of intent subproposal. +4. If you are worried that a specific declaration of intent is confusing, ambiguous, or otherwise badly formed, please communicate this before starting work. +5. If a declaration of intent is quite old, consider reaching out to Maker Governance to enquire as to whether it is still valid before starting work. This may prompt a new declaration of intent in the case intentions have changed. +6. Due to the way the Governance Cycle operates, payment for completed bounties may be delayed for several months in the worst case. From c3ed02af8854537fd3df379774ee66cc9ed342d1 Mon Sep 17 00:00:00 2001 From: LongForWisdom Date: Mon, 11 May 2020 15:34:06 +0100 Subject: [PATCH 07/50] First draft, Protocol DAI Transfer MIP. --- MIPX/MIPXc2-Subproposal-Template.md | 51 ++++++++++++ MIPX/MIPXc2-Subproposals/placeholder.md | 1 + MIPX/mipX.md | 106 ++++++++++++++++++++++++ 3 files changed, 158 insertions(+) create mode 100644 MIPX/MIPXc2-Subproposal-Template.md create mode 100644 MIPX/MIPXc2-Subproposals/placeholder.md create mode 100644 MIPX/mipX.md diff --git a/MIPX/MIPXc2-Subproposal-Template.md b/MIPX/MIPXc2-Subproposal-Template.md new file mode 100644 index 000000000..0044b1d62 --- /dev/null +++ b/MIPX/MIPXc2-Subproposal-Template.md @@ -0,0 +1,51 @@ +# MIPXc2: Subproposal for Protocol DAI Transfer + +## Preamble +``` +MIPXc2-SP: # +Title: +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date ratified: <yyyy-mm-dd> +--- +Amount: +``` + +## Specification + +### Sentence Reason + +- A one sentence reason of why DAI is being transferred from the protocol. + +### Reason Details + +- More details regarding the reason for the Protocol DAI Transfer. + +### Targets + +- Clearly listed target addresses with matching amounts in the format: +``` +Recipient Address: 0x0000000000000000000000000000000000000000 +Amount To Transfer: 0 DAI +``` +- Combined amount of DAI should not be higher than the Amount specified in the Preamble. + +### Relevant Information: + +- Links to discussion, evidence or anything related to the transfer. + +### Proposed Executive Code +The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team writing the executive spell. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. + +``` +VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); +VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * totalDaiAmountToTransfer); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer1, daiAmountToTransfer1); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer2, daiAmountToTransfer2); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer3, daiAmountToTransfer3); +... +``` + +Variables totalDaiAmountToTransfer, targetAddressToTransfer and daiAmountToTransfer should be modified according to the Amount and Targets section above. \ No newline at end of file diff --git a/MIPX/MIPXc2-Subproposals/placeholder.md b/MIPX/MIPXc2-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIPX/MIPXc2-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIPX/mipX.md b/MIPX/mipX.md new file mode 100644 index 000000000..7ce355647 --- /dev/null +++ b/MIPX/mipX.md @@ -0,0 +1,106 @@ +# Protocol DAI Transfer + +## Preamble +``` +MIP#: X +Title: Protocol DAI Transfer +Author(s): @LongForWisdom +Contributors: N/A +Type: Process +Status: <Assigned by MIP Editor> +Date Proposed: <yyyy-mm-dd> +Date Ratified: <yyyy-mm-dd> +Dependencies: MIP0 +Replaces: N/A +``` +## References +**[MIPXc2-Subproposal-Template.md](MIPXc2-Subproposal-Template.md)** + +## Sentence Summary + +MIPX defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. + +## Paragraph Summary + +MIPX defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so. + +## Component Summary + +**MIPXc1: Considerations Regarding Protocol DAI Transfers** +A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIPXc2. + +**MIPXc2: Protocol DAI Transfer Process** +A process component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. + +**MIPXc3: Protocol DAI Transfer List** +A list component that lists the previous direct DAI transfers that have been made by the protocol in the past. + + +## Motivation + +Giving governance the ability to use the value generated by the Maker Protocol is beneficial for two main reasons: +- It allows Maker Governance to incentivise actions taken to improve the protocol. +- It reduces Maker Governance's reliance on the Maker Foundation. + +Both of these should be seen as beneficial for fairly obvious reasons. Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future. + +## Specification / Proposal Details + +**MIPXc1: Considerations Regarding Protocol DAI Transfers** +There are several important considerations to take into account before transferring value out of the Maker Protocol. +- Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation. +- Transfer of DAI from the protocol will take DAI from the surplus buffer if available. +- Transfer of DAI from the protocol will create bad debt and trigger FLOP auctions after the Debt auction delay (wait parameter) if there is not sufficient DAI available in the surplus buffer. +- If there is a more specific process MIP that allows DAI transfers that is more appropriate to the use case, use that process instead. + +--- + +**MIPXc2: Protocol DAI Transfer Process** +MIPXc2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIPXc2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses. + +If a MIPXc2 subproposal is Accepted, The DAI Transfer is appended to the list in MIPXc3 by a MIP Editor. + +MIPXc2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: + +**< 10,000 DAI Transfer** +- **Feedback Period:** 0 days +- **Frozen period:** 0 days + +**10,000 - 100,000 DAI Transfer** +- **Feedback Period:** 4 weeks +- **Frozen period:** 1 week + +**> 100,000 DAI Transfer** +- **Feedback Period:** 12 weeks +- **Frozen period:** 4 weeks + +MIPXc2 subproposals must use the template located at **[MIPXc2-Subproposal-Template.md](MIPXc2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + +--- + +**MIPXc3: Protocol DAI Transfer List** +This list can be amended through subproposals created under MIPXc2. + +**List Entry Template** +Entries into this list should follow the following template: + +``` +Reason: +Sub-proposal Number: # +Date Ratified: (yyyy-mm-dd) +Amount Transferred: +Recipient Address: +``` + +**Historical Transfer List** +There are currently no historical transfers. Below is an example transfer which should be removed (as should this paragraph) when the first ratified transfer is added to this list . + +``` +Reason: Funding Chocolate for Governance Facilitators +Sub-proposal Number: MIPXc1-SP0 +Date Ratified: 2020-02-30 +Amount Transferred: 1,000,000 DAI +Recipient Address: 0x0000000000000000000000000000000000000000 +``` + +--- From d69481a274edae02f03576e6c031b5e8168a8729 Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Tue, 12 May 2020 14:23:20 +0100 Subject: [PATCH 08/50] Updated Feedback and Frozen periods to be denominated in 'full weeks' after discussion with Charles as to the best convention to follow. --- MIPX/mipX.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/MIPX/mipX.md b/MIPX/mipX.md index 7ce355647..1f339e4aa 100644 --- a/MIPX/mipX.md +++ b/MIPX/mipX.md @@ -63,16 +63,16 @@ If a MIPXc2 subproposal is Accepted, The DAI Transfer is appended to the list in MIPXc2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: **< 10,000 DAI Transfer** -- **Feedback Period:** 0 days -- **Frozen period:** 0 days +- **Feedback Period:** 0 full weeks +- **Frozen period:** 0 full weeks **10,000 - 100,000 DAI Transfer** -- **Feedback Period:** 4 weeks -- **Frozen period:** 1 week +- **Feedback Period:** 4 full weeks +- **Frozen period:** 1 full week **> 100,000 DAI Transfer** -- **Feedback Period:** 12 weeks -- **Frozen period:** 4 weeks +- **Feedback Period:** 12 full weeks +- **Frozen period:** 4 full weeks MIPXc2 subproposals must use the template located at **[MIPXc2-Subproposal-Template.md](MIPXc2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. From 750bee174d22d063cfeb58a9dcf500bf30911554 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 14 May 2020 10:58:24 -0400 Subject: [PATCH 09/50] Add MIP Number and edit proposal --- MIPX/mipX.md | 78 ++++++++++++++++++++++++++-------------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/MIPX/mipX.md b/MIPX/mipX.md index 7a457035a..8ecc9243d 100644 --- a/MIPX/mipX.md +++ b/MIPX/mipX.md @@ -1,54 +1,54 @@ -# MIPX: Declarations of Intent +# MIP13: Declarations of Intent ## Preamble ``` -MIP#: X +MIP#: 13 Title: Declarations of Intent Author(s): @LongForWisdom Contributors: n/a Type: Process -Status: <Assigned by MIP Editor> -Date Proposed: <yyyy-mm-dd> +Status: Request for Comments (RFC) +Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 Replaces: n/a ``` ## References -**[MIPXc3-Subproposal-Template.md](MIPXc3-Subproposal-Template.md)** -**[MIPXc4-Subproposal-Template.md](MIPXc4-Subproposal-Template.md)** -**[MIPXc5-Subproposal-Template.md](MIPXc5-Subproposal-Template.md)** +**[MIP13c3-Subproposal-Template.md](MIP13c3-Subproposal-Template.md)** +**[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)** +**[MIP13c5-Subproposal-Template.md](MIP13c5-Subproposal-Template.md)** ## Sentence Summary -MIPX introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help convert that intention into reality. +MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help convert that intention into reality. ## Paragraph Summary -MIPX introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help make that intention into reality. MIPX defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. Additionally, Maker Governance is able to optionally attach bounties to these declarations in order to incentivise actors to work on making them a reality. +MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help make that intention into reality. MIP13 defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. Additionally, Maker Governance is able to optionally attach bounties to these declarations in order to incentivise actors to work on making them a reality. ## Component Summary -**MIPXc1: What is a Declaration of Intent?** +**MIP13c1: What is a Declaration of Intent?** Describes the desireable properties of a Declaration of Intent, and the considerations that should be made when creating or modifying one. -**MIPXc2: List of Active Declarations** +**MIP13c2: List of Active Declarations** A list component which contains a list of the currently active declarations of intent. -**MIPXc3: Declaration of Intent Process** +**MIP13c3: Declaration of Intent Process** A process component that allows Maker Governance to create, replace or amend-through-replace a declaration of intent. -**MIPXc4: Revocation of Intent Process** +**MIP13c4: Revocation of Intent Process** A process component that allows Maker Governance to revoke a declaration of intent. -**MIPXc5: Acceptance of Work Process** +**MIP13c5: Acceptance of Work Process** A process component that allows Maker Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. -**MIPXc6: Considerations for Bounty Hunters** +**MIP13c6: Considerations for Bounty Hunters** Lays out a set of considerations for Bounty Hunters that wish to earn bounties through working on declared intents. ## Motivation -MIPX is designed to formalize and expand on a pattern of behavior that has appeared consistently in the Maker Governance community. This pattern of behaviour tends to look like this: +MIP13 is designed to formalize and expand on a pattern of behavior that has appeared consistently in the Maker Governance community. This pattern of behaviour tends to look like this: 1. Recognise that something should be done. 2. Discuss the problem. 3. Vote in some form to ensure that a majority wants to do something. @@ -66,7 +66,7 @@ The inclusion of bounties helps to deal directly with point 4 listed above, in t ## Specification / Proposal Details -### MIPXc1: What is a Declaration of Intent? +### MIP13c1: What is a Declaration of Intent? **Definition** @@ -88,9 +88,9 @@ While it's perfectly acceptable to declare intent in vague terms, it is suggeste --- -### MIPXc2: List of Active Declarations +### MIP13c2: List of Active Declarations -This list can be amended through subproposals created under MIPXc3, MIPXc4 and MIPXc5. +This list can be amended through subproposals created under MIP13c3, MIP13c4 and MIP13c5. **Entries into this list should follow the following template:** @@ -109,68 +109,68 @@ There are currently no active declarations. Below is an example declaration whic ``` Declaration Statement: All Governance Facilitators should be given chocolate on the 30th of February each year. -Sub-proposal Number: MIPXc3-SP0 +Sub-proposal Number: MIP13c3-SP0 Date Ratified: 2020-02-30 Bounty: 1,000,000 DAI ``` --- -### MIPXc3: Declaration of Intent Process -MIPXc3 is a Process MIP component that allows MKR Governance to create, replace or amend-through-replace a declaration of intent through a subproposal. +### MIP13c3: Declaration of Intent Process +MIP13c3 is a Process MIP component that allows MKR Governance to create, replace or amend-through-replace a declaration of intent through a subproposal. Note that Declarations of Intent can be assigned bounties as part of this process. Bounties are always denominated and provided in DAI. -If a declaration of intent is ratified through a MIPXc3 subproposal, it should be added to the MIPXc2 list by a MIP Editor. +If a declaration of intent is ratified through a MIP13c3 subproposal, it should be added to the MIP13c2 list by a MIP Editor. If the subproposal defines a declaration to be replaced then: -- That declaration should be removed from the MIPXc2 list by a MIP Editor +- That declaration should be removed from the MIP13c2 list by a MIP Editor - The replaced declarations subproposal status should be changed to 'revoked' by a MIP Editor -MIPXc3 subproposals have the following parameters: +MIP13c3 subproposals have the following parameters: - **Feedback Period**: 1 month - **Frozen Period**: 1 week -MIPXc3 subproposals must use the template located at **[MIPXc3-Subproposal-Template.md](MIPXc3-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. +MIP13c3 subproposals must use the template located at **[MIP13c3-Subproposal-Template.md](MIP13c3-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. --- -### MIPXc4: Revocation of Intent Process +### MIP13c4: Revocation of Intent Process -MIPXc4 is a Process MIP component that allows MKR Governance to revoke a declaration of intent through a subproposal. +MIP13c4 is a Process MIP component that allows MKR Governance to revoke a declaration of intent through a subproposal. -If a declaration of intent is revoked through a MIPXc4 subproposal then: -- That declaration should be removed from the MIPXc2 list by a MIP Editor. +If a declaration of intent is revoked through a MIP13c4 subproposal then: +- That declaration should be removed from the MIP13c2 list by a MIP Editor. - The revoked declarations subproposal status should be changed to 'revoked' by a MIP Editor -MIPXc4 subproposals have the following parameters: +MIP13c4 subproposals have the following parameters: - **Feedback Period**: 1 month - **Frozen Period**: 1 week -MIPXc4 subproposals must use the template located at **[MIPXc4-Subproposal-Template.md](MIPXc4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. +MIP13c4 subproposals must use the template located at **[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. --- -### MIPXc5: Acceptance of Work Process -MIPXc5 is a Process MIP component that allows MKR Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. Note that MIPXc5 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to the producer(s) of the accepted work. +### MIP13c5: Acceptance of Work Process +MIP13c5 is a Process MIP component that allows MKR Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. Note that MIP13c5 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to the producer(s) of the accepted work. If work is accepted that fulfils a declared intention then: -- The fulfilled declaration should be removed from the MIPXc2 list by a MIP Editor. +- The fulfilled declaration should be removed from the MIP13c2 list by a MIP Editor. - The fulfilled declarations subproposal status should be changed to 'fulfilled' by a MIP Editor. -MIPXc5 subproposals have the following parameters: +MIP13c5 subproposals have the following parameters: - **Feedback Period**: 1 month - **Frozen Period**: 1 week -MIPXc5 subproposals must use the template located at **[MIPXc5-Subproposal-Template.md](MIPXc5-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. The 'Proposed Executive Code' section of this template should be left unchanged by subproposal authors. +MIP13c5 subproposals must use the template located at **[MIP13c5-Subproposal-Template.md](MIP13c5-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. The 'Proposed Executive Code' section of this template should be left unchanged by subproposal authors. --- -### MIPXc6: Considerations for Bounty Hunters +### MIP13c6: Considerations for Bounty Hunters This component is included to provided guidance to Bounty Hunters that wish to fulfil declared intentions and recieve DAI as bounty. 1. Payment is contingent on demonstrating to Maker Governance that the intention has been satisfied. -2. Once the work has been completed, the party responsible for the work should submit a MIPXc5 subproposal to claim the bounty. +2. Once the work has been completed, the party responsible for the work should submit a MIP13c5 subproposal to claim the bounty. 3. Work with Maker Governance as much as possible for each step of the process, make sure that you have a full understanding of the intention described in the declaration of intent subproposal. 4. If you are worried that a specific declaration of intent is confusing, ambiguous, or otherwise badly formed, please communicate this before starting work. 5. If a declaration of intent is quite old, consider reaching out to Maker Governance to enquire as to whether it is still valid before starting work. This may prompt a new declaration of intent in the case intentions have changed. From 939dcca0a06138da0ebb8107bdd00a2706879a76 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 14 May 2020 11:00:30 -0400 Subject: [PATCH 10/50] Rename mipX to MIP13 --- MIPX/{mipX.md => MIP13.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename MIPX/{mipX.md => MIP13.md} (100%) diff --git a/MIPX/mipX.md b/MIPX/MIP13.md similarity index 100% rename from MIPX/mipX.md rename to MIPX/MIP13.md From 04207cd18863fa78cdcf2515c645100e997944a6 Mon Sep 17 00:00:00 2001 From: CPSTL <12cpsl@queensu.ca> Date: Thu, 14 May 2020 11:10:44 -0400 Subject: [PATCH 11/50] Update mipX to MIP13 throughout proposal components --- {MIPX => MIP13}/MIP13.md | 0 .../MIP13c3-Subproposal-Template.md | 6 +++--- .../MIP13c3-Subproposals}/placeholder.md | 0 .../MIP13c4-Subproposal-Template.md | 6 +++--- .../MIP13c4-Subproposals}/placeholder.md | 0 .../MIP13c5-Subproposal-Template.md | 6 +++--- .../MIP13c5-Subproposals}/placeholder.md | 0 7 files changed, 9 insertions(+), 9 deletions(-) rename {MIPX => MIP13}/MIP13.md (100%) rename MIPX/MIPXc3-Subproposal-Template.md => MIP13/MIP13c3-Subproposal-Template.md (82%) rename {MIPX/MIPXc3-Subproposals => MIP13/MIP13c3-Subproposals}/placeholder.md (100%) rename MIPX/MIPXc4-Subproposal-Template.md => MIP13/MIP13c4-Subproposal-Template.md (70%) rename {MIPX/MIPXc4-Subproposals => MIP13/MIP13c4-Subproposals}/placeholder.md (100%) rename MIPX/MIPXc5-Subproposal-Template.md => MIP13/MIP13c5-Subproposal-Template.md (93%) rename {MIPX/MIPXc5-Subproposals => MIP13/MIP13c5-Subproposals}/placeholder.md (100%) diff --git a/MIPX/MIP13.md b/MIP13/MIP13.md similarity index 100% rename from MIPX/MIP13.md rename to MIP13/MIP13.md diff --git a/MIPX/MIPXc3-Subproposal-Template.md b/MIP13/MIP13c3-Subproposal-Template.md similarity index 82% rename from MIPX/MIPXc3-Subproposal-Template.md rename to MIP13/MIP13c3-Subproposal-Template.md index 30929cba6..78563009f 100644 --- a/MIPX/MIPXc3-Subproposal-Template.md +++ b/MIP13/MIP13c3-Subproposal-Template.md @@ -1,8 +1,8 @@ -# MIPXc3: Subproposal Template for Declaration of Intent +# MIP13c3: Subproposal Template for Declaration of Intent ## Preamble ``` -MIPXc3-SP#: # +MIP13c3-SP#: # Author(s): Contributors: Status: @@ -10,7 +10,7 @@ Date Proposed: <yyyy-mm-dd> Date Ratified: <yyyy-mm-dd> --- Declaration Statement: -Declaration to Replace: MIPXc3-SP# or n/a +Declaration to Replace: MIP13c3-SP# or n/a Bounty: ``` ## Specification diff --git a/MIPX/MIPXc3-Subproposals/placeholder.md b/MIP13/MIP13c3-Subproposals/placeholder.md similarity index 100% rename from MIPX/MIPXc3-Subproposals/placeholder.md rename to MIP13/MIP13c3-Subproposals/placeholder.md diff --git a/MIPX/MIPXc4-Subproposal-Template.md b/MIP13/MIP13c4-Subproposal-Template.md similarity index 70% rename from MIPX/MIPXc4-Subproposal-Template.md rename to MIP13/MIP13c4-Subproposal-Template.md index 431eda9f2..3b583d3ad 100644 --- a/MIPX/MIPXc4-Subproposal-Template.md +++ b/MIP13/MIP13c4-Subproposal-Template.md @@ -1,15 +1,15 @@ -# MIPXc4: Subproposal Template for Revocation of Intent +# MIP13c4: Subproposal Template for Revocation of Intent ## Preamble ``` -MIPXc4-SP#: # +MIP13c4-SP#: # Author(s): Contributors: Status: Date Proposed: <yyyy-mm-dd> Date Ratified: <yyyy-mm-dd> --- -Declaration to Revoke: MIPXc3-SP# +Declaration to Revoke: MIP13c3-SP# ``` ## Specification diff --git a/MIPX/MIPXc4-Subproposals/placeholder.md b/MIP13/MIP13c4-Subproposals/placeholder.md similarity index 100% rename from MIPX/MIPXc4-Subproposals/placeholder.md rename to MIP13/MIP13c4-Subproposals/placeholder.md diff --git a/MIPX/MIPXc5-Subproposal-Template.md b/MIP13/MIP13c5-Subproposal-Template.md similarity index 93% rename from MIPX/MIPXc5-Subproposal-Template.md rename to MIP13/MIP13c5-Subproposal-Template.md index 5a317aab6..485346b69 100644 --- a/MIPX/MIPXc5-Subproposal-Template.md +++ b/MIP13/MIP13c5-Subproposal-Template.md @@ -1,15 +1,15 @@ -# MIPXc5: Subproposal Template for Acceptance of Work +# MIP13c5: Subproposal Template for Acceptance of Work ## Preamble ``` -MIPXc5-SP#: # +MIP13c5-SP#: # Author(s): Contributors: Status: Date Proposed: <yyyy-mm-dd> Date Ratified: <yyyy-mm-dd> --- -Declaration to Fulfil: MIPXc3-SP# +Declaration to Fulfil: MIP13c3-SP# ``` ## Specification diff --git a/MIPX/MIPXc5-Subproposals/placeholder.md b/MIP13/MIP13c5-Subproposals/placeholder.md similarity index 100% rename from MIPX/MIPXc5-Subproposals/placeholder.md rename to MIP13/MIP13c5-Subproposals/placeholder.md From 2e0f8927981349c81652c868394cb15962bd5c02 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 14 May 2020 11:16:39 -0400 Subject: [PATCH 12/50] Update mipx to MIP14 --- MIPX/{mipX.md => MIP14.md} | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) rename MIPX/{mipX.md => MIP14.md} (61%) diff --git a/MIPX/mipX.md b/MIPX/MIP14.md similarity index 61% rename from MIPX/mipX.md rename to MIPX/MIP14.md index 1f339e4aa..9df8a0462 100644 --- a/MIPX/mipX.md +++ b/MIPX/MIP14.md @@ -2,37 +2,37 @@ ## Preamble ``` -MIP#: X +MIP#: 14 Title: Protocol DAI Transfer Author(s): @LongForWisdom Contributors: N/A Type: Process -Status: <Assigned by MIP Editor> -Date Proposed: <yyyy-mm-dd> +Status: Approved by MIP Editor +Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 Replaces: N/A ``` ## References -**[MIPXc2-Subproposal-Template.md](MIPXc2-Subproposal-Template.md)** +**[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)** ## Sentence Summary -MIPX defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. +MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. ## Paragraph Summary -MIPX defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so. +MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so. ## Component Summary -**MIPXc1: Considerations Regarding Protocol DAI Transfers** -A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIPXc2. +**MIP14c1: Considerations Regarding Protocol DAI Transfers** +A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIP14c2. -**MIPXc2: Protocol DAI Transfer Process** +**MIP14c2: Protocol DAI Transfer Process** A process component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. -**MIPXc3: Protocol DAI Transfer List** +**MIP14c3: Protocol DAI Transfer List** A list component that lists the previous direct DAI transfers that have been made by the protocol in the past. @@ -46,7 +46,7 @@ Both of these should be seen as beneficial for fairly obvious reasons. Less reli ## Specification / Proposal Details -**MIPXc1: Considerations Regarding Protocol DAI Transfers** +**MIP14c1: Considerations Regarding Protocol DAI Transfers** There are several important considerations to take into account before transferring value out of the Maker Protocol. - Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation. - Transfer of DAI from the protocol will take DAI from the surplus buffer if available. @@ -55,12 +55,12 @@ There are several important considerations to take into account before transferr --- -**MIPXc2: Protocol DAI Transfer Process** -MIPXc2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIPXc2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses. +**MIP14c2: Protocol DAI Transfer Process** +MIP14c2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIP14c2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses. -If a MIPXc2 subproposal is Accepted, The DAI Transfer is appended to the list in MIPXc3 by a MIP Editor. +If a MIP14c2 subproposal is Accepted, The DAI Transfer is appended to the list in MIP14c3 by a MIP Editor. -MIPXc2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: +MIP14c2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: **< 10,000 DAI Transfer** - **Feedback Period:** 0 full weeks @@ -74,12 +74,12 @@ MIPXc2 subproposals have parameters that depend on the total amount of DAI to be - **Feedback Period:** 12 full weeks - **Frozen period:** 4 full weeks -MIPXc2 subproposals must use the template located at **[MIPXc2-Subproposal-Template.md](MIPXc2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. +MIP14c2 subproposals must use the template located at **[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. --- -**MIPXc3: Protocol DAI Transfer List** -This list can be amended through subproposals created under MIPXc2. +**MIP14c3: Protocol DAI Transfer List** +This list can be amended through subproposals created under MIP14c2. **List Entry Template** Entries into this list should follow the following template: @@ -97,7 +97,7 @@ There are currently no historical transfers. Below is an example transfer which ``` Reason: Funding Chocolate for Governance Facilitators -Sub-proposal Number: MIPXc1-SP0 +Sub-proposal Number: MIP14c1-SP0 Date Ratified: 2020-02-30 Amount Transferred: 1,000,000 DAI Recipient Address: 0x0000000000000000000000000000000000000000 From cd6fddc41b8d418aed9ae44f2afe17494eb00976 Mon Sep 17 00:00:00 2001 From: CPSTL <12cpsl@queensu.ca> Date: Thu, 14 May 2020 11:19:58 -0400 Subject: [PATCH 13/50] Update mipX to reflect newly assigned number (14) --- {MIPX => MIP14}/MIP14.md | 0 .../MIP14c2-Subproposal-Template.md | 4 ++-- .../MIP14c2-Subproposals}/placeholder.md | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename {MIPX => MIP14}/MIP14.md (100%) rename MIPX/MIPXc2-Subproposal-Template.md => MIP14/MIP14c2-Subproposal-Template.md (96%) rename {MIPX/MIPXc2-Subproposals => MIP14/MIP14c2-Subproposals}/placeholder.md (100%) diff --git a/MIPX/MIP14.md b/MIP14/MIP14.md similarity index 100% rename from MIPX/MIP14.md rename to MIP14/MIP14.md diff --git a/MIPX/MIPXc2-Subproposal-Template.md b/MIP14/MIP14c2-Subproposal-Template.md similarity index 96% rename from MIPX/MIPXc2-Subproposal-Template.md rename to MIP14/MIP14c2-Subproposal-Template.md index 0044b1d62..ebb6111c1 100644 --- a/MIPX/MIPXc2-Subproposal-Template.md +++ b/MIP14/MIP14c2-Subproposal-Template.md @@ -1,8 +1,8 @@ -# MIPXc2: Subproposal for Protocol DAI Transfer +# MIP14c2: Subproposal for Protocol DAI Transfer ## Preamble ``` -MIPXc2-SP: # +MIP14c2-SP: # Title: <Title> Author(s): Contributors: diff --git a/MIPX/MIPXc2-Subproposals/placeholder.md b/MIP14/MIP14c2-Subproposals/placeholder.md similarity index 100% rename from MIPX/MIPXc2-Subproposals/placeholder.md rename to MIP14/MIP14c2-Subproposals/placeholder.md From 29371e3822b695f79eab9f2aece17dd804efb215 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 15 May 2020 11:39:19 -0400 Subject: [PATCH 14/50] Update MIP14 status to RFC --- MIP14/MIP14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP14/MIP14.md b/MIP14/MIP14.md index 9df8a0462..06ae75f46 100644 --- a/MIP14/MIP14.md +++ b/MIP14/MIP14.md @@ -7,7 +7,7 @@ Title: Protocol DAI Transfer Author(s): @LongForWisdom Contributors: N/A Type: Process -Status: Approved by MIP Editor +Status: Request for Comments (RFC) Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 From 6ba8629bb21b1c1a875f924199a717950764dd53 Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Mon, 18 May 2020 14:06:23 +0100 Subject: [PATCH 15/50] Minor change to wording. Fixed incorrect statement in MIP14c1 regarding the behavior of the Maker Protocol. --- MIP14/MIP14.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MIP14/MIP14.md b/MIP14/MIP14.md index 06ae75f46..7eb52ccc7 100644 --- a/MIP14/MIP14.md +++ b/MIP14/MIP14.md @@ -1,4 +1,4 @@ -# Protocol DAI Transfer +# MIP14: Protocol DAI Transfer ## Preamble ``` @@ -42,7 +42,7 @@ Giving governance the ability to use the value generated by the Maker Protocol i - It allows Maker Governance to incentivise actions taken to improve the protocol. - It reduces Maker Governance's reliance on the Maker Foundation. -Both of these should be seen as beneficial for fairly obvious reasons. Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future. +Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future. ## Specification / Proposal Details @@ -50,7 +50,7 @@ Both of these should be seen as beneficial for fairly obvious reasons. Less reli There are several important considerations to take into account before transferring value out of the Maker Protocol. - Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation. - Transfer of DAI from the protocol will take DAI from the surplus buffer if available. -- Transfer of DAI from the protocol will create bad debt and trigger FLOP auctions after the Debt auction delay (wait parameter) if there is not sufficient DAI available in the surplus buffer. +- If there is insufficient DAI available in the surplus buffer unbacked DAI will be created and FLOP auctions will be able to be triggered immediately. - If there is a more specific process MIP that allows DAI transfers that is more appropriate to the use case, use that process instead. --- From 3cf79578502c4a41705b761405fcd16711149437 Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Mon, 18 May 2020 14:20:22 +0100 Subject: [PATCH 16/50] Updated feedback and frozen periods to be written as 'full weeks' to aid clarity. --- MIP13/MIP13.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index 8ecc9243d..28229438b 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -128,8 +128,8 @@ If the subproposal defines a declaration to be replaced then: - The replaced declarations subproposal status should be changed to 'revoked' by a MIP Editor MIP13c3 subproposals have the following parameters: -- **Feedback Period**: 1 month -- **Frozen Period**: 1 week +- **Feedback Period**: 4 full weeks +- **Frozen Period**: 1 full week MIP13c3 subproposals must use the template located at **[MIP13c3-Subproposal-Template.md](MIP13c3-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. @@ -144,8 +144,8 @@ If a declaration of intent is revoked through a MIP13c4 subproposal then: - The revoked declarations subproposal status should be changed to 'revoked' by a MIP Editor MIP13c4 subproposals have the following parameters: -- **Feedback Period**: 1 month -- **Frozen Period**: 1 week +- **Feedback Period**: 4 full weeks +- **Frozen Period**: 1 full week MIP13c4 subproposals must use the template located at **[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. @@ -159,8 +159,8 @@ If work is accepted that fulfils a declared intention then: - The fulfilled declarations subproposal status should be changed to 'fulfilled' by a MIP Editor. MIP13c5 subproposals have the following parameters: -- **Feedback Period**: 1 month -- **Frozen Period**: 1 week +- **Feedback Period**: 4 full weeks +- **Frozen Period**: 1 full week MIP13c5 subproposals must use the template located at **[MIP13c5-Subproposal-Template.md](MIP13c5-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. The 'Proposed Executive Code' section of this template should be left unchanged by subproposal authors. From a31140b21834d7be004c93d209a6107931d53742 Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Mon, 18 May 2020 14:22:12 +0100 Subject: [PATCH 17/50] Updated MIP13c5-Subproposal-Template to match the conventions used in the MIP14c2 template. --- MIP13/MIP13c5-Subproposal-Template.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/MIP13/MIP13c5-Subproposal-Template.md b/MIP13/MIP13c5-Subproposal-Template.md index 485346b69..35ff56f70 100644 --- a/MIP13/MIP13c5-Subproposal-Template.md +++ b/MIP13/MIP13c5-Subproposal-Template.md @@ -17,8 +17,12 @@ Declaration to Fulfil: MIP13c3-SP# - Describe the implementation, and how it fulfils the linked Declaration of Intent. ### Bounty Dispensation -- How should the bounty be distributed? -- CLEARLY list any addresses and the amount of DAI to be distributed to each. The total amount should not exceed the bounty listed on the declaration of intent that has been fulfilled. +- CLEARLY list any addresses and the amount of DAI to be distributed to each in the following format: +``` +Recipient Address: 0x0000000000000000000000000000000000000000 +Amount To Transfer: 0 DAI +``` +- Combined amount of DAI should not exceed the bounty listed on the declaration of intent that has been fulfilled. ### Relevant Information - Links to evidence that proves the fulfilment of the intent. @@ -27,9 +31,11 @@ Declaration to Fulfil: MIP13c3-SP# The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team when the executive spell is written. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. ``` -VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * daiAmountToTransfer); VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer, daiAmountToTransfer); +VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * totalDaiAmountToTransfer); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer1, daiAmountToTransfer1); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer2, daiAmountToTransfer2); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer3, daiAmountToTransfer3); ``` This template can be used by a Smart Contracts domain team as many times as necessary (once per target address.) Variables `targetAddressToTransfer` and `daiAmountToTransfer` should be modified according to the Bounty Dispensation section above. \ No newline at end of file From f123fe8fc8c27d5a4731ee0a112126476171deab Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Thu, 21 May 2020 14:19:29 +0100 Subject: [PATCH 18/50] Added a description of a possible model that can be used to manage bounties to MIP13c1. --- MIP13/MIP13.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index 28229438b..1d2e95502 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -86,6 +86,8 @@ Declarations of both types (and anything inbetween) should be considered legitim While it's perfectly acceptable to declare intent in vague terms, it is suggested that Governance consider the vagueness of the declaration as a factor when determining if a bounty is released. Vague intentions may result in implementations that match the intention as written, but are not what Maker Governance expected, this should not be used as an excuse to deny bounty payments. +One model that may appeal to Maker Governance and/or bounty hunters is that of involving a project manager familiar with Maker Governance who can act as an intermediary between Maker Governance and the bounty hunters. In this instance the intermediary can handle the required governance processes and organise the delivery of work in exchange for a share of the bounty. + --- ### MIP13c2: List of Active Declarations From 5db26b49ac95cab675e35fdb18407f71b77547ad Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Thu, 21 May 2020 14:19:59 +0100 Subject: [PATCH 19/50] Minor clarification in MIP13c5-Subproposal-Template. --- MIP13/MIP13c5-Subproposal-Template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP13/MIP13c5-Subproposal-Template.md b/MIP13/MIP13c5-Subproposal-Template.md index 35ff56f70..82b586c80 100644 --- a/MIP13/MIP13c5-Subproposal-Template.md +++ b/MIP13/MIP13c5-Subproposal-Template.md @@ -28,7 +28,7 @@ Amount To Transfer: 0 DAI - Links to evidence that proves the fulfilment of the intent. ### Proposed Executive Code -The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team when the executive spell is written. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. +The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team writing the executive spell. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. ``` VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); From e6ea239666c3785a40ddeeff0c86f187c3e090af Mon Sep 17 00:00:00 2001 From: CPSTL <12cpsl@queensu.ca> Date: Fri, 29 May 2020 00:35:11 -0400 Subject: [PATCH 20/50] Propose Amendment MIPs for MIP6, MIP8, MIP9, MIP12 --- MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md | 38 ++++++++++++++++++ MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md | 50 ++++++++++++++++++++++++ MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md | 50 ++++++++++++++++++++++++ MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md | 51 +++++++++++++++++++++++++ MIP4/MIP4c2-Subproposals/placeholder.md | 1 - 5 files changed, 189 insertions(+), 1 deletion(-) create mode 100644 MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md create mode 100644 MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md create mode 100644 MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md create mode 100644 MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md delete mode 100644 MIP4/MIP4c2-Subproposals/placeholder.md diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md new file mode 100644 index 000000000..2c2120b31 --- /dev/null +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md @@ -0,0 +1,38 @@ +# MIP4c2-SP1: MIP6 Amendments + +## Preamble + +``` +MIP4c2-SP#: 1 +MIP to be Amended: MIP6 +Author(s): Charles St.Louis (@CPSTL) +Contributors: @LongForWisdom +Status: Request for Comments (RFC) +Date of Amendment Submission: 2020-05-28 +Date of ratification: <yyyy-mm-dd> +``` + +## Specification + +### Motivation + +Today, MIP6 currently requires MIP6 collateral applications to go through Domain Greenlight ([MIP8](https://github.com/makerdao/mips/blob/master/MIP8/mip8.md)) to be eligible for the Community Greenlight Poll ([MIP9](https://github.com/makerdao/mips/blob/master/MIP9/mip9.md)). Based on community feedback as well as general thoughts from the Authors and Contributors, the collateral onboarding process would be more efficient and effective if it did not require Domain Greenlight (MIP8) to occur before the Community Greenlight Poll ([MIP9](https://github.com/makerdao/mips/blob/master/MIP9/mip9.md)). This amendment MIP requests to allow collateral applications to be eligible for [MIP9](https://github.com/makerdao/mips/blob/master/MIP9/mip9.md) Community Greenlight polls at least two weeks after the [MIP6](https://github.com/makerdao/mips/blob/master/MIP6/mip6.md) application has been proposed, moving the Domain Greenlight process until after the polls have concluded. This amendment to the collateral onboarding process also helps with Domain team bandwidth and allows the Domain teams to allocate their time to collateral assets only after the community has approved them. + +This amendment to [MIP6](https://github.com/makerdao/mips/blob/master/MIP6/mip6.md) affects the general collateral onboarding flow previously proposed in the ratified Collateral Onboarding MIPs Set. Ultimately, it allows the collateral onboarding process to become more efficient. + +### Amended Components + + +- **MIP6c1: Process Overview** + - Add small phrasing updates throughout MIP6 to improve clarity/legibility. + - Remove bullet point 3 + - Replace content of bullet point 4 and convert the bullet point to number 3 (as bullet point 3 was removed). + + +### Amendment Pull Request (PR) + +- [Updated Version of MIP6 PR]() + +### Relevant Information + +- n/a \ No newline at end of file diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md new file mode 100644 index 000000000..3efd0f66f --- /dev/null +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md @@ -0,0 +1,50 @@ +# MIP4c2-SP2: MIP8 Amendments + + +## Preamble + +``` +MIP4c2-SP#: 2 +MIP to be Amended: MIP8 +Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) +Contributors: +Status: Request for Comments (RFC) +Date of Amendment Submission: 2020-05-27 +Date of ratification: <yyyy-mm-dd> + +``` + +## Specification + +### Motivation + +Today, the Domain Greenlight (MIP8) process occurs before the Community Greenlight Poll (MIP). This workflow increases the work required from Domain teams and reduces the time they can spend on doing domain work for onboarding collateral assets. + +Therefore, this amendment MIP is proposing that the Domain Greenlight process (MIP8) should occur after the proposed collateral asset has passed the MIP9 Community Greenlight Poll allowing the Domain teams to use the Community Greenlight Poll results to make a more informed decision and proceed with their domain work. + +In summary, the amendments in this proposal affect the overall Collateral Onboarding MIPs Set and the previously ratified collateral onboarding process. More specifically, it rearanges the collateral onboarding process to allow MIP9 to occur before MIP8. + +### Amended Components + +- **Component Summary** + - Re-arranged the order of the components to improve clarity. +- **Motivation** + - Updated to reflect the amendment changes mentioned in the Motivation section of this proposal. +- **Specification/Proposal Details** + - Remove introductory paragraph to remove redundancies. +- **MIP8c1: Domain Greenlight Process** + - Re-written to reflect amendments and improve readability and clarity. + - Updated the overview diagram to reflect the amended collateral onboarding process. +- **MIP8c2: Domain Greenlight Outcomes** + - Updated to reflect the amendments and to improve clarity surounding the possible outcomes of the the Domain Greenlight process. +- **MIP8c3: Domain Greenlight Requirements** + - Updated to reflect the amendments. This includes further explanation of the Domain Greenlgiht requirements as well as additions to the domain requirements to improve clarity and transparency as to what is required from the domain teams. + + +### Amendment Pull Request (PR) + +- [Updated Version of MIP8 PR]() + +### Relevant Information + +- n/a \ No newline at end of file diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md new file mode 100644 index 000000000..93d17ee70 --- /dev/null +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md @@ -0,0 +1,50 @@ +# MIP4c2-SP3: MIP9 Amendments + +## Preamble +``` +MIP4c2-SP#: 3 +MIP to be Amended: MIP9 +Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) +Contributors: +Status: Request for Comments (RFC) +Date of Amendment Submission: 2020-05-28 +Date of ratification: <yyyy-mm-dd> +``` +## Specification + +### Motivation + +This amendment MIP proposes some minor language edits and addresses some inconsistencies detailed throughout MIP9. More specifically, the proposed change will update the MIP to be consistent in saying that the Community Greenlight process will occur before the Domain Greenlight process, that Community Greenlight Polls will run for two weeks (including the details as to when they begin and end), and separating the components to increase clarity surrounding the overall process requirements and outcomes. + +In summary, the amendments in this proposal affect the overall Collateral Onboarding MIPs Set and the previously ratified collateral onboarding process. More specifically, it rearranges the collateral onboarding process to allow MIP9 to occur before MIP8. + +### Amended Components + +- **Paragraph Summary** + - Update paragraph to reflect the newly proposed period for when the Community Greenlight Polls begin and end. + +- **Component Summary** + - Create new components to separate further and clarify the content of the already existing components. + + +- **MIP9c1: The Community Greenlight Requirements and Process** + - Create new bullet points to detail further the Community Greenlight process and the criteria that must be met in order for the community greenlight polls to begin. + - Update the overview diagram to reflect the new collateral onboarding flow. + +- **MIP9c2: The Community Greenlight Outcomes** + - Further, explain the details of the "greenlit" status outcome of the poll and what it means for a collateral type after it has become "greenlit". + - Further, explain the details of what the "deferred" status outcomes of the poll and what it means for a collateral type after it has been "deferred". + - Add details as to how the Community Greenlight Polls are scored. + +- **MIP9c3: The Community Greenlight Requirements** + - Add the Governance Facilitators' responsibilities and requirements for the Community Greenlight process and how it affects the community. + +- **MIP9c4: Community Greenlight Poll Template** + - Add an introduction to MIP9c4 and update the Community Greenlight Poll Template. + + +### Amendment Pull Request (PR) + - [Updated Version of MIP9 PR]() + +### Relevant Information + - n/a \ No newline at end of file diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md new file mode 100644 index 000000000..1d854d708 --- /dev/null +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md @@ -0,0 +1,51 @@ +# MIP4c2-SP4: MIP12 Amendments + +## Preamble + +``` +MIP4c2-SP#: 4 +MIP to be Amended: MIP12 +Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) +Contributors: +Status: Request for Comments (RFC) +Date of Amendment Submission: 2020-05-28 +Date of ratification: <yyyy-mm-dd> +``` + +## Specification + +### Motivation + +This amendment MIP proposes a change to MIP12 to allow the collateral onboarding process to operate more efficiently. More specifically, it states that collateral onboarding can continue to operate despite not having an official General Risk Model ratified through the MIP11 process. + +This amendment MIP specifically impacts MIP12 subproposals. The update will allow MIP12 subproposals to be proposed to the governance cycle without needing a General Risk Model officially ratified in order for risk domain teams to provide risk constructs for the greenlit collateral assets. + +### Amended Components + +- **Paragraph Summary** + - Updated to reflect all of the domain teams involved in the collateral onboarding process. + +- **Component Summary** + - Add minor phrasing updates to the MIP12c1 summary to improve clarity surrounding the Domain team requirements for onboarding collateral to the Maker Protocol. + +- **Motivation** + - Add minor phrasing updates to make the language used across the Collateral Onboarding MIPs Set to be more consistent. + - Clarify that the MIP12 subproposal process is reserved for domain teams to propose new risk parameters, oracles, and adaptors for a new, or existing collateral type. + +- **MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol** + - Add minor phrasing updates to the domain team descriptions to further explain the domain team requirements for collateral onboarding. + +- **MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters** + - Add minor phrasing updates to reflect that the MIP12 subproposal process is reserved for domain teams. + - Update the descriptions of the three deliverables required when proposing new risk parameters, oracles, and collateral Adapters for collateral types. More specifically, changing the risk team's requirements to allow MIP12 subproposals to be proposed to the governance cycle without needing a General Risk Model officially ratified in order to provide risk constructs for collateral assets (note that this holds true until a second, non-Foundation domain risk team has been ratified through the MIP7 process). + +- **MIP12c3: Collateral Type Checklist for Governance Approval** + - Add minor formatting updates. + +### Amendment Pull Request (PR) + +- [Updated Version of MIP12 PR]() + +### Relevant Information + +- n/a \ No newline at end of file diff --git a/MIP4/MIP4c2-Subproposals/placeholder.md b/MIP4/MIP4c2-Subproposals/placeholder.md deleted file mode 100644 index b3a425249..000000000 --- a/MIP4/MIP4c2-Subproposals/placeholder.md +++ /dev/null @@ -1 +0,0 @@ -placeholder \ No newline at end of file From 5d1910f51f43e8ee50c4731bd015b01cd28f4ba0 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 00:47:33 -0400 Subject: [PATCH 21/50] Update MIP6 with Amendments detailed in MIP4c2-SP1 --- MIP6/mip6.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/MIP6/mip6.md b/MIP6/mip6.md index 0b982fcaa..c93664c4e 100644 --- a/MIP6/mip6.md +++ b/MIP6/mip6.md @@ -1,15 +1,16 @@ -# MIP6: Collateral Onboarding Form/Forum Template +# MIP6: Collateral Onboarding Application ## Preamble ``` MIP#: 6 -Title: Collateral onboarding form/forum template +Title: Collateral Onboarding Application 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 +Last Amended: <yyyy-mm-dd> Dependencies: n/a Replaces: n/a ``` @@ -24,55 +25,55 @@ MIP6 defines a standardized application form used to kick off the process of onb ## Paragraph Summary -The purpose of this proposal is to standardize the collateral onboarding form/forum template that community members and third-party projects can use to begin the process of getting their collateral onboarded to the Maker Protocol. +The purpose of this proposal is to standardize the collateral onboarding application template that community members and third-party projects can use to begin the process of getting their collateral onboarded to the Maker Protocol. ## Component Summary **MIP6c1: Process Overview** -Provides an overview of the collateral application form submission process which includes location, involved stakeholders and the next phase. +Provides an overview of the collateral application form submission process, which includes location, involved stakeholders, and the next phase. **MIP6c2: Application Template** -Provides an collateral application form template to be used in the submission process defined in MIP6c1. +Provides a collateral application form template to be used in the submission process defined in MIP6c1. **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 -This proposal aims to layout one part of the generalized process for adding collateral types to the Maker Protocol. This will allow the community to get an idea of what the applying collateral is, an overview of the risks, and an understanding of the potential benefits to Maker. A consistent application form allows prospective collateral types to be compared by the community. The pitch materials allow the interested party to generate interest from the Maker community. +This proposal aims to layout one part of the generalized process for adding collateral types to the Maker Protocol. This generalized process will allow the community to get an idea of what the applying collateral is, an overview of the risks, and an understanding of the potential benefits to Maker. A consistent application form allows prospective collateral types to be easily compared by the community. The pitch materials enable the interested party to generate interest from the Maker community. -Although this is only one component of the overall collateral onboarding process, this proposed standard would decrease confusion surrounding how to start the process of getting collateral added to the Maker Protocol and ultimately, increase the onboarding speed at which new collateral types can be onboarded. +Although this is only one component of the overall collateral onboarding process, this proposed standard would decrease confusion surrounding how to start the process of getting collateral added to the Maker Protocol and, ultimately, increase the onboarding speed at which new collateral types can be onboarded. ## Specification / Proposal Details ### MIP6c1: Process Overview **Collateral Onboarding Form / Form Template** -1. Fill out the application/questions in as much detail as you’re willing. +1. Fill out the application/questions in as much detail as you're willing. - - Once filled out, the application must be published on the official MakerDAO forum and should be posted within the `Collateral Onboarding App` subcategory within the `Maker Improvement Proposals` category. - - This post should have the tag `collateral-app`. - - Note that an 'interested party' refers to anybody willing to act as a stakeholder for this onboarding process. + - Once filled out, the application must be published on the official MakerDAO forum and should be posted within the `Collateral Onboarding App` subcategory within the `Maker Improvement Proposals` category. + - This post should have the tag `collateral-app.` + - Note that an 'interested party' refers to anybody willing to act as a stakeholder for this onboarding process. 2. After the submission on the forum, the community will likely have follow up questions. While not a requirement, answering questions about your project may help generate support or excitement for the proposed collateral type. Additionally, the interested party may organize an optional call to pitch their proposal as well as open up further discussion to the community. -3. Once the application has been submitted to the forum, it is eligible for Domain Greenlight as defined in MIP8. -4. After two weeks of discussion have passed, and Domain Greenlight (MIP8) has been completed, the application is eligible to move to the Community Greenlight poll defined in MIP9. +3. Once the MIP6 application has been published for at least two full weeks, it is eligible for a Community Greenlight poll defined in [MIP9](https://github.com/makerdao/mips/blob/master/MIP9/mip9.md). -### Overall Process Overview Diagram +### Community Introduction Process Overview Diagram + +<img width="635" alt="mip6-a" src="https://user-images.githubusercontent.com/32653033/83067804-49cb6a00-a035-11ea-9841-73b66df52fef.png"> -<img width="649" alt="mip6" src="https://user-images.githubusercontent.com/32653033/79087563-ad136e00-7d0d-11ea-89b2-679747275ecf.png"> --- ### MIP6c2: Application Template -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. +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. -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. +Responses to these questions serve as an introduction to the community; this minimum set of information helps intrigued community members research the project independently. Other pitch materials of all sorts are encouraged if the applicant believes it will help them garner support and excitement for the collateral. --- @@ -84,5 +85,4 @@ MIP6c3 is a Process MIP component that allows the modification of the template d 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. - --- From eb26198e9ccd60cf70009da7142ea6528ca803f3 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 00:48:54 -0400 Subject: [PATCH 22/50] Add PR to MIP6 for MIP4c2-SP1 --- MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md index 2c2120b31..58976e08b 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md @@ -31,8 +31,8 @@ This amendment to [MIP6](https://github.com/makerdao/mips/blob/master/MIP6/mip6. ### Amendment Pull Request (PR) -- [Updated Version of MIP6 PR]() +- [Updated Version of MIP6 PR](https://github.com/makerdao/mips/pull/39) ### Relevant Information -- n/a \ No newline at end of file +- n/a From c7b0d458256cbb60fe40f8d7aee857f4c5df3150 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 00:55:26 -0400 Subject: [PATCH 23/50] Update MIP8 with Amendments detailed in MIP4c2-SP2 --- MIP8/mip8.md | 71 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 46 insertions(+), 25 deletions(-) diff --git a/MIP8/mip8.md b/MIP8/mip8.md index a70eed62d..cf359ea6e 100644 --- a/MIP8/mip8.md +++ b/MIP8/mip8.md @@ -7,10 +7,11 @@ 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> -Dependencies: n/a +Date Ratified: 2020-05-02 +Last Amended: <yyyy-mm-dd> +Dependencies: MIP7, MIP9 Replaces: n/a ``` ## References @@ -18,53 +19,73 @@ No referenced materials. ## Sentence Summary -MIP8 defines the process by which domain teams signal that a potential collateral type is worth the time spent investigating its inclusion in the Maker Protocol. +MIP8 defines the process by which domain teams signal that a potential collateral type is worth investigating its inclusion in the Maker Protocol. ## Paragraph Summary -This proposal aims to define the process where at least one domain team from each domain (Risk, Smart Contracts, Oracles, Legal, etc) "Greenlights" the collateral type (based on research) in order for the collateral onboarding process to proceed. +This proposal defines the process where at least one domain team from each domain (Risk, Smart Contracts, Oracles, Legal, etc.) "Greenlights" the collateral type (based on research) in order for the collateral onboarding process to proceed. ## Component Summary -**MIP8c1: Domain Greenlight Requirements** -Defines the responsibilities of the domain teams in the domain greenlight process. -**MIP8c2: Domain Greenlight Process** +**MIP8c1: Domain Greenlight Process** Defines the domain greenlight process and its interaction with the collateral onboarding process. -**MIP8c3: Domain Greenlight Outcomes** +**MIP8c2: Domain Greenlight Outcomes** Defines the possible outcomes from the domain greenlight process. +**MIP8c3: Domain Greenlight Requirements** +Defines the responsibilities of the domain teams in the domain greenlight process. + ## Motivation -The goal of this proposal is to inform the community about the pre-evaluation stage with the aim of identifying any show-stopping problems before time is spent on a full evaluation of the collateral type. +The goal of this proposal is to define and inform the community about the pre-evaluation stage (Domain Greenlight) with the aim of identifying any show-stopping problems before domain teams spend time working on the work requirements to get a collateral type added to the Maker Protocol. ## Specification / Proposal Details -In this stage, the domain teams will signal that they believe the collateral type is worth the time to perform a full evaluation in their respective domain. Note that this stage may happen in parallel to the MIP6 process, but communication from the Domain teams should always come within two weeks of the end of the allotted review time for MIP6's collateral onboarding form/forum publication. +### MIP8c1: Domain Greenlight Process -### MIP8c1: Domain Greenlight Requirements +- For an asset to be onboarded to the Maker Protocol, domain work must be completed by risk, oracle, smart contracts, and optionally legal domain teams. Domain greenlight is the process through which domain teams signal their willingness to complete domain work on a proposed collateral asset. +- The domain greenlight process occurs after a proposed collateral asset has passed a MIP9 Community Greenlight Poll. +- If any domain team signals unwillingness to work on a proposed collateral asset, it does not mean that the asset will never be included as collateral in the Maker Protocol. +- If at least one domain team from the risk, oracle, and smart contracts domains do not greenlight a proposed collateral asset, the onboarding process for that asset awaits alternative domain teams willing to perform the domain work. -- If unresolvable issues arise with a specific domain, that domain team is responsible for communicating that they have **rejected** the collateral type to both the interested party and the community via the Maker forums. The domain team will provide a reason for rejection as part of this communication. -- If resolvable issues arise with a specific domain, that domain team is responsible for communicating that the collateral is **deferred** to both the interested party, and to the community via the Maker forums. This communication will include an explanation for the change in status and the criteria that should be met before they resume work. -- If there are no issues that warrant stopping this process, then each domain team is responsible for communicating that they are happy to proceed to a full evaluation. This is done by a member of each type of domain team making a forum reply to the MIP6 collateral application forum post saying they have done a MIP8 review and found no issues. +#### Domain Greenlight Process Overview Diagram + +<img width="839" alt="mip8-a" src="https://user-images.githubusercontent.com/32653033/83055609-0f0c0680-a022-11ea-9d93-6cad0a2ef8a3.png"> --- + +### MIP8c2: Domain Greenlight Outcomes + +**Greenlit** -### MIP8c2: Domain Greenlight Process +- If **greenlit**, the domain team has signaled their willingness to complete the domain work required to add the collateral asset to the Maker Protocol. -- In case new information becomes available that changes the assessment of a domain team, they can revoke their greenlight by posting that they are revoking it in the same forum post. -- If domain greenlight fails from one or multiple domain teams, it does not prevent the asset from being considered for collateral onboarding. It only prevents it from being onboarded if there is not an alternative team in that domain willing to greenlight it. +**Deferred** -#### Overall Process Overview Diagram +- The **Deferred** status signals that the domain team is willing to complete the domain work required to add the collateral asset to the Maker Protocol provided specific criteria are met. +- The resumption criterion must be defined and communicated clearly by the domain team on the official forum as part of this outcome. +- Until all deferred criteria are met, the deferring domain team will not proceed with the domain work required to add the collateral asset to the Maker Protocol. -<img width="822" alt="mip8-diagram" src="https://user-images.githubusercontent.com/32653033/79890509-9637e000-83cd-11ea-8078-7fcaac410a51.png"> +**Rejected** + +- The **Rejected** status signals that the domain team is unwilling to complete the domain work required to add the collateral asset to the Maker Protocol. +- Optionally, the domain team may provide a reason for this rejection as part of this outcome. --- - -### MIP8c3: Domain Greenlight Outcomes -- Regardless of whether any issues are raised, the process continues with MIP9 (Community Greenlight). -- If **deferred**, a resumption criterion is defined and communicated clearly. Until all **deferred** criteria are met, the deferring domain team will not work on the collateral. -- If **rejected** by any domain team, that team has signalled that they are unwilling to do further work on the collateral and that they do not recommend it for inclusion into the Maker Protocol. +### MIP8c3: Domain Greenlight Requirements + +- Communication from domain teams regarding domain greenlight must come within two weeks of the end of the MIP9 Community Greenlight poll on the official forum. +- A domain team should aim to signal their greenlight outcome within two weeks of the end of the MIP9 Community Greenlight poll. +- If a domain team cannot signal their greenlight outcome, they must do the following before the target date passes: + - Post a reason for the delay on the official forum. + - Post a new target date for communicating their domain greenlight outcome on the official forum. +- If subsequent dates will be missed, communication should be provided before the deadline passes, and should include a new target date. +- If further information becomes available that changes the domain team's assessment, they can modify their greenlight outcome by posting on the official forum at any time. +- If a deferred outcome is given, resumption criteria must be provided on the official forum. +- If resumption criteria from a deferred outcome are met, the greenlight outcome should be modified to greenlit. + +--- From 2d8bc420838e1bd660e42ce09b44fb9f2bb651d8 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 00:56:42 -0400 Subject: [PATCH 24/50] Add PR to MIP8 for MIP4c2-SP2 --- MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md index 3efd0f66f..73ec91518 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md @@ -43,8 +43,8 @@ In summary, the amendments in this proposal affect the overall Collateral Onboar ### Amendment Pull Request (PR) -- [Updated Version of MIP8 PR]() +- [Updated Version of MIP8 PR](https://github.com/makerdao/mips/pull/40) ### Relevant Information -- n/a \ No newline at end of file +- n/a From be2c590df73c1aa376dd8b00df656d45715e3ee0 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 01:02:39 -0400 Subject: [PATCH 25/50] Update MIP9 with Amendments detailed in MIP4c2-SP3 --- MIP9/mip9.md | 123 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 75 insertions(+), 48 deletions(-) diff --git a/MIP9/mip9.md b/MIP9/mip9.md index 26895923b..c593cc986 100644 --- a/MIP9/mip9.md +++ b/MIP9/mip9.md @@ -7,10 +7,11 @@ 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> -Dependencies: MIP6, MIP8 +Date Ratified: 2020-05-02 +Last Amended: <yyyy-mm-dd> +Dependencies: MIP6 Replaces: n/a ``` @@ -23,14 +24,20 @@ MIP9 defines the process by which MKR Token Holders can signal their judgment on ## Paragraph Summary -This proposal aims to standardize the process for allowing MKR Token Holders to inform the Domain Teams of their preferences for collateral types that have been proposed through MIP6. The preferences of the MKR Token holders are expressed in the form of an on-chain governance poll. The governance poll (Greenlight poll) runs at the end of the governance cycle and will run for a period of two weeks. +This proposal aims to standardize the process for allowing MKR Token Holders to inform the Domain Teams of their preferences for collateral types that have been proposed through MIP6. The preferences of the MKR Token holders are expressed in the form of an on-chain governance poll. The governance poll (Community Greenlight poll) is published at the start of the third week of the governance cycle and will run for a period of two weeks ending in the fourth and final week of the governance cycle. ## Component Summary -**MIP9c1: The Community Greenlight Requirements and Process** -Defines the process, requirements and possible outcomes from Community Greenlight process and the Governance Facilitators responsibilities in its operation. +**MIP9c1: The Community Greenlight Process** +Defines the community greenlight process and its interaction with the collateral onboarding process. -**MIP9c2: Governance Poll Template** +**MIP9c2: The Community Greenlight Outcomes** +Defines the possible outcomes from the community greenlight process. + +**MIP9c3: The Community Greenlight Requirements** +Defines the responsibilities of the Governance Facilitators in the community greenlight process. + +**MIP9c4: Community Greenlight Poll Template** Defines a governance poll template to be used in the on-chain Community Greenlight poll. ## Motivation @@ -40,56 +47,76 @@ While domain teams are free to choose their own workload, an on-chain governance ## Specification / Proposal Details -In this stage, the Governance Facilitator (GF) will create an on-chain governance poll in the template format defined in MIP9c2 and the community will vote with their preferences. - -### MIP9c1: The Community Greenlight Requirements and Process +### MIP9c1: The Community Greenlight Process -1. The process begins when an interested party (collateral type proposer) informs the Governance Facilitator(s) that the collateral application process has reached the Community Greenlight phase. - - The collateral form (MIP6) has been submitted to the forum and/or has received Domain Greenlight approval (MIP8) from each of the domain teams (smart contracts, risk and oracles). -2. From then on, the Governance Facilitator(s) are responsible for creating a Community Greenlight Poll for the collateral type in question. - - Note that an individual approval poll is created for each collateral asset. This poll will use the format defined in MIP9c2 (Governance Poll Template), using ETH as an example collateral type. - - The greenlight polls happen at a fixed time each governance cycle, from the 4th Monday of the month to the 4th Friday of the month. -3. The Governance Facilitator(s) are responsible for maintaining a list of collaterals based on the outcome of the individual Community Greenlight Polls. This list should include collateral types that have both passed and failed to pass their Community Greenlight Polls. -4. The collateral assets in the polls will be listed and ranked based on their score. As noted above (3), the list includes the collateral types that have both passed and failed to pass in the Community Greenlight Polls. It's important to include assets that have failed (negative score) to still be considered based on the domain teams judgment call, because you could have situations where competitors are trying to use MKR to suppress each other's assets in order to get a competitive edge and thus, unfairly put them at a disadvantage by denying them funding from Maker. -5. Any collateral asset that has passed MIP8, and not had any of its MIP8 greenlight approvals revoked again, including assets that have already had a greenlight poll before, will be included in the MIP9 community greenlight polls, except when for technical reasons there is not enough capacity to hold all the votes, in which case the governance facilitator decides the most important assets to include, prioritizing those that haven't had a vote before. +- For an asset to be onboarded to the Maker Protocol, it must pass an executive vote as part of MIP12. Community greenlight is the process through which early sentiment is measured and used to direct the work of domain teams towards assets that MKR Holders will be willing to onboard after work has been completed. +- The community greenlight process for a potential collateral asset consists of an on-chain governance poll using the template defined in MIP9c4. +- The community greenlight polls occur at a fixed time each governance cycle, starting on the 3rd Monday of the month and running for a period of 2 full weeks. +- A potential collateral asset is valid for a community greenlight poll if it has a MIP6 Application that has been published on the official forum for a period of 2 weeks prior to the monthly community greenlight poll date. -**Important Note:** MIP9 may happen in parallel with MIP8 (Domain Greenlight). -**Key Outcomes from the Governance Poll** +#### Community Greenlight Process Overview Diagram -- Once the Community Greenlight Poll is complete. The Domain teams proceed to perform their respective work defined in their mandates. - - **Example:** The Smart contracts team will build the collateral adaptor and the risk team will build their risk construct for the specified collateral type. -- If the Community Greenlight Poll passes and Domain Greenlight (MIP8) fails in one or more domains, the community must find a substitute for the rejecting domain teams before this process can proceed. -- If the Community Greenlight Poll fails the Domain teams are free to work on the collateral if they hold confidence that governance will approve it in the future. - +<img width="722" alt="mip9-a" src="https://user-images.githubusercontent.com/32653033/83067877-65367500-a035-11ea-9fb9-acefca9ec366.png"> + + +--- +### MIP9c2: The Community Greenlight Outcomes + +**Greenlit** + +- The community greenlight poll for the potential collateral asset ends with more greenlight votes than deferred votes. +- The potential collateral asset is marked as having been greenlit by the community. +- Domain teams may feel confident in allocating time to work on the potential collateral asset. +- The potential collateral asset is now eligible for the domain greenlight process defined in MIP8. -### Overall Process Overview Diagram +**Deferred** -<img width="686" alt="mip9" src="https://user-images.githubusercontent.com/32653033/79087697-23b06b80-7d0e-11ea-8411-82d6b4f0a0e5.png"> +- The community greenlight poll for the potential collateral asset ends with more defer votes than greenlight votes. +- The potential collateral asset is marked as having been deferred by the community. +- Domain teams may still choose to work on a collateral type that has been deferred if they are confident that governance will approve future inclusion. +- Community greenlight polls for assets that have been deferred can be rerun in the future at the discretion of the Governance Facilitators. +**Community Greenlight Poll Scoring** + +The polls are scored as follows: +- Score = Yes Votes - No Votes +- Score > 0 = Greenlit +- Score < 0 = Deferred + +Community Greenlight poll scores provide a reasonable first approximation of which assets domain teams should prioritize. However, this prioritization is not binding on the domain teams. Domain teams are free to determine the order in which they perform domain greenlights and domain work. --- -### MIP9c2: Governance Poll Template - -**Governance Poll Template:** - -**Poll Title:** -Should we add ETH (Ether) to the Maker Protocol? - -**Description:** - -If passed, this poll is to be taken as a signal to domain teams that MKR Token Holders have approved further domain work with the aim of adding ETH (Ether) as a collateral asset to the Maker Protocol. - -Background and discussion can be found at the following forum thread: <link to the community introduction thread created by the interested party> - -**Poll Options:** - -- [ ] Yes -- [ ] No - -**Duration of Poll:** - -The poll will run for two weeks . +### MIP9c3: The Community Greenlight Requirements + +- The Governance Facilitators are responsible for creating a Community Greenlight Poll for each valid potential collateral asset each month. +- If a previously deferred potential collateral asset is included in the monthly greenlight polls, a reason must be communicated to the community via the official forum before the greenlight poll occurs. +- The Governance Facilitators are responsible for maintaining a list of collaterals based on the outcome of the individual Community Greenlight Polls. This list should include collateral types that have been both greenlit and deferred. +- At the Governance Facilitators, discretion community greenlight polls may be deferred to a later a month. +- If the Governance Facilitators opt to defer, community greenlight polls a reason must be communicated to the community via the official forum before the greenlight polls take place. + +--- + +### MIP9c4: Community Greenlight Poll Template + +In this template, the asset ETH is used as an example collateral type. + +Additional informational material or reference links may be added to the poll content at the discretion of the Governance Facilitators. + +**Governance Poll Template:** + +**Poll Title** +MIP9 Community Greenlight Poll: ETH (Ether) + +**Description** +If greenlight votes exceed defer votes, this poll is to be taken as a signal to domain teams that MKR Token Holders have approved further domain work with the aim of adding ETH (Ether) as a collateral asset to the Maker Protocol. + +**Duration of Poll** +Two weeks + +**Poll Options** +- Yes (Greenlight) +- No (Defer) --- From a0e8b25c77d166c420a9a3cac2627299b4edca12 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 01:04:03 -0400 Subject: [PATCH 26/50] Add PR to MIP9 for MIP4c2-SP3 --- MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md index 93d17ee70..d09b3132e 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md @@ -44,7 +44,7 @@ In summary, the amendments in this proposal affect the overall Collateral Onboar ### Amendment Pull Request (PR) - - [Updated Version of MIP9 PR]() + - [Updated Version of MIP9 PR](https://github.com/makerdao/mips/pull/41) ### Relevant Information - - n/a \ No newline at end of file + - n/a From 17aedff71a31ad39d30d2619ac513f5718be9d95 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 01:12:11 -0400 Subject: [PATCH 27/50] Update MIP12 with Amendments detailed in MIP4c2-SP4 --- MIP12/mip12.md | 52 ++++++++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 25 deletions(-) diff --git a/MIP12/mip12.md b/MIP12/mip12.md index 4c7d4ef53..3177e8641 100644 --- a/MIP12/mip12.md +++ b/MIP12/mip12.md @@ -6,9 +6,10 @@ 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 +Last Amended: <yyyy-mm-dd> Dependencies: MIP0, MIP3, MIP7, MIP10, MIP11 Replaces: n/a ``` @@ -22,42 +23,42 @@ MIP12 defines the domain team and documentation requirements for adding or chang ## Paragraph Summary -This proposal defines the documentation requirements for the onboarding of a new collateral type to the Maker Protocol, more specifically, the risk teams' objectives and requirements to deliver it in a unified package risk construct. +This proposal defines the documentation and work requirements for the onboarding of new collateral types to the Maker Protocol, specifically the domain teams' objectives and requirements to deliver it in a unified MIP12 subproposal (MIP12-SP). ## Component Summary **MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol** -Lists the required and optional domain teams involved in onboarding a collateral type to the Maker Protocol. +Lists the required and optional domain teams involved in onboarding a collateral type to the Maker Protocol as well as a high-level overview of the domain work required. **MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters** -A process component that defines a method, a template and the requirements for proposing new risk parameters, oracles or collateral adaptors. +A process component that defines a method, a template, and the requirements for proposing new risk parameters, oracles, or collateral adaptors for collateral types. **MIP12c3: Collateral Type Checklist (Governance)** Defines a checklist of actions that must be completed before and after governance approval of a collateral type. ## Motivation -This proposal will focus on the collateral onboarding process blueprint for submitting MIP12 Subproposals (MIP12-SPs). The subproposals allow any community member to propose new risk parameters, oracles, and adapters for a new, or existing collateral type. Additionally, it will also define priority polls and the overall collateral onboarding process requirements. Furthermore, it allows domain teams to execute on collateral onboarding via the executive vote. This is the last step that needs to be completed when you have the risk construct with risk parameters based on a risk model ratified through MIP11. +This proposal will focus on the collateral onboarding process blueprint for submitting MIP12 Subproposals (MIP12-SPs). Submitting MIP12 Subproposals is the final step before collateral types go through the governance cycle and ultimately get added to or rejected from the Maker Protocol. The Subproposal process is reserved for domain teams to propose new risk parameters, oracles, and adapters for a new, or existing collateral type. This proposal also details the involvement of the community greenlight polls (MIP9) and the overall collateral onboarding process requirements. Furthermore, it allows domain teams to execute on collateral onboarding via the executive vote. ## Specification / Proposal Details ### MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol -- **A Risk team** (elected through MIP7) builds and approves their risk construct based on a ratified general model from MIP11 (Collateral Onboarding General Risk Model Management). -- **A Smart Contracts team** (elected through MIP7) builds and approves its collateral adapter, medianizer, oracle security module and executive vote code and the technical risk assessments of these smart contracts. -- **An Oracles team** (elected through MIP7), updates the oracle operations through MIP10 (Oracle Management) and then approves of the currently active price feeds as well as builds and approves their oracle security audit/risk assessment. -- (Optional) **A Legal team** (elected through MIP7) has created and approved the legal risk assessment of the collateral type based on the work completed by the above domain teams. +- **A Risk team** (elected through MIP7) builds and approves risk constructs for the collateral types that have been greenlit through the MIP9 and MIP8 processes. +- **A Smart Contracts team** (elected through MIP7) builds and approves the collateral types' adapter, medianizer, oracle security module for collateral types that have been greenlit through the MIP9 and MIP8 processes. Additionally, the Smart Contracts domain team will create the executive vote code (spell) as well as the technical risk assessments of the aforementioned smart contracts. +- **An Oracles team** (elected through MIP7), updates the oracle operations for collateral types that have been greenlit through the MIP9 and MIP8 processes through MIP10 (Oracle Management). Additionally, the Oracles domain team approves the currently active price feeds as well as builds and approves their oracle security audit/risk assessment. +- (Optional) **A Legal team** (elected through MIP7) creates and approves the legal risk assessment of the collateral types based on the work completed by the above domain teams. --- ### MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters -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 is a process MIP component that allows any domain team 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. +1. A risk domain team creates a risk construct for the collateral type (which should, in most cases, be based on a general risk model) and, in some cases, the results of polls that define all risk parameters for the collateral type. +3. 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. +4. 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 @@ -65,7 +66,6 @@ MIP12c2 subproposals must contain the following three deliverables in the specif 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. - --- ### MIP12c3: Collateral Type Checklist for Governance Approval @@ -73,15 +73,15 @@ MIP12c2 subproposals must use the template located at **[MIP12c2-Subproposal-Tem **Before being approved by governance, the following must be prepared in advance:** -- The risk model/risk construct for the collateral type +- The risk construct for the collateral type - The oracle solution for the collateral type -**After the collateral type has been approved by governance, the following actions are performed by the Smart Contracts Domain Team to formally implement the collateral type as a part of the Maker Protocol:** +**After the collateral type has been approved by governance, the Smart Contracts Domain Team conducts the following actions to formally implement the collateral type as a part of the Maker Protocol:** -- The Smart Contract Domain team creates the spell with the following bundled components generated from the risk model and the oracle solution: +- The **Smart Contract Domain team** creates the executive spell with the following bundled components generated from the risk construct and the oracle solution for the collateral type at hand: - `ilk` - Vault type - - `debt ceiling` - the maximum amount of Dai that can be generated from Vault/collateral type. - - `stability fee` - a variable-rate fee on Dai that is generated from the collateral type's Vault. + - `debt ceiling` - the maximum amount of Dai that can be generated from the Vault/collateral type. + - `stability fee` - a variable-rate fee on Dai generated from the collateral type's Vault. - `collateralization ratio` - the ratio between the value of the collateral and the value of the generated Dai for the specific collateral type Vault. - `flipper` - for the specified collateral type - `lot` - size for flip auction @@ -89,10 +89,12 @@ MIP12c2 subproposals must use the template located at **[MIP12c2-Subproposal-Tem - `min` bid increment - `end` - max auction duration - `ttl` - time duration before an auction ends after a bid - - **Collateral type Oracle** - - Specify the location of the Oracle Security Module (OSM) for the collateral type + - **Oracle Requirements:** + - Specify the location of the Oracle Security Module (OSM) for the collateral type. - gem.join adaptor - - **Once the spell has been created, the code is executed and the following occurs:** - - The collateral type has been added to the Maker Protocol - - Vaults can now be created with the new collateral type + +**Once the executive spell has been created, the code is executed once the Executive Governance Vote passes, and the delay period has passed. At this point, the:** +- The collateral type has been added to the Maker Protocol. +- Vaults can now be created with the new collateral type. + --- From 99c8a63b91a793c5397234c365b9f3533b4e92a5 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 01:13:19 -0400 Subject: [PATCH 28/50] Add PR to MIP12 for MIP4c2-SP4 --- MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md index 1d854d708..7e1674ce6 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md @@ -44,8 +44,8 @@ This amendment MIP specifically impacts MIP12 subproposals. The update will allo ### Amendment Pull Request (PR) -- [Updated Version of MIP12 PR]() +- [Updated Version of MIP12 PR](https://github.com/makerdao/mips/pull/42) ### Relevant Information -- n/a \ No newline at end of file +- n/a From 3d5b4b5683bb58765e55f71084d5e9f74cbe9582 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 29 May 2020 12:55:44 -0400 Subject: [PATCH 29/50] Fix list numbering in MIP12c2 --- MIP12/mip12.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP12/mip12.md b/MIP12/mip12.md index 3177e8641..f2fed78ba 100644 --- a/MIP12/mip12.md +++ b/MIP12/mip12.md @@ -57,8 +57,8 @@ MIP12c2 is a process MIP component that allows any domain team to propose new ri MIP12c2 subproposals must contain the following three deliverables in the specification section: 1. A risk domain team creates a risk construct for the collateral type (which should, in most cases, be based on a general risk model) and, in some cases, the results of polls that define all risk parameters for the collateral type. -3. 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. -4. 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. +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 From 74284cf72c864dac8d6beb40778151bcb031ff65 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Sun, 31 May 2020 11:26:30 -0400 Subject: [PATCH 30/50] Fix punctuation --- MIP9/mip9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP9/mip9.md b/MIP9/mip9.md index c593cc986..cf6864ec7 100644 --- a/MIP9/mip9.md +++ b/MIP9/mip9.md @@ -94,7 +94,7 @@ Community Greenlight poll scores provide a reasonable first approximation of whi - If a previously deferred potential collateral asset is included in the monthly greenlight polls, a reason must be communicated to the community via the official forum before the greenlight poll occurs. - The Governance Facilitators are responsible for maintaining a list of collaterals based on the outcome of the individual Community Greenlight Polls. This list should include collateral types that have been both greenlit and deferred. - At the Governance Facilitators, discretion community greenlight polls may be deferred to a later a month. -- If the Governance Facilitators opt to defer, community greenlight polls a reason must be communicated to the community via the official forum before the greenlight polls take place. +- If the Governance Facilitators opt to defer community greenlight polls, a reason must be communicated to the community via the official forum before the greenlight polls take place. --- From 3b594fd6ad8773163cb8e6a5acc115c3d3693758 Mon Sep 17 00:00:00 2001 From: LongForWisdom <LongForWisdom@pm.me> Date: Mon, 1 Jun 2020 00:08:43 +0100 Subject: [PATCH 31/50] Removed all references to bounties from this proposed MIP based on community feedback. --- MIP13/MIP13.md | 54 ++--------------------- MIP13/MIP13c3-Subproposal-Template.md | 5 --- MIP13/MIP13c5-Subproposal-Template.md | 41 ----------------- MIP13/MIP13c5-Subproposals/placeholder.md | 1 - 4 files changed, 4 insertions(+), 97 deletions(-) delete mode 100644 MIP13/MIP13c5-Subproposal-Template.md delete mode 100644 MIP13/MIP13c5-Subproposals/placeholder.md diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index 1d2e95502..f84a527e8 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -16,15 +16,14 @@ Replaces: n/a ## References **[MIP13c3-Subproposal-Template.md](MIP13c3-Subproposal-Template.md)** **[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)** -**[MIP13c5-Subproposal-Template.md](MIP13c5-Subproposal-Template.md)** ## Sentence Summary -MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help convert that intention into reality. +MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community. ## Paragraph Summary -MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community and optionally attach a monetary incentive to help make that intention into reality. MIP13 defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. Additionally, Maker Governance is able to optionally attach bounties to these declarations in order to incentivise actors to work on making them a reality. +MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community. MIP13 defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. These declarations can help to inform DAO members or the Maker Foundation as to the issues and priorities that Governance considers to be important. ## Component Summary @@ -40,12 +39,6 @@ A process component that allows Maker Governance to create, replace or amend-thr **MIP13c4: Revocation of Intent Process** A process component that allows Maker Governance to revoke a declaration of intent. -**MIP13c5: Acceptance of Work Process** -A process component that allows Maker Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. - -**MIP13c6: Considerations for Bounty Hunters** -Lays out a set of considerations for Bounty Hunters that wish to earn bounties through working on declared intents. - ## Motivation MIP13 is designed to formalize and expand on a pattern of behavior that has appeared consistently in the Maker Governance community. This pattern of behaviour tends to look like this: @@ -61,9 +54,6 @@ We've seen this pattern come up multiple times, across multiple different subjec In each of these cases, there was no formal record of the declaration of intent beyond an on-chain poll and the various forum threads that led to the decision. By formalizing this process in MIPs, anyone wishing to interact with Maker Governance can easily discover what has been agreed on various topics in one place. In addition there will be a record of when each declaration took place, and the described reasons for it to have been declared. -The inclusion of bounties helps to deal directly with point 4 listed above, in that after Maker Governance declares the intent to do something (regards of the method used to do so), it is currently unable to incentivise that thing to take place without relying in some way on the Maker Foundation. - - ## Specification / Proposal Details ### MIP13c1: What is a Declaration of Intent? @@ -82,12 +72,6 @@ There may be times when Maker Governance does not care about the implementation Declarations of both types (and anything inbetween) should be considered legitimate, but Maker Governance should take care to make it clear where each declaration lies on the scale between these two extremes. -**With relation to bounties** - -While it's perfectly acceptable to declare intent in vague terms, it is suggested that Governance consider the vagueness of the declaration as a factor when determining if a bounty is released. Vague intentions may result in implementations that match the intention as written, but are not what Maker Governance expected, this should not be used as an excuse to deny bounty payments. - -One model that may appeal to Maker Governance and/or bounty hunters is that of involving a project manager familiar with Maker Governance who can act as an intermediary between Maker Governance and the bounty hunters. In this instance the intermediary can handle the required governance processes and organise the delivery of work in exchange for a share of the bounty. - --- ### MIP13c2: List of Active Declarations @@ -100,20 +84,17 @@ This list can be amended through subproposals created under MIP13c3, MIP13c4 and Declaration Statement: Sub-proposal Number: # Date Ratified: (yyyy-mm-dd) -Bounty: ``` Note that the subproposal code should link to the relevant subproposal. - **Active Declarations List** -There are currently no active declarations. Below is an example declaration which should be removed (as should this paragraph) when the first ratified declaration is added to this list . +There are currently no active declarations. Below is an example declaration which should be removed (as should this paragraph) when the first ratified declaration is added to this list. If there are no active declarations, the example declaration and this paragraph should be restored. ``` Declaration Statement: All Governance Facilitators should be given chocolate on the 30th of February each year. Sub-proposal Number: MIP13c3-SP0 Date Ratified: 2020-02-30 -Bounty: 1,000,000 DAI ``` --- @@ -121,8 +102,6 @@ Bounty: 1,000,000 DAI ### MIP13c3: Declaration of Intent Process MIP13c3 is a Process MIP component that allows MKR Governance to create, replace or amend-through-replace a declaration of intent through a subproposal. -Note that Declarations of Intent can be assigned bounties as part of this process. Bounties are always denominated and provided in DAI. - If a declaration of intent is ratified through a MIP13c3 subproposal, it should be added to the MIP13c2 list by a MIP Editor. If the subproposal defines a declaration to be replaced then: @@ -151,29 +130,4 @@ MIP13c4 subproposals have the following parameters: MIP13c4 subproposals must use the template located at **[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. ---- - -### MIP13c5: Acceptance of Work Process -MIP13c5 is a Process MIP component that allows MKR Governance to formally accept work done as the realisation of a declared intention and disburse any relevant bounties. Note that MIP13c5 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to the producer(s) of the accepted work. - -If work is accepted that fulfils a declared intention then: -- The fulfilled declaration should be removed from the MIP13c2 list by a MIP Editor. -- The fulfilled declarations subproposal status should be changed to 'fulfilled' by a MIP Editor. - -MIP13c5 subproposals have the following parameters: -- **Feedback Period**: 4 full weeks -- **Frozen Period**: 1 full week - -MIP13c5 subproposals must use the template located at **[MIP13c5-Subproposal-Template.md](MIP13c5-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. The 'Proposed Executive Code' section of this template should be left unchanged by subproposal authors. - ---- - -### MIP13c6: Considerations for Bounty Hunters -This component is included to provided guidance to Bounty Hunters that wish to fulfil declared intentions and recieve DAI as bounty. - -1. Payment is contingent on demonstrating to Maker Governance that the intention has been satisfied. -2. Once the work has been completed, the party responsible for the work should submit a MIP13c5 subproposal to claim the bounty. -3. Work with Maker Governance as much as possible for each step of the process, make sure that you have a full understanding of the intention described in the declaration of intent subproposal. -4. If you are worried that a specific declaration of intent is confusing, ambiguous, or otherwise badly formed, please communicate this before starting work. -5. If a declaration of intent is quite old, consider reaching out to Maker Governance to enquire as to whether it is still valid before starting work. This may prompt a new declaration of intent in the case intentions have changed. -6. Due to the way the Governance Cycle operates, payment for completed bounties may be delayed for several months in the worst case. +--- \ No newline at end of file diff --git a/MIP13/MIP13c3-Subproposal-Template.md b/MIP13/MIP13c3-Subproposal-Template.md index 78563009f..ee2ab67c5 100644 --- a/MIP13/MIP13c3-Subproposal-Template.md +++ b/MIP13/MIP13c3-Subproposal-Template.md @@ -11,7 +11,6 @@ Date Ratified: <yyyy-mm-dd> --- Declaration Statement: Declaration to Replace: MIP13c3-SP# or n/a -Bounty: ``` ## Specification @@ -24,10 +23,6 @@ Bounty: - As clear a description as possible of the intent that Maker Governance wishes to declare. - How flexible is this intent in terms of implementation? -### Justification of Bounty Amount - -- Why has this declaration been given the bounty it has? - ### Relevant Links - Forum Discussions, etc diff --git a/MIP13/MIP13c5-Subproposal-Template.md b/MIP13/MIP13c5-Subproposal-Template.md deleted file mode 100644 index 82b586c80..000000000 --- a/MIP13/MIP13c5-Subproposal-Template.md +++ /dev/null @@ -1,41 +0,0 @@ -# MIP13c5: Subproposal Template for Acceptance of Work - -## Preamble -``` -MIP13c5-SP#: # -Author(s): -Contributors: -Status: -Date Proposed: <yyyy-mm-dd> -Date Ratified: <yyyy-mm-dd> ---- -Declaration to Fulfil: MIP13c3-SP# -``` -## Specification - -### Description of Implemented Work -- Describe the implementation, and how it fulfils the linked Declaration of Intent. - -### Bounty Dispensation -- CLEARLY list any addresses and the amount of DAI to be distributed to each in the following format: -``` -Recipient Address: 0x0000000000000000000000000000000000000000 -Amount To Transfer: 0 DAI -``` -- Combined amount of DAI should not exceed the bounty listed on the declaration of intent that has been fulfilled. - -### Relevant Information -- Links to evidence that proves the fulfilment of the intent. - -### Proposed Executive Code -The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team writing the executive spell. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. - -``` -VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); -VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * totalDaiAmountToTransfer); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer1, daiAmountToTransfer1); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer2, daiAmountToTransfer2); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer3, daiAmountToTransfer3); -``` - -This template can be used by a Smart Contracts domain team as many times as necessary (once per target address.) Variables `targetAddressToTransfer` and `daiAmountToTransfer` should be modified according to the Bounty Dispensation section above. \ No newline at end of file diff --git a/MIP13/MIP13c5-Subproposals/placeholder.md b/MIP13/MIP13c5-Subproposals/placeholder.md deleted file mode 100644 index b3a425249..000000000 --- a/MIP13/MIP13c5-Subproposals/placeholder.md +++ /dev/null @@ -1 +0,0 @@ -placeholder \ No newline at end of file From b5ae959b9dc1dd73f7791726a6aca68da4a058af Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Mon, 1 Jun 2020 22:38:27 -0400 Subject: [PATCH 32/50] Add MIP7c3-SP2 Subproposal Adding subproposal for the Domain Team Onboarding of the Risk Domain Team --- MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md | 39 ++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md diff --git a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md new file mode 100644 index 000000000..c76be0e18 --- /dev/null +++ b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md @@ -0,0 +1,39 @@ +# MIP7c3-SP2: Domain Team Onboarding (Risk Domain Team) + +## Preamble + +``` +MIP7c3-SP#: 2 +Author(s): Cyrus Younessi (@DonutJr) +Contributors: n/a +Status: Request for Comments (RFC) +Date Applied: 2020-06-01 +Date Ratified: <yyyy-mm-dd> +--- +Domain Role: Risk Domain Team Facilitator +Proposed Applicant: Cyrus Younessi +``` + +## Application Form + +### Domain Team Introduction + +- The Risk Domain team has been working for the betterment of the Maker Protocol, starting with Single-Collateral Dai and continuing to this day with Multi-Collateral Dai. + +### Motivation + +- A Risk domain team is needed to help maintain and facilitate the Maker Protocol's risk management duties. Specifically, a risk domain team is responsible for creating frameworks around monetary policy risk and collateral portfolio risk. These frameworks can be used for the calculation of risk parameters that are submitted to Maker governance. + +### Work Credentials + +- **Work Experience** + - Head of Risk for the Maker Foundation + - Director of Research and Trading at Scalar Capital + - Investment Analyst at Cumberland Mining + +### Relevant Information + +- **Rocket Chat Account:** @cyrus +- **Github Account:** [@DonutJr](https://github.com/DonutJr) +- **MakerDAO Forum Account:** [@Cyrus](https://forum.makerdao.com/u/cyrus/summary) +- **Twitter Account:** [cyounessi1](https://twitter.com/cyounessi1) From 47e7a7a4b5d6b488541681fd27e17436c44af1de Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:28:35 -0400 Subject: [PATCH 33/50] Update MIP4c2-SP1 Status to Formal Submission --- MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md index 58976e08b..512793868 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md @@ -7,7 +7,7 @@ MIP4c2-SP#: 1 MIP to be Amended: MIP6 Author(s): Charles St.Louis (@CPSTL) Contributors: @LongForWisdom -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From 2eb534b9111bbf83753a213c72b743ae3669f4d6 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:29:15 -0400 Subject: [PATCH 34/50] Update status of MIP4c2-SP2 to Formal Submission --- MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md index 73ec91518..b159d8c0e 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md @@ -8,7 +8,7 @@ MIP4c2-SP#: 2 MIP to be Amended: MIP8 Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date of Amendment Submission: 2020-05-27 Date of ratification: <yyyy-mm-dd> From 392b0a5c3b7a6b22d86edc8c07dfc6c5a6031578 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:29:48 -0400 Subject: [PATCH 35/50] Update status of MIP4c2-SP3 to Formal Submission --- MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md index d09b3132e..7b118f1c7 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md @@ -6,7 +6,7 @@ MIP4c2-SP#: 3 MIP to be Amended: MIP9 Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From 8f7149fe830267137e81123686b8173367e7391d Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:30:13 -0400 Subject: [PATCH 36/50] Update status of MIP4c2-SP4 to Formal Submission --- MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md index 7e1674ce6..aa65ee6e8 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md @@ -7,7 +7,7 @@ MIP4c2-SP#: 4 MIP to be Amended: MIP12 Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From e9dd8df87ac344b255028bffabe4a3f9f9e35a70 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:31:10 -0400 Subject: [PATCH 37/50] Update status of MIP13 to Formal submission --- MIP13/MIP13.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index f84a527e8..821b3e604 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -7,7 +7,7 @@ Title: Declarations of Intent Author(s): @LongForWisdom Contributors: n/a Type: Process -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 @@ -130,4 +130,4 @@ MIP13c4 subproposals have the following parameters: MIP13c4 subproposals must use the template located at **[MIP13c4-Subproposal-Template.md](MIP13c4-Subproposal-Template.md)**. This template is considered ratified if this MIP moves to Accepted status. ---- \ No newline at end of file +--- From 5f5a28e30538ca4136c25aa0d01672d751f34ccc Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:31:48 -0400 Subject: [PATCH 38/50] Update MIP14 status to Formal Submission --- MIP14/MIP14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP14/MIP14.md b/MIP14/MIP14.md index 7eb52ccc7..8bdffa6d8 100644 --- a/MIP14/MIP14.md +++ b/MIP14/MIP14.md @@ -7,7 +7,7 @@ Title: Protocol DAI Transfer Author(s): @LongForWisdom Contributors: N/A Type: Process -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 From 2017b89a468134898bf0895c4e78985ceccb0471 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Thu, 4 Jun 2020 10:32:43 -0400 Subject: [PATCH 39/50] Update MIP7c3-SP2 status to Formal Submission --- MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md index c76be0e18..baa3360fb 100644 --- a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md +++ b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md @@ -6,7 +6,7 @@ MIP7c3-SP#: 2 Author(s): Cyrus Younessi (@DonutJr) Contributors: n/a -Status: Request for Comments (RFC) +Status: Formal Submission (FS) Date Applied: 2020-06-01 Date Ratified: <yyyy-mm-dd> --- From 933de6d29491753c8acfd197b35cd086bb9aff0d Mon Sep 17 00:00:00 2001 From: Eric Smith <paytonrules@gmail.com> Date: Fri, 26 Jun 2020 13:55:11 -0500 Subject: [PATCH 40/50] Add github action for writing to IPFS On push, for the master, RFC, and Accepted branches. --- .github/workflows/main.yml | 39 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 .github/workflows/main.yml diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml new file mode 100644 index 000000000..823d05ca0 --- /dev/null +++ b/.github/workflows/main.yml @@ -0,0 +1,39 @@ +# This is a basic workflow to help you get started with Actions + +name: IPFS + +# Controls when the action will run. Triggers the workflow on push or pull request +# events but only for the master branch +on: + push: + branches: [ master, RFC, Accepted ] + +# A workflow run is made up of one or more jobs that can run sequentially or in parallel +jobs: + # This workflow contains a single job called "build" + build: + # The type of runner that the job will run on + runs-on: ubuntu-latest + + # Steps represent a sequence of tasks that will be executed as part of the job + steps: + # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it + - uses: actions/checkout@v2 + + - name: Upload to IPFS + uses: aquiladev/ipfs-action@v0.1.3 + with: + # Directory path to upload + path: ../mips + # Type of target service to upload. Supported services [ipfs] + service: ipfs # optional, default is ipfs + # IPFS host + host: ipfs.komputing.org # optional, default is ipfs.komputing.org + # IPFS port + port: 443 # optional, default is 443 + # IPFS protocol + protocol: https # optional, default is https + # Request timeout + timeout: 60000 # optional, default is 60000 + # Level of verbosity + verbose: true From 32ea76287b4698a404d0b141caec0e7ffbc834c8 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:00:29 -0400 Subject: [PATCH 41/50] Update status of MIP13 to Accepted --- MIP13/MIP13.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index 821b3e604..8c162d09d 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -7,7 +7,7 @@ Title: Declarations of Intent Author(s): @LongForWisdom Contributors: n/a Type: Process -Status: Formal Submission (FS) +Status: Accepted Date Proposed: 2020-05-12 Date Ratified: <yyyy-mm-dd> Dependencies: MIP0 From c64ce2af79281fbc87e5feb68b4602d030d7025c Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:01:17 -0400 Subject: [PATCH 42/50] Update status of MIP4c2-SP1 to Accepted --- MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md index 512793868..616cd94b0 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md @@ -7,7 +7,7 @@ MIP4c2-SP#: 1 MIP to be Amended: MIP6 Author(s): Charles St.Louis (@CPSTL) Contributors: @LongForWisdom -Status: Formal Submission (FS) +Status: Accepted Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From 4a0c151f3c6b0d148fefd3715b81877bfbf22abe Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:01:43 -0400 Subject: [PATCH 43/50] Update status of MIP4c2-SP2 to Accepted --- MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md index b159d8c0e..7747f4f0d 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md @@ -8,7 +8,7 @@ MIP4c2-SP#: 2 MIP to be Amended: MIP8 Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: -Status: Formal Submission (FS) +Status: Accepted Date of Amendment Submission: 2020-05-27 Date of ratification: <yyyy-mm-dd> From 20b9bec88cd87fe27f5fc991372db5532769e344 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:02:07 -0400 Subject: [PATCH 44/50] Update status of MIP4c2-SP3 to Accepted --- MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md index 7b118f1c7..7ecd0786c 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md @@ -6,7 +6,7 @@ MIP4c2-SP#: 3 MIP to be Amended: MIP9 Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: -Status: Formal Submission (FS) +Status: Accepted Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From 3d446a04b0dbbdac233c430fd63a2e0ac8b11d99 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:02:27 -0400 Subject: [PATCH 45/50] Update status of MIP4c2-SP4 to Accepted --- MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md index aa65ee6e8..c5a771b3f 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md @@ -7,7 +7,7 @@ MIP4c2-SP#: 4 MIP to be Amended: MIP12 Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: -Status: Formal Submission (FS) +Status: Accepted Date of Amendment Submission: 2020-05-28 Date of ratification: <yyyy-mm-dd> ``` From 656b8d4e92d8e97c71a2461155ad3b62180ab330 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:03:30 -0400 Subject: [PATCH 46/50] Update status of MIP7c3-SP2 to Accepted Officially adding the first Risk domain team to the Maker Protocol --- MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md index baa3360fb..fdb68df88 100644 --- a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md +++ b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md @@ -6,7 +6,7 @@ MIP7c3-SP#: 2 Author(s): Cyrus Younessi (@DonutJr) Contributors: n/a -Status: Formal Submission (FS) +Status: Accepted Date Applied: 2020-06-01 Date Ratified: <yyyy-mm-dd> --- From c986ad58e52d056646c433ed13eafce3bc74889f Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Wed, 1 Jul 2020 22:04:27 -0400 Subject: [PATCH 47/50] Update status of MIP0c12-SP2 to Accepted Officially adding LongForWisdom as a Governance Facilitator --- MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md index cdd8eda59..9e64c5b67 100644 --- a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md +++ b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md @@ -5,7 +5,7 @@ MIP0c12-SP#: 2 Author: LongForWisdom Contributors: n/a -Status: Formal Submission +Status: Accepted Date Applied: 2020-05-04 Date Ratified: <yyyy-mm-dd> --- From 9133ee0e14840acd7e0d0b9d0878c1f3d095ec39 Mon Sep 17 00:00:00 2001 From: Niklas Kunkel <nik@makerdao.com> Date: Thu, 2 Jul 2020 23:00:28 -0700 Subject: [PATCH 48/50] MIP10c15 subproposal template - fixed markdown --- MIP10/MIP10c15-Subproposal-Template.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIP10/MIP10c15-Subproposal-Template.md b/MIP10/MIP10c15-Subproposal-Template.md index 03b3e673c..213d2d47f 100644 --- a/MIP10/MIP10c15-Subproposal-Template.md +++ b/MIP10/MIP10c15-Subproposal-Template.md @@ -34,7 +34,7 @@ Date Ratified: <yyyy-mm-dd> - Is it likely given the information provided that there are individuals who could identify this person? What order of magnitude? ### Light Feeds -**Reputation* +**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? @@ -50,7 +50,7 @@ Date Ratified: <yyyy-mm-dd> - 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* +**Identity** - Did the Oracle Team get in contact with the organization to confirm their application? ### Cost-Benefit From 57db340a659705e5cc2e44cadb4dabadaeeb535e Mon Sep 17 00:00:00 2001 From: CPSTL <12cpsl@queensu.ca> Date: Fri, 17 Jul 2020 11:46:08 -0400 Subject: [PATCH 49/50] Update accepted MIPs --- MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md | 2 +- MIP0/mip0.md | 5 + MIP13/MIP13.md | 2 +- MIP14/MIP14.md | 106 ---------------------- MIP14/MIP14c2-Subproposal-Template.md | 51 ----------- MIP14/MIP14c2-Subproposals/placeholder.md | 1 - MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md | 2 +- MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md | 2 +- MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md | 2 +- MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md | 2 +- MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md | 2 +- 11 files changed, 12 insertions(+), 165 deletions(-) delete mode 100644 MIP14/MIP14.md delete mode 100644 MIP14/MIP14c2-Subproposal-Template.md delete mode 100644 MIP14/MIP14c2-Subproposals/placeholder.md diff --git a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md index 9e64c5b67..e1ffc3d3e 100644 --- a/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md +++ b/MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md @@ -7,7 +7,7 @@ Author: LongForWisdom Contributors: n/a Status: Accepted Date Applied: 2020-05-04 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-05-28 --- Core Personnel Role: Governance Facilitator Proposed applicant: LongForWisdom diff --git a/MIP0/mip0.md b/MIP0/mip0.md index f492bb554..df06e1733 100644 --- a/MIP0/mip0.md +++ b/MIP0/mip0.md @@ -289,6 +289,11 @@ Entries into this list should follow the following template: - **Core Role:** Governance Facilitator - **Date Added:** 2019-09-09 ([Poll: Ratify the Interim Governance Facilitator Mandate](https://vote.makerdao.com/polling-proposal/qmvh4z3l5ymqgtfs6tifq3jpjx5mxgdfnjy6alewnwwvba)) +- **Person Name:** LongForWisdom + - **Sub-proposal Number (MIP0c12-SP):** 2 + - **Core Role:** Governance Facilitator + - **Date Added:** 2020-05-28 [Ratification Vote: Officially Ratify the MIP0c12-SP2 Subproposal for Onboarding a Second Governance Facilitator](https://mkrgov.science/executive/0x9713187b6d7c8d54ac041efdbac13d52c2120fb9) + 2. **MIP Editors:** - **Person Name:** Charles St.Louis diff --git a/MIP13/MIP13.md b/MIP13/MIP13.md index 8c162d09d..1a9c4a66f 100644 --- a/MIP13/MIP13.md +++ b/MIP13/MIP13.md @@ -9,7 +9,7 @@ Contributors: n/a Type: Process Status: Accepted Date Proposed: 2020-05-12 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-06-25 Dependencies: MIP0 Replaces: n/a ``` diff --git a/MIP14/MIP14.md b/MIP14/MIP14.md deleted file mode 100644 index 8bdffa6d8..000000000 --- a/MIP14/MIP14.md +++ /dev/null @@ -1,106 +0,0 @@ -# MIP14: Protocol DAI Transfer - -## Preamble -``` -MIP#: 14 -Title: Protocol DAI Transfer -Author(s): @LongForWisdom -Contributors: N/A -Type: Process -Status: Formal Submission (FS) -Date Proposed: 2020-05-12 -Date Ratified: <yyyy-mm-dd> -Dependencies: MIP0 -Replaces: N/A -``` -## References -**[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)** - -## Sentence Summary - -MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. - -## Paragraph Summary - -MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so. - -## Component Summary - -**MIP14c1: Considerations Regarding Protocol DAI Transfers** -A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIP14c2. - -**MIP14c2: Protocol DAI Transfer Process** -A process component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. - -**MIP14c3: Protocol DAI Transfer List** -A list component that lists the previous direct DAI transfers that have been made by the protocol in the past. - - -## Motivation - -Giving governance the ability to use the value generated by the Maker Protocol is beneficial for two main reasons: -- It allows Maker Governance to incentivise actions taken to improve the protocol. -- It reduces Maker Governance's reliance on the Maker Foundation. - -Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future. - -## Specification / Proposal Details - -**MIP14c1: Considerations Regarding Protocol DAI Transfers** -There are several important considerations to take into account before transferring value out of the Maker Protocol. -- Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation. -- Transfer of DAI from the protocol will take DAI from the surplus buffer if available. -- If there is insufficient DAI available in the surplus buffer unbacked DAI will be created and FLOP auctions will be able to be triggered immediately. -- If there is a more specific process MIP that allows DAI transfers that is more appropriate to the use case, use that process instead. - ---- - -**MIP14c2: Protocol DAI Transfer Process** -MIP14c2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIP14c2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses. - -If a MIP14c2 subproposal is Accepted, The DAI Transfer is appended to the list in MIP14c3 by a MIP Editor. - -MIP14c2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: - -**< 10,000 DAI Transfer** -- **Feedback Period:** 0 full weeks -- **Frozen period:** 0 full weeks - -**10,000 - 100,000 DAI Transfer** -- **Feedback Period:** 4 full weeks -- **Frozen period:** 1 full week - -**> 100,000 DAI Transfer** -- **Feedback Period:** 12 full weeks -- **Frozen period:** 4 full weeks - -MIP14c2 subproposals must use the template located at **[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. - ---- - -**MIP14c3: Protocol DAI Transfer List** -This list can be amended through subproposals created under MIP14c2. - -**List Entry Template** -Entries into this list should follow the following template: - -``` -Reason: -Sub-proposal Number: # -Date Ratified: (yyyy-mm-dd) -Amount Transferred: -Recipient Address: -``` - -**Historical Transfer List** -There are currently no historical transfers. Below is an example transfer which should be removed (as should this paragraph) when the first ratified transfer is added to this list . - -``` -Reason: Funding Chocolate for Governance Facilitators -Sub-proposal Number: MIP14c1-SP0 -Date Ratified: 2020-02-30 -Amount Transferred: 1,000,000 DAI -Recipient Address: 0x0000000000000000000000000000000000000000 -``` - ---- diff --git a/MIP14/MIP14c2-Subproposal-Template.md b/MIP14/MIP14c2-Subproposal-Template.md deleted file mode 100644 index ebb6111c1..000000000 --- a/MIP14/MIP14c2-Subproposal-Template.md +++ /dev/null @@ -1,51 +0,0 @@ -# MIP14c2: Subproposal for Protocol DAI Transfer - -## Preamble -``` -MIP14c2-SP: # -Title: <Title> -Author(s): -Contributors: -Status: -Date Proposed: <yyyy-mm-dd> -Date ratified: <yyyy-mm-dd> ---- -Amount: -``` - -## Specification - -### Sentence Reason - -- A one sentence reason of why DAI is being transferred from the protocol. - -### Reason Details - -- More details regarding the reason for the Protocol DAI Transfer. - -### Targets - -- Clearly listed target addresses with matching amounts in the format: -``` -Recipient Address: 0x0000000000000000000000000000000000000000 -Amount To Transfer: 0 DAI -``` -- Combined amount of DAI should not be higher than the Amount specified in the Preamble. - -### Relevant Information: - -- Links to discussion, evidence or anything related to the transfer. - -### Proposed Executive Code -The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team writing the executive spell. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. - -``` -VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); -VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * totalDaiAmountToTransfer); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer1, daiAmountToTransfer1); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer2, daiAmountToTransfer2); -DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer3, daiAmountToTransfer3); -... -``` - -Variables totalDaiAmountToTransfer, targetAddressToTransfer and daiAmountToTransfer should be modified according to the Amount and Targets section above. \ No newline at end of file diff --git a/MIP14/MIP14c2-Subproposals/placeholder.md b/MIP14/MIP14c2-Subproposals/placeholder.md deleted file mode 100644 index b3a425249..000000000 --- a/MIP14/MIP14c2-Subproposals/placeholder.md +++ /dev/null @@ -1 +0,0 @@ -placeholder \ No newline at end of file diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md index 616cd94b0..44c430cea 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP1.md @@ -9,7 +9,7 @@ Author(s): Charles St.Louis (@CPSTL) Contributors: @LongForWisdom Status: Accepted Date of Amendment Submission: 2020-05-28 -Date of ratification: <yyyy-mm-dd> +Date of ratification: 2020-06-25 ``` ## Specification diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md index 7747f4f0d..396e8d448 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP2.md @@ -10,7 +10,7 @@ Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: Status: Accepted Date of Amendment Submission: 2020-05-27 -Date of ratification: <yyyy-mm-dd> +Date of ratification: 2020-06-25 ``` diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md index 7ecd0786c..43a9dd4fe 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP3.md @@ -8,7 +8,7 @@ Author(s): Charles St.Louis (@CPSTL), @LongForWisdom, Rune Christensen (@Rune23) Contributors: Status: Accepted Date of Amendment Submission: 2020-05-28 -Date of ratification: <yyyy-mm-dd> +Date of ratification: 2020-06-25 ``` ## Specification diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md index c5a771b3f..086c82f9f 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP4.md @@ -9,7 +9,7 @@ Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: Status: Accepted Date of Amendment Submission: 2020-05-28 -Date of ratification: <yyyy-mm-dd> +Date of ratification: 2020-06-25 ``` ## Specification diff --git a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md index fdb68df88..48760461f 100644 --- a/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md +++ b/MIP7/MIP7c3-Subproposals/MIP7c3-SP2.md @@ -8,7 +8,7 @@ Author(s): Cyrus Younessi (@DonutJr) Contributors: n/a Status: Accepted Date Applied: 2020-06-01 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-06-25 --- Domain Role: Risk Domain Team Facilitator Proposed Applicant: Cyrus Younessi From 54fe85c4c5eb2a0bd558ec8bc5d1a39979557134 Mon Sep 17 00:00:00 2001 From: CPSTL <32653033+CPSTL@users.noreply.github.com> Date: Fri, 17 Jul 2020 13:09:27 -0400 Subject: [PATCH 50/50] Update MIP7 - Add Risk Team --- MIP7/mip7.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/MIP7/mip7.md b/MIP7/mip7.md index 70f88fe03..97e63a6c0 100644 --- a/MIP7/mip7.md +++ b/MIP7/mip7.md @@ -85,6 +85,10 @@ Team Name: The name of the onboarded domain team. - **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:** +- **Team Name:** Red Team + - **Sub-proposal Number (MIP7c3-SP):** 2 + - **Domain:** Risk + - **Date Added:** 2020-06-25 [Ratification Vote](https://mkrgov.science/executive/0x1d51ca29e35b6ce30167f634dd21376da1341d9b) **4. Legal Domain Teams:**