# MIP8: Domain Greenlight ## Preamble ``` MIP#: 8 Title: Domain Greenlight Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X) Tags: process, collateral-onboarding, mip-set, collateral-onboarding-mipset Type: Process Status: Obsolete Date Proposed: 2020-04-06 Date Ratified: 2020-05-02 Last Amended: 2020-06-25 Dependencies: n/a Replaces: n/a Ratification Poll URL: Forum URL: https://forum.makerdao.com/t/mip8-domain-greenlight/1910 Extra: This MIP has been amended. See [MIP4c2-SP8](https://mips.makerdao.com/mips/details/MIP4c2SP8). The original version can be found [here](https://github.com/makerdao/mips/blob/a563ad964feb56e1da47f372b3df729cf1112108/MIP8/mip8.md). Extra: This MIP has been removed via [MIP4c4-SP1](https://github.com/makerdao/mips/blob/master/MIP4/MIP4c4-Subproposals/MIP4c4-SP1.md). ``` ## References No referenced materials. ## Sentence Summary 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 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 Process** Defines the domain greenlight process and its interaction with the collateral onboarding process. **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 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 ### MIP8c1: Domain Greenlight Process - 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. #### Domain Greenlight Process Overview Diagram mip8-a --- ### MIP8c2: Domain Greenlight Outcomes **Greenlit** - If **greenlit**, the domain team has signaled their willingness to complete the domain work required to add the collateral asset to the Maker Protocol. **Deferred** - 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. **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 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. ---