MIP39c2-SP10: Adding Sustainable Ecosystem Scaling Core Unit


MIP39c2-SP#: 10
Author(s): @wouter, @juanjuan
Status: Accepted
Date Applied: 2021-04-07
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP39c2-SP10 adds Core Unit SES-001: Sustainable Ecosystem Scaling.


Note: the information presented in this section, and more, is available as permanent documentation in our public drive as part of our transparency reporting. It will be kept up-to-date even after the publication and approval of this MIP.


With the successful launch of Multi-Collateral Dai and impressive growth of the Protocol that leaves us with +$100M in annual revenues, Maker’s first significant contribution, a decentralized stablecoin, has been established. We are now facing our second big challenge: sustainably scaling the decentralized ecosystem while avoiding critical failure scenarios.

While the recipe for successfully scaling a centralized organization is quite well known, sustainably scaling decentralized organizations is mainly uncharted territory. We believe that it is critical for the success of the Protocol to systematically research the topic and continuously improve the efficiency of the decentralized economy as it grows.


Sustainably grow the Maker Protocol’s moats by systematically removing barriers between the decentralized workforce, capital, and work.


To support a decentralized, effective, and scalable economy on top of the Maker Protocol that continues to push forward its growth in a sustainable manner.

This decentralized, effective, and scalable economy:

  1. Has the best and most successful onboarding experience for new participants, with the highest retention rate in the industry.
  2. Allows everyone to find the capital they need to work on the best projects which (1) optimally drive protocol growth and (2) are most fulfilling for its participants.
  3. Has resilient safety mechanisms in place that prevent protocol failure while leaving ample space for rapid innovation and experimentation.

Core Unit ID


Core Unit Name

Sustainable Ecosystem Scaling

Core Unit Mandate

In order to support growing the Maker Protocol’s moats, SES will follow a strategy that is structured as a continuous improvement cycle, with research and development at its core. Iterating through this cycle will systematically drive the ecosystem closer to the vision that was outlined.

In a typical iteration: (1) new scaling bottlenecks are first identified, (2) research is then conducted on how to remove these bottlenecks, and, finally, (3) activities are funded and kick-started to implement practical solutions in line with the research.

Opportunity and Risk Assessment

Because the problem space is so large, it will be critical that we do not attempt to solve every problem at once but instead focus solely on a set of carefully selected priorities.

  • Identify opportunities and risks affecting the sustainable scaling of the ecosystem through engagement with the different DAO stakeholders.
  • Maintain an open backlog of these opportunities and risks, and make it accessible to the broader community.
  • Define research projects to act on the opportunities and risks that are documented in the backlog. Each project has a clear set of Objectives and Key Results.
  • Prioritize these research projects based on (1) what the greatest need is and (2) the most significant impact that the team can have with their set of skills and expertise.


Systematic research will target the identified bottlenecks, leading to repeatable solutions that help the ecosystem scale sustainably.

  • Assemble the right team and appoint a project lead to work on the following priority on the roadmap.
  • Coordinate stakeholder engagement and reach alignment on the objectives and key results of the project.
  • Collect the necessary data and develop models to verify research assumptions and offer insight into the problem. Publish the results for the community.
  • Explore solutions and frameworks that produce high-quality, repeatable results.

Initial Research Roadmap

SES will start out with three initial research projects from day one. Below is an overview of the objectives as they have been defined for now (still subject to change). When these projects are finished, new ones will be started.

01. Project Dog Food

Capture lessons learned from setting up a core unit ourselves.

  • Successful SES CU Setup: Go through the entire process of setting up a core unit ourselves, including (1) conception, (2) team formation, (3) legal setup, (4) budgeting, (5) partner outreach, (6) communication / transparency reporting, and (7) governance MIP approval.
  • Initial Documentation: Systematically document first impressions and the process in general, while going through it: required steps, work we do, available information, challenges and hurdles, …
  • Communication and Reporting Setup: Establish an online presence of SES CU through the creation of (TBD) a website, forum section, … Set up the processes for systematic transparency reporting and comms attuned to the decentralized ecosystem.
  • Kick-start Incubation Program: Create the incubator program and provide coaching to a number of early Core Units / Domain Teams starting out. Incorporate those experiences in the documentation.
  • Publish Results and Next Steps: Based on these initial experiences, create a first list of potential projects for the sustainable ecosystem scaling core unit that can improve the process. Synthesize, present the results to the Maker community and make documentation available.

» Project Dog Food OKRs

02. Project X-Ray

Create an initial model for the developer onboarding funnel.

  • Best practices for technical talent on-boarding:
    Set clear direction for Maker’s best practices and aspirations in developer relations efforts, that is backed by industry broad research, benchmarking, and expert insights.
  • Maker-specific onboarding funnel draft: Prototype the model of Maker’s tech talent onboarding and retention funnel and its components that capture the current situation.
  • First pass of the funnel: The model prototype is validated and improved upon via user research.
  • Improved onboarding funnel: The model is functional and has implemented processes.
  • Future project recommendations: Have an informed insight into the prospective future projects that can address detected bottlenecks, prioritized in accordance to their importance/ impact/ cost.
  • Communicate results to governance community:
    • First Quarter: Work progress and accumulated knowledge are shared with the governance community in a transparent and comprehensible way allowing them to understand the work done + work left on the model.
    • Second Quarter: All results and accumulated knowledge are shared with the governance community in a transparent and comprehensible way allowing them to use the model with minimal effort.

» Project X-Ray OKRs

03. Project Guardrail

Support kick-starting the decentralized safety infrastructure.

  • Early safety infrastructure: Reduce the risk of a “crash during take-off” with the Foundation transitioning to the DAO. Put the early safety infrastructure in place together with the early core units. Set a high standard for future ecosystem participants and help shape the Maker ecosystem culture in the process.
  • Best practices guidance: Reach out to the various technical core units and discuss their safety and security strategy. Provide feedback and guidance based on prior experience in the Foundation.
  • Self-accountability auditing: Help core units to keep themselves accountable by offering a regular audit of their internal processes and practices. Boost the participating core unit’s legitimacy, and strengthen confidence in them by publishing an audit report for governance.
  • Security discussions: Organize a regular security discussion group with participation of the major technical and risk domain teams.
  • Lead by example: Help shape the Maker ecosystem culture by creating the expectation of external auditing, security summits, etc. from the start. Create the necessary visibility in the community to achieve this effect.

» Detailed Project Guardrail OKRs coming soon


Our research must not be purely academic but, instead, be firmly grounded in reality. The produced solutions need to be implemented and maintained in the long run: incubation is a critical element of our strategy.

  • Identify areas of activity that our research shows would contribute to more efficient and sustainable ecosystem scaling.
  • Connect individuals and teams to conduct these activities continuously. Set the team up for success to become an independent Core Unit.
  • Guide and support the team throughout the process, including (1) conception, (2) team formation, (3) legal setup, (4) budgeting, (5) partner outreach, (6) communication/transparency reporting, and (7) governance MIP approval.

Initial Incubation Roadmap

SES will start out with two initial incubation teams from day one. This is an overview of the objectives as they have been defined for now (still subject to change):

01. JavaScript Product Development CU

Develop web applications and tools that maximize participation, simplify complexity, and democratize access in the Maker protocol.

  • Develop dapps, web applications, and open-source tools (e.g. dai.js) for the Maker ecosystem
  • Design delightful & meaningful user experiences and intuitive interfaces improving the Developer & Community Experience
  • Provide support for maintaining existing applications that are vital to the Maker protocol and community (e.g. Governance Portal, Liquidations Portal, Migration Portal)
02. Incubator CU

Increase the successful development of new businesses (teams/Core Units), job creation and employment in areas that are aligned with Maker Protocol’s unique sustainable growth opportunities.

  • Set up an incubation program that will be implemented with participating teams
  • Support participating teams for 3 - 6 months in all aspects of the incubation process
  • Close interaction with incubating core units to understand their needs and collecting feedback on the program for achieving continuous improvement
  • Team covers 3 domain expert areas (people, business, tech profiles experts) + generalists
  • Collaboration with external partners (e.g. educators, recruiters)
Ongoing Conversations

We are talking to a number of interested parties to consider further incubation teams in the following areas:

  • Smart Contracts Development, because we believe that parallelizing SC development work will be key to further scaling the ecosystem.
  • Legal Core Unit, to work on high-priority legal frameworks that the DAO and its core units will need.
  • More to come


Next to the continuous improvement cycle to promote new solutions for sustainable ecosystem scaling, the core unit will also engage in related Sponsorship (and Advisory) activities.

  • Incubation Program Funding provides the necessary financial support for incubator teams to be paid throughout the program, until the publication of their MIP and governance approval of their own budget.
  • Scholarship Grants identify and test a potential Contributor before making a longer-term commitment in a Core Unit or with the DAO.
  • Micro-Grants are intended to test an idea by building an MVP with minimal scope. For experimentation and discovery.
  • Development Grants are aimed at the conception and development of a platform or product that requires a more significant effort.


There is no formal reporting and management structure in the decentralized ecosystem, as is typical for centralized organizations. We believe that a secondary, advisory function performed by mature Core Units will be critical for covering those needs.

We plan the following advisory activities through partnerships with other core units:

  • Help teams to conduct transparency reporting, establish best practices, and organize self-accountability auditing.
  • Offer ceremonies facilitation for core units that do not have a full-time agile coach.
  • Act as trusted third party for Dark Spells to verify critical protocol vulnerabilities and confirm the necessity for a dark spell and the correctness of its implementation.

Transparency Reporting and Self-Accountability

We believe that sustainable scaling of a decentralized organization will require a great deal of transparency reporting and self-accountability mechanisms to perform the function of traditional alignment, reporting and evaluation mechanisms found in centralized organizations.

Apart from the research that we will conduct around this, we’ll start with applying a number of practices in our own core unit to explore their dynamics and potentially set an example for others to follow:

  1. Objectives and Key Results for all our projects as the primary way of communicating goals and tracking progress against those goals. These OKRs will be published on a website that will be kept up-to-date all the time, so that everyone can inspect not just what we’re working on, but also what has already been achieved.
    » Review the Roadmap with OKRs

  2. Weekly Status Update Calls with a documentation trail that can easily be reviewed by anyone who is interested. These calls are already happening every Friday at 14:30 UTC. Every week, an overarching topic is formulated to make the archive more accessible.
    » Review the Status Call Archive

  3. Standardized Core Unit Documentation – We believe that with a growing number of core units in the ecosystem, the need will arise for standardized reporting about several aspects of the team’s activities, goals, and performance. While no standard exists today, we have structured our own core unit documentation in a format that we hope can be reused by others, including the projects in our incubator program.
    » Review the Core Unit Documentation

  4. Self-Accountability Audits – Last but not least, we’re introducing the notion of self-accountability audits, whereby we will work with an independent external party in the community to:

    • Work out and agree on best practices and standards that we want to hold ourselves accountable to as a team.
    • Publicly commit to following this set of best practices and standards.
    • Have regular reviews with the third party to audit the team’s operations, assess to what extent these practices are followed in reality, and formulate improvements where needed.
    • Have a public record of these audits available for full transparency.

    Seb Derivaux agreed to take up the role of self-accountability auditor for the SES Core Unit.

While we are pionering these practices with our own Core Unit, we will be able to support other Core Units through our Advisory Program to implement similar mechanisms based on our own experience.

SES Discord Chat

» Join our Discord server for further discussion and questions.

Related Documents

Core Unit Budget MIP
Core Unit Facilitator MIP


I am convinced this one is going to be important. Right now multiple Core Units are being proposed but the community has no way of checking the internal workings of the groups. We have literally no idea what people are doing. With a profitable organization such as Maker it is very easy to propose new and promising Core Units with the result that the organization grows horizontally like mold in a Petri dish, endlessly adding new non-essential activities. At the same time, due to the much higher abstraction level required, the very necessary vertical growth (such as scaling) can be much harder to achieve.

You might consider adding the following bullet to your “Dog food”.

  • State of Scaling. What are the present ideas about scaling at Maker? Have there been ideas in the past that have been discarded? And why? There is just no way so many smart people can not think about that. And how to get there? Last from the foundation was the Linux of money, but that post is nearly 1.5 years old and extremely vague.

Thank you for this👍 It’s long over due! When @Kurt_Barry saids that Ethereum is no bueno—he ain’t kidding—there’s no sugar coding it—miner extracted value is real—we are getting bent over with no Vaseline: https://youtu.be/Wd0at2Pu6xY

1 Like

Wow really great call today chalk full of information! I didn’t feel like there was an easy way to ask this and get it answered during the call timeframe, but I do have some questions on the philosophy of the Core Unit. Namely, I think what this Core unit is attempting to do is super important and a difficult task even if you were able to start with a “blank slate.” So given that the DAO is (in a very real way) already “up and running,” how do you craft best practices and improve expectations around events and practices that are already in motion?

This is a bit like laying down the train tracks while you’re already chugging along and while seeing this all-star group of talent apply as part of this Core unit gives me confidence, I do wonder how realistic the scope of the unit is. I think there are several challenges with building/improving in an already active space, but one issue in particular that highlights this challenge is the decentralization process itself. In particular, I’m envisioning all the assets and contributors/grantees that have been funded by the Foundation. How is this Core unit addressing the tremendous amount of assets (both people and things) that have been developed under the “old guard?”

Personally, I worry that many great people and projects will be left behind simply because we don’t have an adequate framework for evaluating all the components that have helped grow the protocol to its current size. TL;DR: How does this Core unit plan to address the sheer magnitude of people and projects going on in the DAO? What’s the philosophy behind managing resources?


Thanks @prose11 for the thoughtful questions and remarks. I’m writing up a reply that I will post later today.


As was discussed on our weekly status update call earlier, we’re well aware of the challenges that @prose11 refers to in the post, and we believe they are very relevant. In fact, our strategy is shaped around these exact challenges.

The three questions to consider:

  1. How do we deal with the very broad scope of building a scalable DAO?
  2. How do we approach this in a decentralized environment in particular?
  3. How do we approach this given that things are already up and running? How do we refactor the DAO?

There are no miracle solutions, but we are sticking to the following principles to make it possible.

1. Dealing with the very broad SES scope

We deal with this through 3 principles which have been instrumental is shaping our strategy. They are exactly like traditional management tactics to deal with a high workload.

Ruthless Prioritization

At any time, we work only on a few focus areas that have been selected as the top priority. We don’t try to work on every problem that arises but recognize when our capacity is reached.

  • We will maintain a register with risks, opportunities and scaling bottlenecks that are clearly prioritized so that we can deal with the most urgent issues first.

  • The same principle applies to our backlog of grant proposals, research projects, and potential incubation projects. These are clearly prioritized so that it’s clear at any point what will be dropped in favor of more urgent work.

  • We work on projects that (1) cater to the greatest need and (2) where we can have the biggest impact. The second condition is based on the knowledge and skillset we have available in the team.

Delegation is the Default

The entire core unit is set up to offload as much of the work as possible.

  • Through discussion, advisory, education, research publication and potentially MIPs, we shape the DAO culture and common knowledge that influences the work that other people do. For example: by simply talking about a model for parallel smart contract development work, providing insight in the mechanics, we are already helping others to implement this.

  • The grants program, specifically targeted at those innovations that we know are necessary to improve scalability, is a direct way of supporting others to do the necessary work. Once again we delegate the work.

  • The incubation program has a similar effect for bottleneck solutions that require continued efforts rather than a one-time project.

Careful Expectation Setting

We want to be clear about what we do not do:

  • We will not fix every scalability issue in the DAO. We focus on priorities and leave the rest for others to work on.

  • We will avoid busy kitchens with too many cooks. If there are already too many people with an opinion working on a problem, we will spend our time elsewhere instead of making the consensus more difficult by adding one more opinion.

  • We do not expect to have a monopoly. We will assume a competitive space and are welcoming of other teams to work on scalability challenges just like us.

2. Decentralization principles

This all plays well with the principles of decentralization:

  • Most of the time, we will not wait. We will move forward with solutions without waiting for consensus or permission. We will however communicate and collect feedback along the way.

  • We will take limited responsibility, only for what we control. As a result, we will mostly talk from our own perspective and not try to be the voice of the DAO… unless we’re reporting on the facts, for example: the community has voted for X or Y.

  • We still believe that a fluid consensus, reaching alignment, in the community, is important and we will try to contribute to it:

    • Leading by example, e.g. by presenting a core unit budget structure that we believe can serve as a template for others
    • Analyzing work of others, e.g. by evaluating the budget structure of other core units
    • Summarizing emergent consensus, e.g. by distilling a canonical model form the different budget structure variants
    • Standardizing where possible, by recommending the canonical model e.g. through our incubation program
    • Formalizing where it makes sense, e.g. by submitting a MIP to introduce a consistent budget structure across core units

3. Refactoring the DAO

The DAO is evolving all the time and this is ultimately steered by our everyday decisions. Similar to technical debt and through refactoring in software, it is possible to gradually change the collective behavior into the envisioned ideal. The rules are not inscribed in code, but they are set through MIPs and many more social consensus points. We want to help to gradually evolve this culture of the DAO.

One thing that may help, is that we’ll try and separate problems from vision from solutions:

  • Talk first about what the scaling problem(s) is (are) that we are trying to address. If only the problem is better understood, that is already a win. And without this understanding, it’s not possible to understand the value of an envisioned solution.

  • Be clear when we’re talking about a long-term solution rather than about a short-term practical fix. This helps people orient towards a goal without drowning into the details.

  • Clarify next, what the steps are to reach this goal, rather than suggesting that it will be reached in a single change.

Indeed, baby steps are crucial:

  • Don’t try to get a strict and formal consensus on the long-term vision. This is not possible in a large community, nor is it necessary.

  • Try to agree on the next refactoring step instead.

I hope this helps to clarify things and removes some misconceptions.


Our proposal was now updated with the following changes:

  1. Integrations Incubation Team is joining the SES Permanent Team instead. The Integrations Core Unit was removed from the Incubation Program for now.
  2. Added potential new Incubation Projects that are being discussed.
  3. Updated Project X-Ray Objectives.
  4. Confirmed Seb as our Self-Accountability Auditor.
  5. Updated URLs to point to our new Google Drive.

Could you elaborate a little more on this? Does that mean SES is covering integrations work on a more permanent basis?

Good question, no, SES won’t do integrations.

The Integrations Engineering profile is a strong combination of technical domain knowledge, business domain knowledge, and documentation/education skills (e.g. for creating technical guides, explaining technical concepts, …)

The same combination is needed as a broad technical support role within SES:

  • Help support the technical track of the Incubation Program by providing training and technical guides.
  • Participate in research projects targeting scaling bottlenecks with a technical component, or a tech people component, such as Project X-Ray, Project Guardrail, …
  • Help maintain and curate the documentation created for the risk registry, list of opportunities, and project requirements.

We had open technical positions for this to join the permanent team. Now the integrations team is joining us with their considerable experience in this from their work at the Foundation.

(Of course this doesn’t mean that the DAO won’t need Integrations… but we can’t solve every problem at once :slight_smile: )

1 Like

Got you, so the former integrations team is switching gears a bit. Meaning you’ve filled some gaps in SES, but we need to find a new integrations unit to incubate.

Sounds good, I can see the need for a solid technical support team in SES. Thanks for the detailed response.


The SES team would like to formally submit this subproposal.

1 Like


Something to go back to once/if you guys are voted in :slight_smile:


It would certainly help onboard a lot of users if they were not being price gouged by high gas fees.

A post was merged into an existing topic: Maker’s Oasis on Polygon (previously Matic)