makerdao / mips

Maker Improvement Proposals (MIPs)

Maker Improvement Proposals (MIPs)

Maker Improvement Proposals are the preferred mechanism for improving both Maker Governance and the Maker Protocol.

Through an open and documented process, community feedback will be collected to reach the broadest possible consensus on how the MakerDAO should evolve. Furthermore, MIPs provide a mechanism for any community member to define key issues and suggest changes and additions to the system. The MIPs process is conducted with a high level of transparency, rigor, and community input in order to minimize undesirable results.

For a current and historical view of proposed MIPs, please check out the MIPs Portal. In short, the portal should be the go-to resource for anyone wanting to explore MIPs (and the subproposals derived from them) in a reader-friendly manner. The Portal features smart-linking, on-hover previews, predefined common queries (Views), and advanced queries with logical operators and filters.

The MIP Framework Overview

Definitions

MIPs

MIPs are standardized documents subject to community feedback and voting that, once enacted, define the behavior of the Maker Governance and the Maker Protocol. Collectively, MIPs are the dynamic body of law that regulates MakerDAO at any given moment.

MIPs have two types: technical if they propose changes or additions to smart contracts code related to the Maker Protocol; or general otherwise.

Subproposals

Subproposals are a common recurring process. They are created and used as a means of proposing and enacting decisions nested within specific MIPs.

Just like MIPs, subproposals are standardized documents subject to voting. Once approved, they trigger a concrete action or state such as onboarding specific collateral, offboarding a Core Unit Facilitator, modifying a budget, and so forth.

Authoring and Proposing

In the spirit of DAOs, MIPs and subproposals can be brought forth and proposed by anyone.

If you're interested in proposing a MIP or think you might in the future, continue reading below for a quick overview of the process and how to get started.

Getting Started with MIPs (For Authors)

MIPs are written using Markdown and hosted on GitHub. You can always count on MIP Editors to help you out throughout the process, but having a passing knowledge of these tools will both benefit you with your overall proposal experience and make the process much smoother for all parties involved. Also, it's important to note right away that all MIPs and subproposals must conform to templates!

Markdown

Markdown is a very simple markup language for formatting text, i.e., adding headers, bullet lists, italicized text, et cetera. When working with MIPs, you should use GitHub-flavored Markdown.

GitHub's Mastering Markdown will get you up to speed in no time. The online Markdown editor HackMD is a solid platform for practice and production.

GitHub

GitHub is a code hosting platform for version control and collaboration built on git, a version control software. GitHub is complex and may seem daunting at first, but only a basic familiarity is necessary for our purposes.

We recommend that you read these two short guides: Hello World and Forking Projects.

Templates

• Technical MIPs must conform to the Technical MIP Template.
• General MIPs must conform to the General MIP Template.
• Subproposals, on the other hand, must each conform to a specific template referenced in the MIP that defines the process they instantiate.

Proposing

Once you've picked the appropriate template for your proposal and have a workable draft, the next steps are the following two tasks:

• Post the draft on the appropriate forum section
• Submit it to the GitHub MIP repository

After the two above tasks have been completed, MIP Editors will help assign a number for the proposal. The proposed MIP (or subproposal - they are treated the same way in terms of how to propose them) will then enter a period of community feedback (most frequently referred to as Request For Comments or RFC). This is a great opportunity to be proactive and interact with the broader community, take suggestions, and improve your proposal. Once the feedback period is over and you've incorporated your final changes, there will be a one-week period before you can formally submit the proposal for voting. Lastly, your proposal will go through a voting period.

If all goes well, by the end of the process you will have contributed a piece of MakerDAO legislation. And that's the gist of it!

For a more detailed breakdown of the procedure, please read MIP0c3.

IPFS Deployment

This repo contains a workflow that automatically deploys all MIPs to IPFS whenever a commit is pushed to the master branch. For this, we're using Filebase and Cloudflare, as you can see by going through said workflow.

This deployment can be accessed from https://mips-ipfs.makerdao.com/.

Contact Information

MIP Editors

Remember that MIP Editors are there to clarify the process and help you. Don't hesitate to reach out if you need assistance!

MIP Editor	Discord	GitHub	Forum
Pablo	blimpa_	@blimpa	@blimpa

Helpful Resources

• MIPs Discussion Channel
• MakerDAO MIPs Forum
• MakerDAO MIPs GitHub

mips's Issues

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

---

MIP Path: MIP41/MIP41c4-Subproposals/MIP41c4-SP35.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

url mangled?

On the MIPs portal, looking at https://mips.makerdao.com/mips/details/MIP40c3SP41

I see "MKR incentives have been determined based on the Program discussed here. This is a 3-year vesting plan with 1-year cliff vest."

The URL seems to mismatch what is in the GIT repo,

"MKR incentives have been determined based on the Program discussed here. This is a 3-year vesting plan with 1-year cliff vest."

Recording Bug Clicks - Clicked links not registering.

The click number is not incremented when right-clicked.

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

---

MIP Path: MIP41/MIP41c4-Subproposals/MIP41c4-SP35.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

---

MIP Path: MIP41/MIP41c4-Subproposals/MIP41c4-SP35.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

---

MIP Path: MIP41/MIP41c4-Subproposals/MIP41c4-SP35.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIP 46 missing tags

no tags in MIP 46

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIP 16 references MIP 3 which is superceded by MIP 51

MIP51 is the new monthly gov cycle that supercedes MIP3. However, MIP16 still refers to MIP3.

A quick git grep 'MIP3\W' also turns up,

MIP11/mip11.md:Dependencies: MIP0, MIP3, MIP7
MIP12/mip12.md:Dependencies: MIP0, MIP3, MIP7

Want a pull request to fix this?

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

Restructuring Branches

Problem:
Lots of Branches, lots of overhead to keep them straight, crappy UX for mip authors, etc

Solution:
Eliminate all but the master branch.

Discussion points:

• What does the process look like with one branch?
• ??? add more if you think of any

@CPSTL

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

The `IFlashMintReceiver` callback should take a `sender` parameter.

The receiver will always be a contract that needs to know the user that originated the transaction, and only flash.sol can safely say who that is. The callback interface should include a sender parameter, filled by flash.mint with msg.sender.

IFlashMintReceiver(_receiver).onFlashMint(msg.sender, _amount, fee, _data);

Leaving to the sender to fill data with the account to manipulate on the callback would be unsafe.

There are other mechanisms to safely pass the target account, if sender would not be an EOA. Namely you can either store the address of the target account in a state variable in the receiver, or use off-chain signatures embedded in data. Both methods are more complex and expensive than just having flash.sol state who is the sender.

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP76/MIP76.md

The `IFlashMintReceiver` callback should use a more generic function name.

execute is very generic and could clash with functionality on the receiver or on other callback interfaces.

I would recommend using onFlashMint, since the interface will likely be reused by other projects outside MakerDAO.

MIPS

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

---

MIP Path: MIP41/MIP41c4-Subproposals/MIP41c4-SP35.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

Should MIP7 be amended to include Operational Support Domain?

I see two camps of Domain teams forming, as implied by the MIPs.

1. Domain Teams required for Collateral Onboarding (MIP 07)
   Risk, Oracles, Smart Contracts, Legal

2. Other Domain Teams (Individual, seperate MIPs?)
   Operational Support and Governance Communications.

Is this something that we are being mindful about?

In addition to the Domain Teams being listed on MIP07, I saw that Domain Facilitators get onboarded through MIP07c3
ex: MIP7c3-SP5: Seb Risk Team & MIP7c3-SP6: SamM Smart Contracts

While the Operational Support Domain is only present in MIP28, and uses MIP28c7 for onboarding Operational Support Domain Team Facilitators
ex: MIP28c7-SP2: Juan Operational Support

Is this right? Do you think this structure makes sense? @amy-jung @CPSTL @LongForWisdom @juan-fintech

If something like a Governance Communications Domain Team forms, will it also have it's own separate MIP to house the definition and onboarding/offboarding proposals?

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

Should MIP16c3 be moved into MIP0 as MIP0c14?

I find it super random that MIP16c3: Limiting Governance to MIP-defined processes is in the Weekly Governance Cycle MIP. It sounds like this is a bit more fundamental to the overall MIPs framework as presented in MIP0.

Curious to hear thoughts for or against, and why.

Should MIP16c3 be moved into MIP0 as MIP0c14?

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP40/MIP40c3-Subproposals/MIP40c3-SP69.md

Provisional Technical Spec for MIPs Site

Website Specification

This is an initial specification for how the MakerDAO MIPs site ought to handle the process for educating people on what MIPs are; showing them how to submit MIPs; and setting up a sustainable process for handling and displaying in process, accepted and rejected MIPs.

Initial Template

An example site can be found here. It is built off this branch. All specifications below will refer to this codebase.

We have selected the Gatsby starter purpose-built for the MakerDAO community portal. We have done so for a number of reasons:

1. Coherent design + technical systems across all community-led project/products.
2. Ease of contributions, and more work to contribute to, for comm-dev developers.
3. Reusable code is cool.

Technical Specification

Overview

The new portal is great, however, the way it constructs - in particular - the sidenav content poses a problem for the MIPs site. Currently, the sidenav for any given route is generated for any and all files in that specific directory. So, the sidenav for "Learn" will display all the files under learn in the order you have specified. It simply runs a graphql query at build time and spits out each file as a nav item. We'll need a considerably more intelligent query/set of queries.

Repo Structure

The repo structure for MIPs is different. We want each MIP to have its own directory, such that the MIP and any templates or subproposals associated with it live in one, coherent place. This is especially useful when people submit new MIPs as PRs to the repo. Therefore, we need to fetch the sidenav organisation from the frontmatter status of each mip*.md file.

1. If the status == accepted, display it under the "Accepted" route. Ideally, we can generate a table on the accepted/index.mdx file of all Accepted MIPs, with their date, title, link.
2. If the status == RFC, display it under the "In Progress" route. Ideally, we can generate a table on the in-progress/index.mdx file of all In Progress MIPs, with their date, title, link. (Yes, there are many stages to "RFC", but we'll keep it simple for v1.)

Learn

The Learn route needs to fulfill two functions:

1. It will host a bunch of static content for educating people about how the MIPs process works, how to get involved, and what the aims are etc. The current sidenav algorithm would suffice for this, but:
2. It needs to host all the templates and subproposals from each relevant MIP directory as a part of showing people how to get involved and submit different SPs etc.

• This can be achieved either through a static json file (the easiest option), or a more coherent graphql query at build time, seeing as we need to update it anyway.
• The issue with the json file approach is translations and maintainer overhead. The issue with any other approach is considerable complexity of any query which would fulfill our needs.

Collateral Onboarding

1. This is an important - and likely the most active - part of the MIPs process, and so it gets it's own route. Technically, it's just MIP6c2 Sub Proposals. However, we'll need a sidenav that splits each application into accepted, in progress or rejected, like we have the header navigation, but for collateral applications specifically.
2. This is illustrated by the current directory setup in the initial repo.

Sub-proposals

Sub-proposals will be submitted as PRs to the specific subproposals directory, i.e. here. Once the front matter status has been changed from RFC to Accepted, the same logic should follow as for MIPs, except that they all need to be grouped under a collapsible menu item in the sidenav in either "In Progress" or "Accepted", depending on what their current status is.

Outputs

Critical:

1. A sidenav algorithm that sorts any mip*.md file into either the "Accepted" or "In Progress" route, and orders them according to number. We'll worry about rejected MIPs in v2.
2. Another (part to the) algorithm that allows us to do a static query/use a json file to organise content under the Learn route.
3. A third (part to the) algorithm which sorts "Collateral Onboarding" applications specifically into their own route, divided into three sections: "In Progress", "Accepted" and "Rejected".

This all ensures two critical features:

1. The repo structure stays largely the same, no critical files change names, and each MIP keeps its own directory, for ease of navigating in GH + submitting new MIPs.
2. MIP Editors just need to change 1 status field in the frontmatter of a single MIP file (or collateral application) in order for it to be updated across the site and appear in the right place.

Bonus:

1. A auto-generated table for "Accepted" and "In Progress" index pages to give an easy overview which need not be manually maintained.

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP95/MIP95.md

---

MIP Path: MIP97/MIP97.md

---

MIP Path: MIP98/MIP98.md

MIPs with problems to parse

Some problems where found on this MIPS:

MIP Path: MIP92/MIP92c5-Subproposals/MIP92c5-SP1.md