MIP39c2-SP12: Adding Collateral Engineering Services Core Unit

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

The problem here is the myth that genius senior devs are infallible, which leads to the thinking that governance has to put all their trust in a small closed group of special genius devs that are the only ones who will ever be good enough to write code for the maker protocol. But this way of thinking doesn’t hold water considering that even Rain and Lev - literally the two greatest geniuses in all of crypto who basically built the entire maker protocol by themselves - made some serious mistakes with the emergency shutdown module.

The solution is to move past branding specific people as special infallible genius devs (which im sure nobody actually wants to be), and instead opening up and branching out by relying on open, scalable processes and external audits by top tier auditing firms (which the genius devs can help identify and vet). For collateral onboarding I think it can be quite simple such as:

At least 1 audit and 2 weeks bug bounty for a small debt ceiling, 2 audits and 1 month live bug bounty for a large debt ceiling and 3 audits + 3 months liveness and bug bounty for unlimited debt ceiling (unlimited here meaning the risk team can set the parameters they want without worrying about technical risk factors related to the adapter, oracle, liquidation setup and other things related to the technical collateral onboarding itself).

That is of course just a basic example, but this kind of hypothetical process can be extremely scalable, and also be supported and improved by simultaneously making sure we have plenty of super geniuses in the ecosystem that also review and take part in the process - but we can’t put all of our trust in specific individuals, we have to put our trust in open processes because otherwise we will never scale, and then as we stretch everyone thin running on single thread mistakes will start to happen.


Very much looking forward to details on how you’ll do this.

Yes, I am well aware of the bottlenecks. I’ve been at the Foundation for almost two years and have had my hands all over this, MIP41c4-SP14: Facilitator Onboarding, Collateral Onboarding Core Unit. The past six months, I’ve been facilitating the Foundation’s dissolution. My roles have been 100% internal focused so I haven’t had a lot of community participation…until now. :wink:

While there are some technical challenges (there always are), there is another one with our current governance process as it relates to moving collateral through the system. There is a element of autonomy that is needed, with guardrails, in order for us to scale the collateral onboarding process.

To scale, it’s a function of three things: the COB team, the parallel development work (infrastructure), and changes to the governance process that allow for a much quicker, iterative approach when adding collateral.

To me, the biggest challenge is attracting, hiring, and retaining the COB team since solving any problem first starts with the people side of the equation. I’ve been doing that for 30 years so I feel pretty comfortable taking that challenge on.

Thanks for this. You’re aligned with the thinking here. In my conversations with the Foundation members and others, this is the theme that has emerged.

I believe we still need those genius senior devs. It’s just the right tool for the right job. That’s why I’ve also proposed using the COB as a training ground for newer devs into the Maker ecosystem. As an example, working with SES using a feeder system to allow new devs to cut their teeth on the protocol. It’s a perfect opportunity for those folks to work on classes of collateral that have already been figured out and are more mechanical.

For those new collateral types where innovation is required, we’ll need our best people on the job to figure it out then pass the work onto less experienced devs.

1 Like


I fully support this effort, but I think it will require both skill and timing to get this Core Unit going. What I think you are proposing is a unit composed of approximately 1/3 Engineering, 1/3 Oracles, and 1/3 Risk, which then (hopefully) are able to turn the collateral onboarding process from creating unique pieces of art into something more similar to serial production.

Initial thoughts from my side - mostly just brainstorming

  • Right now Maker has a collateral onboarding pace of about 2 types per month, but as far as I know, nobody has done any serious attempt to debottleneck the existing process.
  • So since you propose this CU it must be assumed that either debottlenecking will not happen or that the results will be poor - otherwise this CU makes no sense. Thoughts?
  • Possibly you will have to wait with growing this CU until the market crashes and more devs will be available
  • I guess you have probed around for support on this CU, but I think what would convince people would be a description of the process flow of the as-is situation, and then a description of the process flow within your proposed CU. Right now you are just promising to employ more people?

Thanks for the questions!

I’ll be speaking more about the plan and process at an upcoming Core Unit presentation scheduled for May 26th.

Overall, what I am proposing is an iterative process. When I managed collateral onboarding within the Foundation, it exposed the almost the same issues we’re having today in the community. Today, it’s more important than ever we figure out how scale the process. There is a low probability our current collateral onboarding system will meet our long-term needs.

The strategy involves three components: building and retaining the team, scaling the infrastructure, and creating autonomy.

I appreciate your thoughts around the team. Right now, we have a number of dependencies within other Core Units and this creates the bottlenecks. The team I am proposing to build will have elements from all three groups in order to streamline the process. I want to be clear this is a collaborative effort between the Oracle, PE, and Risk Core Units. There are always challenges in hiring people in any market. The goal is to focus on what’s best for the protocol.

On the infrastructure, it’s critical to take a holistic approach in developing our products. I think that is one thing missing to date. My background is delivering software with a product orientation. Functional approaches are important and make sense in some situations. In this case, we’re going to need to figure out how to have multiple teams working at the same time on smart contract functionality. My feeling is that the whole project will be in jeopardy if we don’t do this one thing. Plus, it’s really important to diversify responsibilities within the DAO.

When it comes to autonomy, all decisions are structured to go through Governance today. This alone will prevent the entire protocol from scaling. How do we modify our structure to accommodate a higher level of growth, while working under reasonable guardrails, and without introducing unreasonable risk into the system? Collateral onboarding provides a great opportunity for us to figure this out since debt ceilings are an automatic limiter of the system.

Please keep your comments coming as it’s going to be a collective effort to make all of us successful.


Hey @monkey.irish, in general I think having a Core Unit to focus on collateral onboarding is a good idea, will hold my thoughts on that to the end. Initially I’m just going to focus on and hopefully provide some useful comments to the contents of this MIP.

I don’t really understand how some of these principles are directly relevant to collateral onboarding.

Collateral Onboarding isn’t really very related to DAI adoption. The one tenuous connection is that it exposes those wanting to take leverage on that collateral to DAI. The rest: supply, attractiveness and market usage either don’t drive DAI adoption or aren’t really addressed by collateral onboarding.

This doesn’t really have anything to do with scientific governance?

Again, not sure what the statement has to do with gradual decentralization.

Feels a little like you had the principles in front of you and are trying to fit them to the collateral onboarding unit. Imo it would be better to just say: We want to really push and support pillars 4 and 5 in these ways. Rather than trying to connect 2 and 3 to this unit when they are only tangentially related.

Not sure this makes sense back-to-back? ‘If so’ - what are you referring to?

Not sure this really says much? In what way is high-quality collateral connected to a strong incentive system? What does compensation have to do with demand have to do with growth?

This is more of a ‘content’ comment rather than a ‘presentation’ comment. I’m not sure that we want a single core unit that is the guardian of how collateral makes its way into the protocol? This doesn’t sound like a decentralized solution. Like, you mentioned economics, risk and the DAO principles, but are you trying to claim that this unit should have the final say on levels of risk, economics and how the DAO principles apply?

Why is it good to encourage competition in this instance? Competition leads to a race to the bottom, and sacrificing long-term stability for short-term gain. If you turn collateral onboarding into a competition, you misalign the incentives of the risk-evaluation portion of collateral onboarding.

This is problematic, imo, for a number of reasons. First, those principles are old as hell, and very rarely referenced by anyone in the community at this point. Second, that vote took place at a time when MKR was much more centralized than it is now, and had different owners. Third, why exactly is this a part of the collateral onboarding mandate? Being a ‘guardian’ of these principles has nothing to do with collateral onboarding. The part about being ‘true to our community’ rings a bit false to me personally too, as you haven’t exactly been heavily involved in the community up to this point - at least not that I’ve noticed.

Have each of the core units mentioned here explicitly agreed to work with this core unit in this way?

Feels like agreeing this with critical stakeholders should be a prerequisite rather than something you figure out as you go? Like, what if critical stakeholders aren’t cooperative?

To summarize my thoughts after reading this, I would say that this seems like a good idea, but I am less sure of the execution. If I personally wanted to setup this core unit, I would do the following:

  1. Speak to PE, Oracles, Risk and GovAlpha and express my desire to help coordinate the collateral onboarding process and seek to get their buy-in to do this on a trial basis.
  2. Setup a meeting each week that covers collateral onboarding that includes the above stakeholders.
  3. Provide value to those stakeholders and make their jobs around collateral onboarding as easy as possible by providing coordination, setting expectations and handling communication with the community and collateral partners.
  4. Become indispensable to the process.
  5. Start hiring individuals to perform the more mundane duties that the existing stakeholders don’t want to handle.
  6. Expand the team to take over more and more of the process.

I would probably do a core unit proposal around step 3/4, initially budgeting only for my own time on a 3-month budget, then adding to the budget and responsibilities as I was able to hire.

The tl;dr of this is that I would actively provide value, and make myself indispensable to the process, and propose a budget that supported myself doing that, before attempting to onboard additional contributors.