MIP39c2-SP12: Adding Collateral Engineering Services Core Unit

MIP39c2-SP12: Adding Collateral Engineering Services Core Unit


MIP39c2-SP#: 12
Author(s): @monkey.irish
Tags: collateral-eng, collateral-onboard, collateral-offboard, core-unit, mip-set, ces-001, cob-001
Status: Formal Submission (FS)
Date Applied: 2021-05-12
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP39c2-SP12 adds Collateral Engineering Services Core Unit, CES-001.

For more information on the changes to this MIP, please see:



MakerDAO and the ecosystem is faced with several critical supply side issues.

The pace of innovation in the cryptocurrency industry is outstripping the protocol’s ability to keep up with it. To thrive in today’s market, we not only have to maintain our first mover position, we need to continue increase the velocity of innovation to prevent an existential threat lurking amongst current DeFi players, the multichain future, and entry by traditional finance.

And how do we systematically attract and onboard the trillions of dollars of assets represented in the real world? We are off to a good start as the community is experimenting in different asset classes, with more approaches in the pipeline. Overall, the future growth and long-term success of the protocol is dependent upon the inclusion of a wide range of off-chain assets.

In my opinion, one of the highest priority is to have a Core Unit solely focused on the productization of collateral for the Maker protocol. Since the Multi-collateral Dai launch and with adoption of the collateral onboarding process by the community, we have done a great job with the resources available to us. Now, it’s time to greatly improve upon our capabilities to reach one trillion Dai and beyond. Focus is the only way to reach and exceed our supply goals.


Scale the Dai supply and manage the product collateral lifecycle.


Provide product management, engineering, & technical services for onboarding and offboarding collateral.

The Mission and Vision involves two mandates:

  1. Productization of collateral
  2. Building a sustainable Core Unit

Core Unit ID


Core Unit Name

Collateral Engineering Services Core Unit

Proposed Core Unit Facilitator


Core Unit Mandate

The Collateral Engineering Services Core Unit (CES) is a crucial service for growing the supply of the MakerDAO ecosystem and central to the protocol’s success. What follows is an explanation of the Core Unit mandates.

Productization of collateral

The mandate of productization contributes to the protocol’s success as we follow best practices in software Product Management.

If the goal is decentralization, and it is still a goal at this present moment, then Core Unit diversity and parallelization is a key part of that strategy. A one-to-one translation of teams from the Foundation into the DAO is the first logical step. Currently, you’re seeing a lot of this happening. So, what’s the next step? It’s the product oriented, holistic approach called “productization”.

The implementation leads to consolidating the collateral product and technical functions into one Core Unit. It’s really simple to say and a little more challenging to implement. Some of you might have worked on teams where cross-functional value was delivered with each software development iteration. I’m referring to a Product Team where you take a holistic approach in delivering incremental features. You can think of these features as specific collateral or collateral classes as they collectively roll up into the Product.

As more Core Units adopt the Product Team approach, this leads to parallel development efforts on the same code base. CES plans to assist and leverage the work the Sustainable Ecosystem Scaling Core Unit (SES) is undertaking to enable a scalable approach to support parallelization. This work will help create more diversity and reduce bottlenecks and dependencies on any one Core Unit.

All products have a lifecycle and need to be continuously assessed and managed. Our collateral is no different. The health of a product will also be tracked using metrics and dashboards to read out current statuses.

For clarity, some of the best practices of Product Management are:

  • Collaborative ownership of the product vision
  • Managing the product roadmap
  • Scoping and estimation with engineering teams
  • Managing the product and iteration backlogs
  • KPIs, OKRs, and reporting
  • Communication and collaboration with stakeholders

I’d also like to make sure I am very clear on one point. This Core Unit is a highly-collaborative effort and it’s a partnership, not competition, with the key stakeholders in the DAO. CES will continuously work with Protocol Engineering, Oracles, Risk, Real World Finance, and other critical stakeholders to:

  1. Identify and determine CES technical responsibilities
  2. Manage ongoing priorities with the product vision and roadmap
  3. Develop processes that work for all stakeholders
  4. Build competency, quality, and trust with the MakerDAO ecosystem

Key Takeaway

Productization is the way we scale the Dai supply.

Building a sustainable Core Unit

The mandate of sustainability is to ensure CES is a profitable entity for business continuity.

Managing our supply and collateral is the foundational activity that makes everything about the protocol work. It is important not to lose sight of this and to be grounded in the realities of what is required to create a sustainable, systematic, and repeatable practice. This is a top priority for the Core Unit.

One of the key aspects of every Core Unit is that of business continuity. As we know, some Core Units carry a high degree of risk if they do not operate properly. The question is, how do we architect a level of Core Unit stability as volatility continues to hit our industry and markets? The solution is to look at Core Units as a regular business.

Something to point out before we move forward. Functions within every business, entity, or organization, regardless of structure, have two general categories: 1) cost centers and 2) revenue generators. CES is specifically focused on supporting revenue generation for MakerDAO. This is an important point since future compensation, incentive, profitability, and sustainability models will be explored based upon performance.

As a business, the top operational aspects are:

Product-Market Fit

Since CES is a revenue generating function within MakerDAO, it is critical we have product-market fit for our collateral. Citing the article above, the top four reasons a new company fails are:

  1. No market need
  2. Ran out of cash
  3. Not the right team
  4. Got outcompeted

The first and fourth bullets are addressed with the productization mandate. The second and third are addressed by building a sustainable Core Unit.

Attract and Retain the Team

With a decentralized workforce, the challenge is to attract team members while organizing around a common mission and vision relating to the mandates of the Core Unit. I will also mention aligning with generally accepted MakerDAO objectives is also helpful. The cohesion of the team and support of the mission and vision are critical elements in retaining the best people.

The challenge CES faces is hiring permanent team members with a background in software architecture and/or software engineering with a comprehensive understanding of blockchain fundamentals, security architecture, consensus algorithms, formal modeling and verification, and smart contract Solidity/Ethereum development experience. We seek to balance the needs of the community, collateral objectives/outcomes, and the Core Unit to attract, hire, and retain top talent as it relates to compensation and incentive structures.

While individual incentives are important, incentivizing someone to achieve something, especially as a team, is much more sticky and can lead to better retention. As we establish CES, incentive models based upon contribution and performance will be presented to the community.

Expense Management

Runway is a critical aspect with a new business venture since it gives a team time to execute on the vision and strategy. Controlling expenses while building the right product-market fit is a delicate balance.

CES will operate on a funding model where the DAO allocates funds for periods of time. For example, an initial funding allocation for the first six months of operation then quarterly, semi-annual, or yearly after. The first tranche of funds will go into business formation, establishing the CES team, and productizing the collateral. See MIP40 for additional detail.

Generally speaking, month-to-month employee relationships are more costly and can introduce volatility. The goal is to move away from the transactional nature of a group of contractors to a model where the Core Unit has a shared vision and common goals along with incentive systems that support teamwork.

Funding and runway are also incentives to retain the team. Due to the shortage of qualified engineers in DeFi, we will be looking to attract product people and senior developers from outside of crypto and blockchain. Many people from other industries will find it challenging to commit to a month-to-month relationship with CES. Therefore the CES runway will introduce more stability and help as a recruiting and retention tool.


As the CES team and business model is established, the Core Unit will focus on profitability. Only when a business entity is profitable and has the necessary reserves does it have a chance to survive a prolonged downturn in the market or industry. Given the importance of CES and having the necessary reserves, in the way of profit, leads to business continuity and sustainability. See MIP40 for additional detail.

Key Takeaway

CES is a business venture that becomes a profitable entity.

Related Documents

MIP40c3-SP14 Collateral Engineering Services Core Unit Budget Proposal

MIP41c4-SP14: Facilitator Onboarding, Collateral Engineering Services Core Unit


Niiice! Does this mean you can ADD a Collateral Type like WOOFY much faster? And what about the ton of MIP6 applications going back 12-months?


Hi, all. To be clear, I am onboarding a brand new team. If you are interested in joining the team, please reach out to me. I have a lot more detail that I will be sharing shortly. It’s going to be a wild and fun ride! Come join us (me)!

It would be good to get an understanding of the team’s track record in doing the things promised above. There is a bunch of work that happens to make both crypto-native and non-crypto native assets work with the protocol, both in terms of understanding of the assets as well as coordination in the back-office with the multiple teams it involves. Having worked with both the crypto-native and the RWF, the frameworks are substantially different. So transparent track record in any of those is a huge requirement, in my view.


Thank you for these MIPs :slight_smile: My first thought reading this was “I would need to see well-known former Foundation employees post endorsements”. It’s crazy how much value those employees that have been active in chat/forums have created for themselves over time.

1 Like

A point of clarification on the team. I worked directly with the Foundation engineering teams for almost two years. I also organized and ran the first Collateral Onboarding processes internally at the Foundation. Today, the COB work is split across several teams in the community. In my opinion, having a consolidated focus for COB is critical. I would love to have some folks from the Protocol Engineering team to join but that team is interested in doing innovation work. I mean, I experienced the challenges first hand so I get it. So, this is a new team.

Based upon the team I build will determine what is possible with crypto native and RWF onboarding. Yes, right now, just about everything is different. We have to get past everything being a one off and build an assembly line for onboarding collateral. This isn’t going to happen overnight and all the work the RWF team and others are doing are very important to figure out that model.

First priority, we’ve got to get the crypto native assets onboarded in a systematic way. And everything changes with our current collateral types so we have to keep up with that too. That alone is a lot of work and it can happen in parallel with all the experimentation with real world assets.


Ok, so does this mean this is a “competitor” core unit to the existing Risk one? How do you see this operating in practice along with @Risk-Core-Unit ?

Would you be able to share with the community open-source/transparent work that has been done during these years?

Thanks for putting this proposal forward, @monkey.irish.

There are several initial comments I have regarding the structure of this and other proposals in the set. My main concern is the direct copying of large chunks of the Protocol Engineering proposals. It’s definitely not a good look and I’d advise you to rewrite those parts (or delete them for the time being).

Another thing that I noticed is that you don’t state your name in the proposals. I’d like to ask if this was intentional? I think it’d be desirable for the community to be able to tie your credentials to a name.

Please let me know (here or on rocket chat) if you need any further advice on structuring your proposals.

1 Like

No, not competitive. Risk, Oracles (that one coming today), and Smart Contracts core units are key in the creation of the COB core unit. Initially, there is a heavy collaboration between multiple core units and then a migration of identified responsibilities into the COB once trust and competency are built between the two teams.

As an example, when I spoke with Nik and Marc-Andre about their feedback, they would still be doing the code reviews since it’s their asses on the line if something happens. As trust builds, we’ll determine what makes sense for the COB to take over. The same would be true of Risk and Smart Contracts.

Would you be able to share with the community open-source/transparent work that has been done during these years?
This has been rolling out for a while. When Cyrus left, a community Risk team was formed. The Mandated Actors was another move. The Collateral Onboarding guides that were published not so long ago is another data point. The current collateral onboarding process was an iteration of what we created internally at the Foundation. It’s pretty much all out in the public source. As for me, I’ve been in the middle of the collateral onboarding during my tenure at the Foundation.

My role as an onboarder of a core unit and Facilitator is about organizing, facilitating, building, and leading the COB. I’ve been doing this work for three decades.

I did copy two sections from the PE core unit and I called those out. The only reason why those are there is due to the similarities of the teams but with the COB only focused on collateral. I’m happy to remove/rewrite them if that causes people any concern. I was the Agile coach for all of the Foundation engineering teams so most of that I was involved with the the Foundation’s smart contracts engineering team. :wink:

Yes. I’m a bit curious about this. I notice we have a few anonymous people in the community. The Foundation folks can vouch for me (or not). lol I decided to share less vs more only due to less attack vectors for me personally.

Done. I referenced them instead.

1 Like

I did copy two sections from the PE core unit and I called those out. The only reason why those are there is due to the similarities of the teams but with the COB only focused on collateral.

In my comment, I’m also referring to your budget proposal which very closely mirrors those of Protocol Engineering and SES.

I notice we have a few anonymous people in the community. The Foundation folks can vouch for me (or not). lol I decided to share less vs more only due to less attack vectors for me personally.

By all means, I’m the last person to push you if this was intentional.

That is very intentional. If you consider the core of COB does, I have the exact same needs at the PE core unit. I can change the words but the needs are the same. And it’s very intention that I followed Wouter’s SES budget template as well. It’s the best I’ve seen so far and I’m a big fan of DRY. I think you’ll see more of these templates due to the focus of SES and his incubation program.

I also support the MKR vesting proposal from SES.

Overall, we’re here to help each other especially when the needs are the same.

We don’t need to be referenced and can be copied (or templated from) as needed.

SES produces to scale the ecosystem, so I’m glad that some of our work is already helping the community.

I’m quite sure that @Derek shares the same view.


I’m not going to argue the merit of COB’s needs being the same as SES’s or PE’s as I have no experience or knowledge to support an argument.

I’m also not prescribing how a proposal should look like as long as it fits the appropriate MIP template. I do, however, believe that the precedent of wholly copying past proposals without reference is an undesirable one. Call it an academic bias but I think the community should at least know where a particular concept comes from.


I agree 100% with transparency and referencing so let me know if there are any other questions.

There was A LOT of work that went into getting the information into these MIPs. While the formats could appear to be exactly the same, the data present is very unique and based upon tons of feedback and experience.

Currently, to onboard a collateral, Risk (Risk or RWF), Oracles, and SC (PE) need to coordinate, each party taking responsibility for their part.

The PE team itself has a backlog of code they have produced but not yet audited. Most likely the same for Oracles.

The only way to increase speed is to give your team the “keys” to publish executives’ spells. Otherwise, your team will just add to the current backlog. Are we all confident to do that?

Indeed, and trust is built over time. Yet, your forum profile has not participated in anything other than proposing your core unit.


I want to react specifically to this point because it is a common misunderstanding. I added the silent assumption here.

This problem does not have to be. The reason is simply because no one has seriously looked into making smart contracts work parallelizable. What we do know, is that there is most likely some low hanging fruit there that should unblock a big chunk of the bottleneck.

In the case of collateral onboarding, it is particularly easy to create sandboxes that make it relatively safe for multiple development teams to deploy code. PE Engineering can design the sandbox so that it’s secure and guaranteed to remove tail end risk. Others can then plug into it with limited permissions.

We’re still working on our risks & opportunities analysis, but SES is most likely going to make this a priority, because we believe it may be the number one hurdle to scaling the ecosystem today.

It is perfectly possible to prepare for this by the time a core unit of this size is spun up. I would say that if we haven’t done it by then, we’re not doing well in terms of competition because other protocols definitely will.

We haven’t published much details yet, but this status update from a month ago should give a rough idea.


Thank you for hearing me out, I appreciate the recent changes to the proposals.

1 Like