MIP39c2-SP21: Adding MakerLabs Core Unit

MIP39c2-SP21: Adding MakerLabs Core Unit


MIP39c2-SP#: 21
Author(s): @colrad, @urbanisierung, Tim Schuppener (@ultraschuppi)
Contributors: -
Tags: core-unit, cu-skunk-001, mandate
Status: Formal Submission
Date Applied: 2021-07-19
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP39c2-SP21 adds MakerLabs Core Unit for building and validating MVPs.



Good, new products usually emerge from high-risk endeavours. In the world of traditional software engineering, building a Minimum Viable Product either validates or invalidates your product idea. However, real validation is gained from the market when the MVP is released to the public. Real validation is not the promise to use the product but only the product usage itself.

While the current setup of the Maker DAO allows for incremental and low-risk improvement of the existing product, the current framework is not set up for pursuing revolutionary product ideas.

Therefore we propose a new MakerLabs Core Unit that implements new product ideas spanning across the full stack of decentralized technologies.

Having full technological responsibility inside a single Core Unit would give MakerLabs the autonomy to move fast and ultimately test and validate new ideas early.


The MakerLabs Core Unit Team responsibilities essentially revolve around the rapid implementation of new product ideas grounded in solid full-stack engineering practices, including iterative product improvements to find Product Market Fit.

  1. Picking up a new product idea and a fast implementation of an MVP. A wide collection of diverse ideas already exists that can advance the Maker Ecosystem at different levels. The selection for the implementation of the next product lies with the Core Unit in discussion with the Maker Community.
  2. Make the product available and ensure easy entry. Implementing the MVP is only the first step. A product can only be used if it is accessible to a broad user base. This applies to both technical prerequisites and user experience. Technical barriers for users have to be low, and the product needs to be designed for usage without reading long documentation.
  3. Validation and quick iterations based on user feedback and metrics. The most important tool to validate a product is measuring and processing feedback. This involves the use of various channels of direct and indirect user interaction to obtain all the necessary information. The result of validation is binary: Product Market Fit achieved or not.


The MakerLabs Core Unit will have a flat management structure led by the facilitator who answers to the community of MKR holders. This Core Unit is being proposed as a single team.

Our team has already bootstrapped a couple of products and teams and brought them to market. After solving all the hard problems, we moved over to the next mission.

This experience and familiarity with Maker will allow us to be effective from Day 1, with little lead time, no need to recruit heavily and bring an established working process.

Core Unit ID


Core Unit Name


Core Unit Mandate

Product Implementation

Quickly develop new product ideas into usable MVPs.

  • Products are focused on increasing the Maker Ecosystems value and usability to end users.
  • The scope of the products would be strictly separated from the Maker Protocol. We want to build products upon the Maker Ecosystem, not modify or change but instead leverage what other Core Units e.g. Protocol Engineering or Oracles are building.


MVPs end up being deployed to test and production environments.

Move fast and break things is usually not something you would want to hear in the Maker Ecosystem. We will apply it on test environments but will switch to risk-capped innovation measures on production environments:

  • Risk to MKR value will be limited to whatever MKR holders find appropriate
  • Risk borne by early adopters will be limited to whatever MKR holders find appropriate

Full Stack Engineering

MakerLabs Core Unit will build all aspects of a product.

  • Smart Contracts
  • User Frontends
  • Metrics


  • User Feedback
  • Measure, measure, measure
  • Quick, small iterations to improve the product based on new insights
  • If a product idea is successfully validated, MakerLabs Core Unit will propose plans for the next steps

The first product we’d like to tackle is eurDai. From deploying the eurDai Contracts, to building a eurDai wallet to metrics measuring its success or failure.


I like this. What is the initial thought about transitioning successful products out of this CU? Or will successful products stay within this CU?

The primary purpose is about prototyping new product ideas and the very last step on the happy path is to propose a plan how to move forward. Maybe naive, but I guess that if something works pretty good there will always be someone interested in picking it up. But let’s cross that bridge when we get there :wink:

1 Like

Hi @ultraschuppi - exciting proposal you have here!

thumbs up for taking on eurDai right away

I have some questions, forgive me if some of them are not so smart:

  1. When you say Minimum Viable Product (MVP) do you mean testnet viable, or mainnet viable?
  2. Is this a sort of a “Space-x method”? Crash and burn is certain, but you iterate really fast towards something that works?
  3. If you add a frontend to a MVP (as you plan), are you not quite close to the real thing?
  4. When you complete the MVP, who will take over and do the rest? Why not do the rest of the job while you are on it? What is lacking here - will or patience?

and now for the interface questions:

  1. Which groups are you going to interface with? I guess PE will be involved at some point or not? Could SKUNK do some of the tasks that PE would normally do as a sort of apprentice program?
  2. Will SKUNK be a good match with GROW? You could do proof of concept work? That is MVP anyway? Again - take some of the workload off PE?
  3. How about RWA? There are now 4 or 5 possible methods for getting into US Treasuries - is this something SKUNK could support?
  4. Is SKUNK willing to do collateral applications? Like the less painful ones to start?

Hi @Planet_X

Thank you for your great questions!

Even though I’m not as well versed with the Maker Community as @ultraschuppi, I hope I can clarify some of them.

If your friend says “It’s a great product!”, then that is certainly nice to hear but no real validation.

We think validation can only be proven when people commit to the product. Be it money, by paying for it. Or be it time, by using it.

Therefore we have to deploy the MVP to the mainnet. We believe validation can never happen on testnet.

I like this “Space-X” analogy but I think there is a major difference. Early Space-X and similar projects like ITER and Manhattan would have failed because the goal is technically not feasible or too expensive.

Software engineering has the great advantage that it’s pretty cheap. The greatest challenge in new software projects is to make something people want, or more precisely make something people want to pay for.

So a crash and burn for MakerLabs is not spending 12m on an exploding rocket. But in the end having a rocket that nobody wants to use.

Therefore we want to build rockets very fast/cheap and measure if people actually want to use the rocket.

If we can prove that people are actually paying for rockets, other teams can step in and build even greater and more efficient rockets.

I tend to disagree. Let’s look at something like Facebook. One could argue that the original thefacebook, marketed to College Students was a MVP. But the Facebook we have today is completely different to thefacebook of 2003.

The differentiation between MVP and the real thing is even more important for the financial products we are building.

  • Auditing and hardening the Smart Contract would slow us down. We want all our MVPs to be risk-capped.
  • Supporting the Product for millions of users would drain our small team of all resource
  • Marketing the Product is not something that lies within our expertise
  • Exploiting a market opportunity, going down the rabbit hole of optimization, would lead us away from what we do best. Building and validating unproven Products.

Transforming a MVP to the real thing, is usually an endeavour bigger than building the MVP.

This would include all the auditing/hardening work, removing the risk-caps, building an infrastructure for support and monitoring … and adding new features. Maybe even transforming the Product to adjust it to changing customers needs.

There are typically 2 types of strategies: exploration and exploitation.

We as a team draw the most satisfaction from exploration, this is something we excel at.

Other people and teams on the other hand are great at exploiting existing market opportunities.

There are a lot of exciting product ideas in the maker community that sound worth pursuing. We want to validate them and then come back to the community with either “Great Idea and it found adoption” or “Great Idea but nobody is really using it”

In both cases the community can then decide on how to move forward.

Even in the case of a successfully validated Product, the community could decide not to move forward (because it does not match the vision of Maker …)

Or the community could decide to grant a Budget for exploiting the opportunity more deeply.

In the case of an unsuccessful validation the community could propose adjustments for revalidation or decide to drop it for good.

We see MakerLabs as a tool for the Maker Community to explore and validate Product Ideas. As any tool we serve one specific purpose.

Like a skrewdriver we excel at driving screws but we are less efficient at driving nails.

We will interact with all interfaces that are necessary to implement the MVP. This also means that we have no limitations in the technology stack and may also implement smart contracts (for example).

However, in order to move forward as autonomously as possible, we would like to act independent of other Core Units and request as little support as possible from other Core Units.

We picked eurDai as the first product because:

  • We think we can implement it without changes to PEs domain

  • We probably don’t need to make profound adjustments to the smart contracts

  • We like the product idea and think it is worth pushing forward.

  • Some people in the Maker Community want eurDai but nobody has proven that it will be used

The inherent difference between PoC and MVP is that PoC usually proves the technical feasibility. MVP proves the market feasibility.

If there are topics that call for a MVP (user/market validation) and contain changes to the existing Maker Smart Contract then MakerLabs would be glad to create Pull Requests to the PE repository.

But I think before this can happen, MakerLabs has to prove itself to PE and the Maker Community, that we can write sound and safe Smart Contracts and that we would not be a burden to PE.

We haven’t thought so much about RWA topics so far (and eurDai will probably suck some time anyway) - I wouldn’t reject any topic without digging into it.

I don’t think we would add great value to collateral applications. At least for me, adding new collateral types seems like a proven process done by the Risk Team, Oracles and PE. It’s like adding a new Feature to an already great Product.

From my point of view this falls in the exploitation category and therefore would be outside of MakerLabs domain.


Oh Em Gee! :smiling_face_with_three_hearts:

A small comment with regards to:

Speaking from experience in the PE team, I have seen that engaging newer members into the collateral onboarding process has been one of the quickest ways to get them up to speed on system interactions, tests, and to build an awareness of various protocol dependencies - it’s not so much that they add value to the process - in cases it slows down the process, which is fine because the longer term value outweighs the short term.

In saying this, I’m not suggesting that you become a collateral onboarding team, but just thought I’d share the value we have had in integrating people into this weekly (now fortnightly) ritual as a safe proving ground. Perhaps a similar process, even if you wanted to do it independently, may be of value.


I’m torn.

This proposal keeps me debating myself (not in a good way).

On the one hand… :muscle:t3::muscle:t3::muscle:t3:

  • I believe in the ability of @ultraschuppi (I’ve spent a lot of hours contributing with him and I can attest to his values, intelligence, and commitment.
  • I have spoken a couple of times with the rest of the team, and my general impression only improved.
  • We could not onboard these individuals faster: this team is already Maker.

But on the other… :anguished:

:hammer_and_wrench: Show me the mocks! (or a support team)

  • I would expect a team building MVPs to have:
    • UX Researchers
    • Designers
    • Prototypers
    • A product manager
    • and I’m probably forgetting more roles, but I haven’t prototyped in what feels like a lifetime.

PS, I get a similar feeling when the brilliant minds from @Protocol-Engineering work on a front end, a MIP, or a proposal. We need to enable the smarter ones to spend as much time as possible working on tough problems.

:dart: A clear purpose: scaling Maker

Is this a group of smart people telling us that they need direction (speculation)? Again: are we wasting brilliant minds playing with toys (or MVPs) instead of focusing on the next big problem? What are the areas that we need to focus on to scale Maker?

:toolbox: The drawer of old toys

I’m afraid (speculation again) that we are going to end up with a bunch of tools that people might like, but:

  • we don’t have the bandwidth to maintain them (taking this statement to the extreme, we might be creating a problem)
  • not a lot of people use it (niche tools)
  • are not a full product (yes, I know what MVP stands for, but still)

But decentralization… :man_shrugging:t2:

If the smartest doctor wants to focus on plastic surgery instead of longevity*, there’s not a lot we can do. We can only make sure that the incentives are in the right place.

As mentioned: if this team wants to work on creating 3D NFTs for Maker, we should probably let them, but… argh.

*) I reserve the right to change this bad analogy for a better one.


Not sure there is a need to speculate here.

  • MakerDAO wants eurDAI. In my view, there is a consensus that it is a big opportunity for MakerDAO but competition is coming.
  • MakerLabs will work on eurDAI. It will most likely take a long time just to get started.
  • @ultraschuppi has shown the willingness to do whatever it takes for the DAO. We need someone to write signal requests, he does the jobs (countless times). Figuring out the rates, guess who created the MakerDAO Open Market Committee (quite useful to understand what is needed for eurDAI). His entrepreneurial mindset is what we need for such a project.
  • The team is already productive with the delegates analytics UI.
  • Cost is under control.

While I agree that in the long run we may need dedicated people specializing in those functions, I absolutely disagree on the need to get them into the team right now. Sure you need the capabilities (up to a certain level) to start the show - but we already have them in the current team.

I would not hire a full time UX Researcher, Designer, Product Manager at the very beginning of this CU. Let’s start small and grow (if needed) by the time we realize it makes sense to get someone specialized on board.

Too many cooks spoil the broth.

I’d argue that an MVP is a valuable tool, not a Toy. (Else no Company in their right mind would build MVPs)
When you say Maker should fix the “big Problems” to “scale Maker”, then I agree.
But this is not the purpose of MakerLabs.
The purpose of MakerLabs is to find new Opportunities in a professional manner.

The question is: Does the Maker Community deem an opportunity exploring CU important or not.

The only difference between science and fucking around is writing it down - Mythbusters

That’s why we think defining a threshold that sets a level for “achieved Product Market Fit” beforehand is so important.
I’d like to think of it like a pop-up store. Let’s test Unicorn-poo flavoured Icecream, set up a Store for a limited amount of time and measure sales. If it’s beyond a predefined threshold then we open an even bigger, permanent store. If not we close for good … sorry to the 15 very satisfied customers that enjoyed our product but you are not enough to support our business case.

MVP’s are like pop-up stores. They should not live very long. Either they transform into a big beautiful Butterfly or they should be put down.


Again, and maybe my post wasn’t clear enough: this team is gold. We need them on board.

Speculation arises when things are not clear (or de-risked).

It’s called MakerLabs, not EURDai Core Unit. I would be much more inclined to vote for a Core Unit that has the latter name. I would even throw in some grant money to do previous research before working on this (SES might have offered this :wink: ).

I’m sure they can also write poetry for the DAO and be productive, but these guys are WAY smarter than that UI (the ones that can write smart contracts smart).

@ultraschuppi, you’re one of the smartest persons that I know. I know that you can do UIs (or research, or the long list of et ceteras that you’re proposing (you can probably become a successful TikTokker if you set your mind to it :wink: )).

I also know that you will do whatever you like doing best (and that’s perfectly fine). I also know that I will support you in your future endeavours.


  • more focus (ideally on a big problem)
  • more focus (ideally doing what you do best)
  • I will support you regardless. <3

we would like to push this to Formal Submission please :slight_smile:


Best team FS push award goes to MakerLabs !!! :fireworks:


I really had to look here.

The point here is that when it comes to new business ventures and longer term plans and projects this would have to be well integrated into Growth and coordinate quite a bit with PE (can it be done, how, etc.) The idea for this to be a separate group with its own funding and lack of high level deliverable metrics and reporting means it should actually start off as a sub-group under one of the CUs and Growth seems a natural place.

Frankly I want to hear from @Nadia on whether she thinks she wants another completely independent CU group doing long term planning or whether she would prefer MakerLabs actually be a sub-group under GROWTH CU which honestly is where I think this should sit.

I want to vote no to this for the above reasons, but without real input or validation here will simply will abstain.

One point - I too feel like the members chosen are valuable members of the DAO, I just think organizationally such a group should sit under GROWTH because everything these guys are going to come up with is basically going to land in GROWTH CU lap.

This is dangerous: are you asking a CU-facilitator to support or not the generation of a new CU (possibly with some intersections) and/or to include it or not in her own? :roll_eyes:

It’s ok in this specific case, since @Nadia is a healthy member of the community and would not respond out of self-interest, but in general we should avoid this type of setup imho.

We want to promote decentralisation of CUs as much as possible while keeping a reasonable efficiency.


We already have an incubation program with SES if someone wants to go that route.

1 Like

This is ‘dangerous’. Seriously? We ask for other CU input on a number of topics - why not ask a CU whose work will be impacted by another whether she would rather have another CU or just a budget to hire for the specific task of ‘long term growth’.

My point here is Growth may already have some long term plans. Now they may not be setup to do the eurDAI - that is fine. If this was the only thing this CU was tasked with I would be asking why do we need a CU for it, rather than just some bounties being put up for design, implementation and let biz sell it. Instead this CU having that as its first task also wants longer term funding for doing longer term growth stuff. Personally if I was the CU of growth I’d feel a bit slighted this group didn’t approach me first for a grant and/or discuss whether it makes sense to have a different CU since these two units are likely going to have overlap. I have no clue of what internal discussions go on…

I have said before I think multiple CUs for redundancy and quality assurance is a good thing. But given there is no model for how to shop tasks between such units or who manages authorities with the responsibilities I don’t see how this doesn’t turn into a bit of a management mess.

Sure we can let more CUs fly but frankly when a new CU is being proposed that has significant overlap with another I consider it courtesy to at least have people who will be affected weigh in one way or another. I consider communication ‘healthy’, decentralization actually means higher levels of communication not less.

1 Like

Growth’s mandate is to grow Maker’s distributions channels through partnerships. This is why our focus by now is on:

  1. creating alliances with new players in the PSM (Paxos’s PSM has generated almost 500m DAI, and they are working on the integration of DAI in their APIs that will open new rails for DAI)
  2. The institutional vault product (which will help Maker to increase the TVL of ETH and wBTC, increasing DAI in the market)
  3. And the integration with companies from all over the world helping us to increase DAI awareness and creating channels for people to access DAI.

We are constantly thinking about what other initiatives we can do. Crypto is a continuously changing environment, and to be successful with our mandate, we have to understand what’s happening around us and create a Maker flavor for that (DAI+Gamers, DAI+NFTs, DAI+Institutions…). Some time ago, @MarianoDP posted an open question to the community about products that could help us create a Maker Nation. It is out of our mandate to have a dev team that could work on that, but we can bring the ideas to the Maker community and try to find out there, teams doing something similar and convince them to integrate the Maker vision by creating a partnership with them.

I think we (Growth team and the community in general) have a lot of ideas of what products we want to see as part of that Maker Nation. Besides what Mariano posted, these are other things we asked for in the last ETHOnline hackathon:

  1. An auction keeper implementation to further decentralize and democratize auction participation.
  2. A GUI for PSM on IPFS and/or PSM bridge: So we could link our PSM’s and do any type of swap we are capable of doing. A user that has Pax, for example, could swap to USDC or vice versa by just paying the tin to get Dai, and then in the same transaction, it would put Dai into the other PSM and getting the token. The tout is zero going out anyways.
  3. A furocombo-like web for arbitrage with PSM and Flash Mint.
  4. An optimistic roll up test environment to facilitate the testing of L2 code. Extra points for leveraging Dapptools.

Because of the complexity of Maker and as we haven’t been actively participating in hackathons, none of the teams worked on that.

So, my thoughts about the Maker Nation products:

  • I love the idea
  • I think having more products around Maker will help us to grow
  • It would be great to create more documentation and resources (like a wishlist of products) to have more people building around Maker
  • The scope of these products has to be very well defined and let the community decide if we want a product that takes one month or six months to be built.
  • euroDAI is an excellent solution, still, there are other ideas around, ones more simple than euroDAI, of course with less impact, but I think that’s up to the community to decide. If that’s the product we decide to build, I don’t know how an MVP will work, and I don’t know if we as Growth can go outside and talk with partners about a euroDAI that hasn’t been audited.
  • I trust in @ultraschuppi skills for this. I have seen how he’s always thinking about how to bring new things to Maker

I would highlight that this Core Unit is currently not passing due to @PaperImperium voting against it. Below is his reasoning.

First on a “bit rushed” part, the discussion started in February (Declaration of Intent and the eurDAI thread). The Declaration of Intent was voted in April (a case where bureaucracy killed momentum). You might have missed that as it was happening before you joined. Moreover, @ultraschuppi is a consistent contributor and everyone can get an opinion on the value he created for the protocol (Autonomous MakerDAO member, MOMC member, signal request master, …).

Secondly, the whole idea of gating the CU to PE, Growth, and/or SES is centralization. PE doesn’t see eurDAI as a priority (which makes 100% sense, which is why eurDAI is awesome to get a new CU started). Are we saying that eurDAI (something community approved) will never see the light even when sounds people are ready to work on it?

Finally, there is a belief that this CU will launch the project and move on no matter what and it will be PE role to clean the mess. This is short-sighted. @ultraschuppi showed to be responsible. We need entrepreneurs like him. I think the proposal is here, take it or leave it.

I encourage people to voice their opinion on the poll. Currently, it’s not passing because it seemed a bit rushed. Scientific governance in action :slight_smile: .


I will refer you to the recent launch video session and the discussion there.

There is nothing wrong with taking a month to build out more details on how to hand off large projects, or to pivot to pure R&D of smaller products.

As I stated in my communication about my current votes, I encourage the applicants to flesh out the business plan a bit more. My apologies for not paying more attention to this earlier in the process.