Collateral Onboarding Process (v1)

Hello everyone! The Collateral Onboarding Process that @LongForWisdom (me), @Mitote, @Planet_X and @cyrus have been working on for the past few months is now at a stage where it is ready to be presented to the community at large.

The document is viewable both directly in this post and as a google-doc. The google doc has footnotes linking various concepts to the appropriate appendices that do not translate to markup. It also has a navigation pane. It’s probably easier to consume on google-docs. Additionally, this document doesn’t fit in a single forum post. Appendices can be found in the first reply.

Note that this is a long document, it has to be in order to capture the reasoning, requirements and responsible parties for each stage. Despite the work we’ve done on this, it’s quite possible that we’ve missed things. Please do read and comment on this as much as you can.

Thank you to everyone who helped produce this.

I will detail next steps in a reply to this topic. So without further ado, here is version 1 of the collateral onboarding process.

Collateral Onboarding Process

Introduction and the Scope of this Document

The goal of this document is to expedite the inclusion of diverse and desirable collateral into the Maker Protocol. The ultimate arbiters of which collateral types can be used in the Maker Protocol are MKR Token Holders, and they require information in order to make informed and rational decisions. For this reason, this process has been built to be as transparent as possible.

This document lays out a generalized process for adding collateral types to the Maker Protocol. If ratified, both MKR Token Holders and domain teams will be required to take part in this process. Additional collateral types are important because they will allow the Maker Protocol to scale up Dai supply while reducing the portfolio risk inherent in relying heavily on a single collateral type.

This document does not dictate the way in which individual domain teams complete their work on a collateral type, leaving this open to individual teams to decide. Instead it defines a series of stages and responsibilities for both MKR Token Holders, domain teams and the interested party. These stages and responsibilities make up the onboarding process.

Please note that this document will need to be adjusted in both the near and long term future, both in response to community feedback and as requirements change or become more clearly understood. Additionally, as new governance structures developed for the Maker Protocol this process will need to be adjusted to meet the requirements of those structures. This document should not be viewed as the end of the conversation with regard to on-boarding collateral to the Maker Protocol, but rather the beginning.

Process Summary

This process is divided into stages in order to ensure shared understanding of progress and accountability. A brief description of these stages follows. Each stage is broken down into sub-stages and described in more detail later in this document. Finally, several appendices have been added to explain new concepts that have arisen as a result of creating this document.

Pre-Process (Optional) - Business Development

This is an optional stage which describes the Business Development process that the Foundation is actively running in order to acquire good quality collateral partners for the Maker Protocol.

Stage 1 - Greenlight

In this stage, the collateral type is introduced to the Maker community. Both the governance community and individual domain teams are required to ‘greenlight’ the collateral, confirming that it is worth spending time and effort on analysis with the aim of bringing it into the Maker Protocol.

Stage 2 - Domain Work

In this stage, domain teams do any work that is required in order for the collateral to be added to the Maker Protocol. This includes producing risk parameters, setting up oracles, and creating any required smart contracts. This work is then presented to the Maker community.

Stage 3 - Ratification and Deployment

This is the final stage required to activate a collateral type in the Maker Protocol. Through a poll and an executive vote, MKR Token Holders confirm that the collateral type should be added with the proposed risk parameters.

Post-Process - Maintenance

This is an ongoing responsibility on behalf of Risk Teams in order to ensure that the Maker Protocol is correctly compensated for any additional risk accrued by the collateral type in the future.

Pre-Process (Optional) - Business Development


The Business Development team supports relationships with various organizations looking to engage with Maker. If helpful to a potential collateral partner, the Business Development team can offer information about the protocol and facilitate the onboarding process.


The Maker Foundation funds business development personnel to spread the Maker Protocol. Successful promotion of the protocol requires understanding of its core mechanics as well as communication skills. Business development interacts with many different organizations on behalf of the foundation. Relationships formed by business development personnel can lead to increased availability of quality collateral types. Successful communication between business development and the interested project smooths the onboarding process and helps to manage partner expectations. In the case of collateral partners that may be less familiar with the crypto space, it’s important to introduce them to this process and familiarize them with the various stakeholders. For example, pilot vault transactions give the partner a chance to better understand the mechanics of the Maker Protocol.

Potential Actions

  • Business Development can ensure that the partner understands the Collateral Onboarding Process and is provided with appropriate documentation.
  • Business Development may organise pilot transactions where the Maker Foundation mimics some functionality of the protocol for the collateral partner.
  • Business Development can opt to serve as a liaison between the collateral partner, domain teams and the community by operating as the “interested party” (detailed in Stage 2), keeping all parties involved and up-to-date.
    • Alternatively, informal methods of communication could be used to promote understanding if the partner expresses confusion.

Stage 1 - Greenlight

1.1 - Community Introduction


This initial stage introduces a collateral type to the Maker community. This is done through the means of the collateral application form and - optionally - a pitch presented to the community by the interested party. Once the application has been posted to the forum, a period of two weeks will be set aside for discussion by the community.


This step allows 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 MakerDAO. 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.

Actions and Responsible Parties

  • An interested party fills out the collateral application form and produces pitch materials selling the Maker community on the collateral’s inclusion. Both the application and pitch materials should be posted to the MakerDAO forum.
    • This post should be made in the Collateral Discussion subcategory within the Risk category.
    • This post should have the tag ‘collateral-app’
    • An ‘interested party’ refers to anybody willing to act as a stakeholder for this on-boarding process.
  • (Optional) It is suggested that the interested party interact with the MakerDAO community in order to allay potential concerns and generate support for the potential collateral.
  • (Optional) The interested party may organise a presentation or pitch meeting in order to convince the community of the value and safety of the proposed collateral asset and answer questions in a face-to-face setting.
    • These meetings should occur outside the weekly governance meeting on the grounds of time constraints.
    • These meetings should be recorded and made accessible to community members that are not able to participate directly.


At the end of two weeks, this process moves to stage 1.2 (Domain Greenlight), regardless of the level of discussion that the application has attracted from the community.

1.2 - Domain Greenlight


This is a pre-evaluation stage with the aim of identifying show-stopping problems before time is spent on a full evaluation of the collateral type. A team from each Domain (Risk, Integration, Oracle and Legal) must ‘greenlight’ the collateral in order for this process to proceed, signalling that they believe it is worth the time to perform a full evaluation in their respective domain.

This stage may happen in parallel to stage 1.1 (Community Introduction), but communication from the Domain teams should come within two weeks of the end of stage 1.1 (Community Introduction) at the latest.


This step minimizes the chance of the application being rejected or deferred after time has been spent on domain work.

Actions and Responsible Parties

  • If there are no issues that warrant stopping this process, then each domain team is responsible for communicating to the community that they are happy to proceed to a full evaluation. This communication should happen via the official forum.
  • 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 official forum. The domain team may or may not provide a reason for rejection as part of this communication at their own discretion.
  • 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 forums. This communication will include an explanation for the change in status and the criteria that should be met before they resume work.
  • Each Domain team is responsible for communicating with the other domain teams in order to make sure there are no problems with the collateral that could cause it to be rejected or deferred.


  • If no issues are raised, the process continues to stage 1.3 (Community Greenlight)
  • If deferred resumption criteria are defined and communicated clearly. Once all deferred criteria are met, the process continues to stage 1.3 (Community Greenlight).
  • If rejected by any domain team, that team has signaled 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 stage 1.3 (Community Greenlight).

1.3 - Community Greenlight


This stage has the aim of allowing MKR Token Holders to inform domain teams of their preferences. These preferences are expressed in the form of an on-chain poll. While domain teams are free to choose their own workload, an on-chain poll gives them insight into community sentiment for each collateral type.

Note that this stage may happen in parallel with stage 1.2 (Domain Greenlight). This poll lasts for two weeks.


It is important to gather the opinion of MKR Token Holders towards the proposed collateral asset before full domain work takes place in order to prevent work being wasted on undesirable collateral types.

Actions and Responsible Parties

  • The interested party is responsible for informing the Governance Facilitator(s) that the collateral application thread has reached stage 1.3 (Community Greenlight).
  • The Governance Facilitator(s) are responsible for creating a Community Greenlight Poll for the collateral type in question.
  • The Governance Facilitator(s) are responsible for maintaining a public 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.


  • Once the Community Greenlight Poll is complete. The process continues to stage 2.1 (Domain Work).

  • If the Community Greenlight Poll passes and Domain Greenlight 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.

Stage 2 - Domain Work

2.1 - Domain Work


This is a work stage for the domain teams (Risk, Integration, Oracle and Legal) to complete any domain specific work required for the collateral type to be added to the Maker Protocol. This includes but is not limited to:

  • A risk construct which will output risk parameters.
  • An analysis of legal risk.
  • An analysis of oracle risk.
  • An analysis of technical risk.
  • A technical audit and production of required collateral adaptor.
  • A maintenance plan for the collateral type in which the periodic review interval is defined.

Any work may or may not be outsourced to external teams, but must be validated by internal DAO teams.


Risk assessment is a core component of Maker Governance. All collateral types must undergo rigorous analysis. While outsourcing this work can increase domain teams capacity, there is the risk of misaligned incentives with outsourced work, this is guarded against by requiring external work to be validated by internal teams.

Actions and Responsible Parties

  • Each domain team is responsible for organising the completion of the work within their domain that is required to add the collateral type to the Maker Protocol.This work can either be completed in-house, out-sourced, or provided by the interested party that initiated this process.
  • Each domain team is responsible for keeping the community informed of their current work and projects, and any changes in the status of this collateral.


  • The domain work is completed to each team’s satisfaction. This process moves to stage 2.2 (Cross Domain Presentation)
  • A resolvable issue is identified by a domain team, and the collateral is marked as deferred. A resumption criteria is defined and communicated clearly. Once this criteria is met, stage 2.1 (Domain Work) is resumed.
  • An unresolvable issue is identified by a domain team. The collateral is rejected by that team and this process ends unless an alternative domain team can be found to complete the outstanding work for that domain.

2.2 - Cross Domain Presentation


This is a communication stage between the domain teams and the wider governance community. A representative from each domain team presents an overview of their domain work both within a governance meeting and the MakerDAO forum. Complete sets of information, models and presentation slides are published.


Transparency increases the community’s confidence in the proposed asset and their confidence in the domain teams. In addition, this step creates a historical record which can be used to measure performance.

Actions and Responsible Parties

  • Each domain team is responsible for creating their domain’s portion of a presentation for consumption by the governance community. This presentation should be published on the forum one week prior to the meeting in which it is presented.
  • Each domain team is responsible for seeing that the information and analysis for their domain is provided to the community. This information should be published on the forum one week prior to the meeting in which it is presented.
  • Each domain team is responsible for ensuring that the community’s comments and questions are addressed on the forum.
  • The Governance facilitator(s) are responsible for coordinating the scheduling of the combined presentation with the domain teams.
  • The Governance facilitator(s) are responsible for communicating the scheduled meeting to the wider community.


  • No major concerns are raised two weeks after the forum publication of the domain work. Process moves to stage 3.1 (Domain Work Approval Poll)
  • Major concerns are raised by the community and the appropriate domain team recognizes that their analysis is incomplete and they agree to address the issues. The domain team re-presents their domain work, highlighting the issues, fixes, and why the concerns were not initially identified. If the community signals willingness to proceed. Move to stage 3.1 (Domain Work Approval Poll)
  • Major concerns are raised by the community and the appropriate domain team contests these concerns. If no agreement can be reached on how to proceed, move to stage 3.1 (Domain Work Approval Poll) and allow the community to vote in the on-chain poll.

Stage 3 - Ratification and Deployment

3.1 - Domain Work Approval Poll


This is a ratification stage that allows MKR Token Holders to formally communicate their acceptance of the domain work completed in stage 2. The domain work approval poll does not directly enact the collateral for use in the protocol, but it signals acceptance prior to the creation of an executive vote.

Each collateral type will have an individual poll which will last for two weeks. This poll will include risk parameters and links to any risk, integration, oracle and legal work that has been provided.


MKR Token Holders must signal acceptance of the produced domain work before initiation is made into the protocol through an executive vote. Having a single bundled poll for all work slightly reduces governance overhead.

Actions and Responsible Parties

  • The Governance Facilitator(s) are responsible for composing the poll accurately, clearly, and completely.
  • The Domain teams are responsible for reviewing the poll for accuracy and communicating inaccuracies in a timely manner.
  • The Governance Facilitator(s) are responsible for adding the poll to the governance interface and ensuring that MKR holders have been informed through all commonly used communication channels.


  • The domain work approval poll passes. Move to stage 3.2 (Executive Vote)
  • The domain work approval poll fails to pass and the appropriate domain team recognizes that their analysis is incomplete and agrees to address the issues. The domain team presents an alternative set of work in a new on-chain poll. Once a version of this poll passes, move to stage 3.2 (Executive Vote).
  • The domain work approval poll fails to pass and the appropriate domain team contests the communities concerns. If no agreement can be reached on how to proceed, the collateral should be marked as rejected by the domain team in question. In order to continue to stage 3.2 (Executive Vote), a replacement domain team must present work that passes the Domain Work Approval Poll.

3.2 - Executive Vote


This is a ratification stage that enables the collateral for use within the Maker Protocol. The specific parameters of the debt instrument are enacted as voted in stage 3.1 (Domain Work Approval Poll), and borrowing is made available.


This vote is the action that enables a collateral type for use within the Maker Protocol.

Actions and Responsible Parties

  • The Governance Facilitator(s) are responsible for adding the executive vote to the on-chain governance system.
  • The Risk and Integration teams are responsible for ensuring that the executive spell contains what it is supposed to contain and nothing more.
  • MKR Token Holders are responsible for voting the collateral type into the Maker Protocol if they believe it should be added.


  • The executive vote passes and the collateral is enacted in the system and is available to be used. On-boarding process has concluded.
  • If the executive vote has not passed after one month and there are no exceptional circumstances that explain the executive vote’s failure to pass then this process should end and not be restarted for a period of at least six months.

Post-Process - Maintenance

Recurring management


This is an ongoing stage in which a Risk team continuously assesses the health of the Dai portfolio and specific collateral types within. The general plan for the management of each collateral as well as the system as a whole is outlined in the risk models voted by MKR token holders, however circumstances may require deviation from these plans. Generally management will come from risk teams, but other developing circumstances may require input from integration, oracle or legal teams.


Continuous risk management helps to ensure healthy functioning of the protocol.

Actions and Responsible Parties

  • The evaluating Risk Team is responsible for the maintenance of the collateral type added through this process and will be compensated for this on-going responsibility. This entails:
    • An emergency response process that allows the risk team to react to sudden changes in risk model input parameters.
      • Shifts in the fundamentals of a project may null or require adjustments in the risk model itself.
    • A periodic examination of the risk parameters to check their suitability given any changes to risk model or input parameters over the last period. The length of this period will have been defined as part of stage 2.1 (Domain Work)
      • It is suggested that periodic parameter changes for different collaterals share dates wherever possible for ease of management and to reduce governance overhead.
  • Maintenance work may be outsourced to willing parties, but the responsibility for keeping risk parameters up-to-date remains with the evaluating risk team.


  • A parameter change is determined as needed by the maintaining Risk Team, move to the Risk Parameter Changes post-process stage.
  • No parameter change is required at this time, the Risk Team continues to maintain the collateral package.

Risk Parameter Changes


This stage defines how changes should be made to risk parameters of a collateral currently in use within the Maker Protocol. The maintaining Risk team will bring concerns or direct proposals to the attention of the community based on changing circumstances. These changes should be confirmed via on-chain governance poll, and then will need to be enacted via executive vote.


As risks change over time, MKR token holders will need to be able to change parameters on existing collateral packages.

Actions and Responsible Parties

  • The evaluating Risk team is responsible for proposing changes to system parameters to the community based on their judgement of changing circumstances.
  • The Governance Facilitator(s) are responsible for running an on-chain governance poll to confirm risk parameter changes before they are added to an executive vote.
  • The Risk and Integrations teams are responsible for ensuring that any executive spells contain the changes the community intended and nothing more.
  • MKR Token Holders are responsible for voting on the proposed risk parameter changes.


  • The parameter change is made successfully and the collateral parameters are modified in the Maker Protocol.
  • If the parameter change is not successful and a Risk team feels able to address the communities concerns then an alternative parameter change should be proposed.
    • Note that other parties can always bring alternative arguments on what is the wisest parameters change
  • If the parameter change is not successful and the maintaining Risk team is unable to address the communities concerns then no change should be made. If the maintaining Risk team are no longer willing to maintain the collateral type given the disagreement then an alternative group should be given this responsibility. If no such group can be found, governance should consider deprecating the collateral package. This would mean:
    • Its debt ceiling being reduced to zero.
    • Giving consideration to forced liquidation of users of the collateral package if the risk is deemed to be immediate and severe.

Cont’d below



Appendix A - Domain Teams

At this stage, the types of domain teams required for collateral onboarding and their responsibilities are as follows:

Risk Teams - Responsible for developing and maintaining risk models and parameters to capture the risk involved in adding and maintaining a collateral type in the Maker Protocol.

Integration Teams - Responsible for the technical work required to add a collateral type to the Maker Protocol, including audit / validation work and production of adaptor contracts.

Oracle Teams - Responsible for setting up and maintaining oracle price sources and feeds required in order to add a collateral type to the Maker Protocol.

Legal Teams - Responsible for advising on the legal and regulatory risk of add a collateral type to the Maker Protocol.

In the interim stage, the following Foundation teams will coordinate and fulfil the following roles:

Risk Team - Interim Risk Team (Cyrus Younessi)

Integration Team - Foundation Integration and Smart Contract teams will divide this work as appropriate.

Oracle Teams - Interim Oracle Team (Nik Kunkel)

Legal Teams - TBD

There are open questions as to the eventual structure of the DAO and specifically domain teams. The initial model assumed by this process is that there will be Internal DAO Domain teams (Risk, Integration, Oracle and Legal) and that these teams will outsource work in order to increase their capacity. We suggest that, over time, the responsibility of these internal teams will change from direct domain work into a managerial and validation role.

It’s possible that regularly hired external teams can be moved into an internal role if there is both sufficient work for them, and they have shown consistent quality in their output.

It’s also possible that outsourced teams may fill multiple of the domain roles, in this case said outsource team is responsible for progress in each of the domains they are filling for a given application.

Appendix B - Collateral Application Form

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.

The suggested application questions are as follows:

  1. Who is the interested party for this collateral application?
  2. Provide a brief high level overview of the project, with a focus on the applying collateral token
  3. Provide a brief history of the project
  4. Link the whitepaper, documentation portals, and source code for the system(s) that interact with the proposed collateral, and all relevant ethereum addresses. If the system is complex, schematic(s) are especially appreciated.
  5. Link any available audits of the project. Both procedural and smart contract focused audits.
  6. Link to any active communities relating to your project.
  7. How is the applying collateral type currently used?
  8. Does one organization bear legal responsibility for the collateral? What jurisdiction does that organization reside in?
  9. Where does exchange for the asset occur?
  10. (Optional) List any possible oracle data sources for the proposed Collateral type.
  11. (Optional) List any parties interested in taking part in liquidations for the proposed Collateral type.

Appendix C - Deferred and Rejected

A situation may arise where a team identifies a risk that could threaten the solvency of the Maker Protocol if left unmitigated. In this situation each domain team has the right to Reject or Defer a collateral type in order to protect the Maker Protocol.


Deferred should be used when the domain team feels that the risk can be resolved through action on the part of the interested party, the team that created the token or another third party. In the case of a deferred judgement, strict criteria should be defined and published explaining what is required for the domain team to resume their work.


Rejected should be used when either:

  • The domain team feels that the risk posed to the Maker Protocol with the inclusion of this collateral type cannot be resolved.
  • The domain team is unwilling to continue work on the collateral type for any reason.

Marking a collateral type as rejected signals an immediate end to all related work conducted by the team making the declaration. Domain teams are not required to make the reason for the rejection public, however they are encouraged to do so in the interest of transparency.

Once a team has marked a collateral type as rejected if the community wishes to see progress, a willing domain team should be found to complete the work. There must always be at least one team willing to take responsibility for each domain.

If this occurs before or during any formal vote, immediate effort should be made by the rejecting team to inform MKR token holders of the rejection. This should take place on all popular social channels used by MKR token holders.

If a vote is active then MKR token holders will make the decision they see is appropriate. If the communication is judged to have lagged and the impression is that voters have not received the information in time to affect their vote, then a follow up poll/executive may be initialized for reversal at the discretion of the Governance Facilitator(s).

If rejection occurs after an executive vote has passed the governance facilitator must communicate with the rejecting team and initiate an emergency executive vote to address the issue. The format of such an emergency vote is not described by this document, but should follow best practices at the Governance Facilitator(s) discretion.

Appendix D - Community Greenlight Poll

An individual approval poll is created for each asset as part of stage 1.3 (Community Greenlight). This poll should use the following format (ETH is used as an example).


Should we prioritise asset ETH (Ether) to be added to the Maker Protocol?


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:

Options: Yes/No

Duration: Two weeks

In addition to creating an on-chain governance poll in the format above, the following actions should be taken by the Governance Facilitator(s):

  • The poll should be publicised in all relevant communication mediums.
  • When this poll is complete, a score should be calculated with which the collateral can be given a semi-formal ranking.
    • Score = Yes Votes - No Votes.

The Governance Facilitator(s) should maintain a forum thread that contains the current list of proposed collateral assets and their current status. For each proposed collateral asset, this list should include:

  • The score received in the community greenlight poll.
  • The MKR turnout in the community greenlight poll.
  • The date that the community greenlight poll was run.
  • The current position of the collateral within this process (if applicable.)
  • The domain teams taking responsibility for this collateral type (if applicable.)
  • Whether this collateral type has passed domain greenlight.
  • Any deferred or rejected statuses announced by any domain teams.

This list should be updated at least once every two weeks.

Once every six months, all of the greenlight polls should be re-run for assets that have not yet been added to the Maker Protocol. This should be announced at least one month ahead of time, and interested parties should be informed in case they wish to again campaign for their specific collateral asset prior to this poll. Organising these polls is the responsibility of the Governance Facilitator(s).

The Governance Facilitator(s) is empowered to organise ad-hoc repeats of community greenlight polls in the event of major structural changes in the risk, integration, oracle or legal landscapes for the asset in question if there is community consensus to do so.

Appendix E - Domain Work Approval Poll

A Domain work approval poll shows support for the underlying tools, code, data and theory used in determining risk parameters. One poll will represent the combined domain work presented to the community. This poll should use the following format (ETH is used as an example).


Do you approve of the Risk, Integration, Oracle and Legal domain work produced for collateral asset ETH (Ether) in preparation for its inclusion in the Maker Protocol?


If passed, this poll confirms approval for the work outlined by the domain teams in relation to including the asset ETH (Ether) in the Maker Protocol.

The full domain work put forward by each team can be found in the following forum threads:

Background and discussion can be found at the following forum thread:

Risk Parameters

Oracle price sources

Collateral Adaptor

Options: Yes/No

Duration: Two weeks

Appendix F - Timeline

This appendix is intended to be a summary of the time taken to go through this process.

  • Pre-Process - Business Development: Not possible to estimate.
  • Stage 1 - Greenlight: 4-7 weeks
    • 1.1. Community introduction: 2 weeks
    • 1.2. Domain Greenlight: 2 weeks (can overlap with 1.1)
    • 1.3. Community Greenlight: 2 weeks
  • Stage 2 - Domain Work: 4-15 weeks
    • 2.1. Domain work: 2-12 weeks
    • 2.2. Cross Domain Presentation: 2 weeks
  • Stage 3 - Ratification and Deployment: 3-6 weeks
    • 3.1. Domain Work Approval Poll: 2 weeks
    • 3.2. Executive vote: 4 weeks maximum
  • Post-Process - Maintenance: Ongoing
    • Recurring management - Ongoing
    • Risk Parameter Changes - 2-4 weeks

Best Case: 11 weeks (~2.5 months)

Average Case: 19 weeks (~4.5 months)

Worst Case: 27 weeks (~6 months)


Collateral Onboarding Process - Next Steps

  • An overview of this process will be presented in this weeks governance and risk meeting.
  • At some point (hopefully soon) there will be a flow-chart.
  • An undefined period of time will be left for feedback and comments on this document. How long do you think we need to spend on this?
  • Further next steps will be directed by the community. How should we proceed once feedback has been gathered?

This is awesome!

I think it would be good to lay out some more concrete guidelines around the Domain Greenlight/Work (at least from a technical perspective). The Foundation Smart Contracts Team spent a lot of time looking into the technicals of a bunch of ERC20 tokens back before the launch of MCD so we have some good experience with this. I would be happy to set up a call or something to collaborate on our process.

Along these lines, it would also be good to think about where formal verification and audits fall in all of this. They can be very costly and time consuming processes (both in run time and work hours) and could even push the 12 week estimation if only 1 or 2 developers are working on it. From my experience working on collateral adaptor formal verification, it can be really tricky. It would be beneficial to make sure that the community is all on the same page with this before a poor dev team is stuck on some hard FV problem and it stalls the process.

These are probably all things for a more technical document to work alongside this one, but good things to start thinking about sooner rather than later.


Hi! Thanks for the feedback

We were avoiding trying to say how domain work should get done. Partly because it would take along time to gather that info from each group, and there seems to be some uncertainty at least on the risk end.

With that said my personal view is that communication is essential, so technical documents on how your processes goes would be very useful for everyone to thoroughly understand what kinda of work/timeline is necessary for technical collateral work.

Personally, I don’t think we or mkr holders should dictate how technical folk specifically do their work, but that gets into the larger debate about how domain teams should be structured/interact with governance. That debate is certainly on the horizon, yet probably out of scope for this document.

On the greenlight front I am interested in what you think makes sense for guidlines. I was always unsure what research each domain would want to do before feeling comfortable giving a greenlight.


Yeah I think this makes sense. I definitely don’t think it would be healthy to put limits on how work gets done or the tools people use to get that work done.

Regarding this, MKR holders do explicitly get to decide on the merit of the technical work done once it comes to actually adding collateral into the system. So, while I do not think they should be deciding how work is done, I do think that we should lay out a framework for what work should be done. For example, 100% code coverage with tests, a 3rd party audit, formal verification. Not saying all of these things should be required, but having a framework for the definition of a finished collateral adaptor would be very helpful. This will both help devs teams not having moving goal posts on their work and protect the community from having to explain why bad code is not accepted.

I will want to think a little more about this all and maybe the whole SC team can get together and chat about what we think is important. I will try to get back to this at some point soon.

1 Like

Totally agree. Mkr voters and dev team should have mutually understood expectations on what work should be done

1 Like

Slight miscommunication between the Foundation and I regarding roles and responsibilities around the Legal Domain. Legal Domain responsibility is now TBD.

1 Like

I just seen this, sorry about that if i’m a bit late. Again, great contents and great proposal.

I only think that the feedback period of even the setup period is too long. This could be done in way less time. Just saying. Time = money

1 Like

Has this thread & document been completely superseded by MIP6 or is there still something that should be discussed here instead of in MIP6?

Largely superseded by the collateral onboarding MIP set. That MIP set was based on this document though, so they are compatible.

MIP6 is a Mipified version of Stage 1.1 - Community Introduction.

1 Like