MIP8: Domain Greenlight

MIP8: Domain Greenlight


MIP#: 8
Title: Domain Greenlight
Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23), Leo Jsaraceno (Mitote), Helge Andreas Qvam (@planet_X)
Type: Process
Status: <Assigned by MIP Editor>
Date Proposed: 2020-04-06
Dependencies: n/a
Replaces: n/a

Sentence Summary

MIP8 defines the process by which domain teams signal that a potential collateral type is worth the time spent investigating its inclusion in the Maker Protocol.

Paragraph Summary

This proposal aims to define the process where at least one domain team from each domain (Risk, Smart Contracts, Oracles, Legal, etc) “Greenlights” the collateral type (based on research) in order for the collateral onboarding process to proceed.

Component Summary

MIP8c1: The Domain Greenlight Requirements and Process
Defines the process, requirements and possible outcomes from the domain greenlight process.


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.

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: The Domain Greenlight Requirements and Process

  • 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 on-hold 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.
  • 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. This will then prevent the asset from being considered for collateral onboarding, or participating in any more community greenlight polls, even if they have already been in some.
  • 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.

Key Outcomes

  • If no issues are raised, the process continues in parallel with or past MIP9 (Community Greenlight).
  • If put on-hold a resumption criterion is defined and communicated clearly. Once all on-hold criteria are met, the process continues to MIP9 (Community Greenlight).
  • 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. The process continues to MIP9 (Community Greenlight).

Overall Process Overview Diagram


So, even if one of the domain teams rejects an application with an unresolvable tag, it continues on the MIP9…

In MIP9, it reads:

Which makes sense on it’s own and means MIP8 is really just a signal - a kind of “domain team gut feeling”.

However, let’s imagine the community + MKR holders come back and say: “No, actually, we want you to look into this collateral, please and thank you.” What happens then in the case of an unresolvable tag, which seems stronger than just a signal?

EDIT: resolved by:


In this case the domain team can say ‘well then find someone else, we’re not doing it’ (this is basically what the unresolvable tag means.)

If the community were dead set on the assets inclusion, we would have to find or create a willing team or teams to cover the domain work for any unaccounted for domains.

Note that currently the protocol doesn’t directly pay domain teams. This may change in the future if the protocol is paying them directly.

Currently there is no allotted review time associated with MIP6.

1 Like

The most updated version of MIP8 can be found here: https://github.com/makerdao/mips/tree/master/MIP8

1 Like

Hello! Where can I find process of how each teams turn on greenlight for Smart contract, Legal, Oracle, Risk.