MIP7: Onboarding and Offboarding Domain Teams for Collateral Onboarding

MIP7: Onboarding and Offboarding Domain Teams (Collateral Onboarding)


MIP#: 7
Title: Onboarding and Offboarding Domain Teams (Collateral Onboarding)
Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23)
Contributors: @LongForWisdom, Leo Jsaraceno (@Mitote), Helge Andreas Qvam (@planet_X)
Type: Process
Status: Request for Comments (RFC)
Date Proposed: 2020-04-06
Dependencies: n/a
Replaces: n/a

Sentence Summary

MIP7 defines processes for onboarding and offboarding domain teams.

Paragraph Summary

The Domain Teams Onboarding & Offboarding proposal provides a predictable framework for both onboarding and offboarding domain teams required for the collateral onboarding process.

Component Summary

MIP7c1: Domain Team Descriptions
Describes the various domain teams and their responsibilities as they relate to the collateral onboarding process.

MIP7c2: The Current Domain Roles List
A list component that is kept up-to-date with the currently ratified domain teams.

MIP7c3: Domain Team onboarding
A process component that defines a method and a template that allows the onboarding of domain teams.

MIP7c4: Domain Team offboarding
A process component that defines a method and a template that allows the offboarding of domain teams.


The Maker Protocol requires a decentralized workforce in order to onboard new collateral assets. This MIP describes Domain Teams that are needed in the collateral onboarding process and highlights their special authority in the governance system to oversee critical processes and mitigate risk.

Specification / Proposal Details

MIP7c1: Domain Team Descriptions

  • Oracle Teams are responsible for designing oracle feed mechanisms for new collateral types, compelling the oracles to upgrade their nodes with new price feeds for new collateral types via MIP10, and creating the oracle work product for collateral onboarding.
  • Smart Contracts Teams are responsible for developing and deploying the collateral adapter for new collateral onboarding, and creating the technical work product for collateral onboarding proposals.
  • Risk Teams are responsible for creating the risk construct for a collateral onboarding proposal. As a part of the collateral on-boarding process, they also need to get a general model ratified on which they can base their risk construct.
  • Legal Teams are in some cases necessary for collateral onboarding, when dealing with assets that have legal claims attached to them. They create the legal work product for collateral onboarding.

MIP7c2: The Current Domain Roles List

This list can be amended through the onboarding (MIP7c3) and offboarding components (MIP7c4) of MIP7.

Entries into this list should follow the following template:

- Team Name: The name of the onboarded domain team.
- Sub-proposal Number (MIP7c3-SP): #
- Domain: The domain in which the team operates.
- Date Added: <date in (yyyy-mm-dd) format>

Active Domain Teams List

1. Oracle Domain Teams:

2. Smart Contracts Domain Teams:

3. Risk Domain Teams:

4. Legal Domain Teams:

MIP7c3: Domain Team Onboarding

  • Outcome: Domain team is either onboarding successfully or is rejected. If onboarded, the domain team is added to the The Current Domain Team Roles list defined in MIP7c2 by the MIP Editor.
  • Feedback Period: 3 months
  • Frozen Period: 1 month
  • Onboarding template:

 - Domain: <Ex: Risk>
 - Domain Team Name: <Ex: Risk Team A>
 - Author: <Person creating this proposal>
 - Date Applied: <date created on, in (yyyy-mm-dd) format>


-   Domain Team Introduction

	-   Brief introduction / pitch of the team, why they want to work.

-   Motivation

	-   Why the team wants to join a certain domain.

-   Work Credentials

	-   Full names of members
	-   Past work experience of members
-   Relevant Information
	- Github accounts
	- Forum accounts
	- Other 

MIP7c4: Domain Team offboarding

  • Outcome: The Domain team is offboarded and the Domain team is removed from the Current Domain Team Roles list defined in MIP7c2 by the MIP Editor.
  • Feedback Period: 0 days
  • Frozen Period: 0 days
  • Offboarding template:
    - Domain Team Name:   
    - Date of Proposed Removal: <date created on, in (yyyy-mm-dd) format>
    - Removal Motivation:
        - An explanation behind the motivation for the removal of the domain team. 
    - Relevant Information:
    	-  Links to evidence further backing the motivation behind the removal of the domain team.

1 Like

Doesn’t this mean that this MIP has MIP10 as a dependency? Or that MIP10 should list MIP7? One of the two seems required to me…

Why does the Domain Team Offboarding component have Feedback and Frozen periods of 0 day? Surely they’ll be given some room to dispute before being offboarded?

1 Like

Does this mean we need to onboard domain teams before they can work on collateral onboarding? Can the interim domain teams fulfill this role as is? If so, we probably should change this MIP to recognize the current interim teams as legitimate.

If not, then we need to onboard domain teams, which means we need to pass this MIP using MIP 2 correct? (since in the interim phase MIP 2 overrides MIP 0’s logic?)

Also the motivation says this MIP highlights domain teams special authority. What is this special authority specifically? I dont see anything constituting authority in this MIP. I am considering “authority” as the power to single-handedly enact enforceable change.

On a minor side note I definitely didn’t even indirectly write this one, The V1 onboarding guidelines didn’t define any on/off boarding of risk teams.

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