Road to DAO: the Core Unit Operating Model

For the last couple of weeks, a group of smart people and I have been working on what would eventually become a MIP set that, we believe, is the right way for Maker to move forward, as the Foundation dissolves and the responsibilities are taken over by the Community. The first step is to lay down the roadmap to facilitate this transition.

Context

As we take another step towards decentralization, we have begun implementing temporary solutions to deal with situations where the Foundation cannot meet Governance’s requirements.
Several Contributors and Facilitators have voiced their concerns to achieve autonomy and flexibility, while Community members search for ways to collaborate.
What’s more, the DAO could benefit from top-talent that the Foundation has spent years hiring and training.

Phase-based approach

We don’t believe it is entirely possible to achieve the Target Operating Model in the first iteration. The MIPs model allows us to discover the shortcomings of the current MIP Set, amend it, and integrate the temporary measures built around its weaknesses.

DAO Primitives

Simplicity and modularity have driven this MIP Set. The main idea behind it is to keep the basic framework flexible so that the Community can use it in multiple situations in an unbiased way. As we learn to self-organize, we will be able to upgrade the Framework to adjust upcoming needs.

Core Objective of the Framework

For the DAO to grow its value and keep running its services, it needs to make sure that its available resources find their way towards the contributors able to perform certain activities.

This Framework aims to help organize both the flow of priorities and resources, not only enticing as much talent as possible to cross the chasm (from the Foundation to the DAO), but also to attract top talent from the broader DeFi talent pool.

The Core Unit

It contains a Mandate, akin to a question that the Facilitator must answer with the available resources.

The Budget

One or multiple budgets per Core Unit; each with its implementation and its breakdown.

The Facilitator

The most trusted actor in the Community; interacts with Governance and the Contributors to organize activities to achieve the Objectives. It contains the name and information and the commitment (the how).

Contributors

The groups of people performing the tasks to maintain and grow the protocol can focus on their job while the Facilitator acts as a proxy and deals with the bureaucracy of interacting with Maker Governance.

Trust, rather than control

Governance is not looking to micromanage any given group. Arguably most MKR holders prefer a relatively hands-off approach and to be consulted in critical decisions (potentially contentious).
The Framework provides Core Unit Facilitators with enough flexibility and margin to quickly react to new events. In return, they’re expected to provide clarity into their actions and expenditures.
While Governance has methods to remove a Core Unit Facilitator (non-performing, rogue, etc.), these agents need to receive the corresponding remuneration and enough trust and autonomy upfront to perform well.

MIP Set Proposed

Existing MIPs Impacted by the Set Proposed

Moving Forward - How can you help

RFC - Improving this Framework

Reply to this proposal. If you think that there’s something we should consider, please comment. We will do our best to try to accommodate every situation.

Using this Framework

Propose a Core Unit. It needs a name and a mandate.
Ideally that Core Unit also comes with a Budget (implementation + breakdown), and a Faciliator and their commitment.

Signed:

@ElProgreso
@iammeeoh
@juanjuan

19 Likes

OK - so compared to what we already have

Domain is renamed Core Unit
Domain Facilitator is renamed Mandated Actor
pluss there is now a bit of a budget

How is this bringing us closer to becoming the Linux of Money?

Reading MIPs is generally an exercise, and these are no different. But am I wrong to say “now the DAO has a procedural method for paying contributors?” In other words, I propose a unit, suggest a budget and, presuming it’s approved, I’m getting paid for my work by the DAO. If so, that’s wonderful and crazy (in a good, innovative way).

5 Likes

Yes. The steps are:

  1. You (or anyone) can propose a Core Unit. This is a container of people/companies/groups that work on a certain task: e.g., risk evaluation, marketing, smart contracts, etc

  2. You propose yourself as Facilitator of the Core Unit. The Facilitator is the link between the DAO and the Core Unit. He is in charge interacting/informing the DAO and also coordinate the work of the people/companies working within the Core Unit (Note: the latter do not need to spend their time of Governance, they just need to talk with the facilitator).

  3. You propose a Budget for your Core Unit. When/if approved, this is a stream of DAI that will reach the Facilitator at each time unit. The Facilitator then distributes this (probably automatically, but we’ll see how it develops) to all people/companies working in their Core Unit.

That’s it!

It’s very simple, but this also means that it is flexible!

We hope to start seeing the first proposal in the next month or so. And then we will iterate and build better and better processes.

I think there is reason to be optimistic.

3 Likes

Thanks for your feedback, @Planet_X. I wasn’t expecting any less from you. ; )
It helps us shed some light on the less clear sections.

Not quite. A Domain nowadays is something close to “a group of talent with some common skills”. While it is entirely possible that this is translated 1:1, I can also see Core Units appearing to solve other pressing issues that Governance might have.

A mandated actor is a generic name for the Core Unit Facilitator.

Now there’s a lot of a budget. With this MIP set, a Core Unit can get approved and expect a stream of payments; Governance needs to approve it once (and any subsequent modifications) but:

  • Contributors benefit from knowing that they will be paid.
  • Governance knows that the Facilitator will administer that budget to achieve the Core Unit Mandate.

This is the first step so that:

  • any group that brings value to Governance can be proposed and get a budget.
  • it works with current solutions (manual suck()), solutions being developed (MIP34: Keg Streaming Payments Module), and any future solution that we haven’t yet thought about (bonuses/rewards/etc).
  • more importantly: groups can organize in different ways according to their jurisdiction/processes/the desired outcome. For example:
    • a Facilitator could set up a company and decide to make contributors employees (with the corresponding benefits).
    • or they could decide to contribute as freelancers.
    • or a group could create a DAO / LAO to organize that group that is providing these services to Maker).

Thanks again for your questions, @Planet_X. We appreciate them.

4 Likes

Thank you for your quick reply @juanjuan, on closer inspection I think my comments were slightly pre-coffee.

1 Like

That’s awesome. Thanks. One quick clarifying question: if I wanted to form a one-person core unit, say I’m a code auditing machine who likes to work alone, could I do that? So, I would present myself as the core unit and facilitator, and request a budget to cover my efforts for the DAO? Or does a core unit necessarily have to have more than one person? Sorry if this is a dumb question.

It is not a dumb question.

Short Answer: Yes, it is possible. We haven’t written anywhere that Core Units must consist of >1 person.

Longer Answer: While possible, this 1person CoreUnit unlikely to get voted. One of the reasons for having CoreUnits is to discharge the Governance from having to deal with financing/checking/managing every single persone working for the DAO. For this reasons, it will be much more governance-energy efficient to have fewer and bigger CoreUnits (like 10 in total, or even less at the beginning).

1 Like

It is not a dumb question.

I think that would be a very interesting Core Unit.
Something like Safety, or Red Team, or along those lines.

You could say that you would like X k Dai (example) for this Core Unit as a budget, and propose yourself as the Facilitator.
Then you could:

  • Do the work yourself and use that budget to pay for it.
  • Hire other contributors
  • Hire companies to run audits.
1 Like

A few questions

  1. You said that Core Units don’t replace Domain Teams. Does this mean Domain Teams are housed within Core Units? How do Domain teams work with this model?
  2. Isn’t this basically the same as Domain Teams, except with the added budget component?
  3. If this is meant to replace domain teams, couldn’t we make it simpler by applying some of the principles of this model to the current MIPs behind Domain Team Onboarding?

Note on Domain Team Onboarding:

It used to be MIP7: Onboarding and Offboarding Domain Teams (Collateral Onboarding) as the sole process for onboarding SC, Oracles, Risk, and Legal Domain Teams.

That evolved when governance passed MIP23: Domain Structure and Roles which:

  • Better defined Domain Teams as consisting of Domain Facilitators & Domain Contributors.
  • Included the Domain Definition Subproposals
  • Included generic Domain team onboarding and offboarding Subproposal processes.

This allowed governance to escape the constraint of “collateral onboarding” related Domain teams as outlined in MIP7. Now MIPs could facilitate onboarding of other Domain Team types, like the Operational Support Domain.

Now, we have this proposal and I’m not sure how it disrupts, replaces, or supplements this structure.


I imagined for a moment that core units would represent the various functions, and that within them there would be the possibility of housing multiple Domain Teams of the same category. Though it seems that this is not the intended design from my reading of these MIPs.

Edit: Okay I am seeing some mention of Domains in MIP39

They are the basic units of domain work that Maker Governance is able to oversee…

Core Units are a primary DAO Primitive used to enable Maker Governance to signal and prioritize the main objectives the domains need to solve.

Core Units are at the intersection of Domains, which denotes skillsets and capabilities, and Core Objectives which denote cross-domain long term work streams. A Core Unit can participate in multiple Core Objectives, and can fall under multiple Domains.

This still leaves me unsatisfied though. Are Core Units better mapped to objectives rather than teams then? Is this example realistic?;

Core Unit: Oracles as a Service
Mandate: Work with domain teams to kickstart Oracles as a Service.
-> Oracle Domain Team
-> Smart Contracts Team

In this example, the Core Unit would be in charge of managing Oracles as a Service. The Unit Facilitator will work with Domain Facilitators to achieve this objective. Meanwhile, Oracle Teams have their usual duties, and so does Smart Contracts Team.

Is that closer to how you envision this structure working? Would love some more example Core Units and how they would work across Domain Teams.

2 Likes

This is a very good point David–Like MIP23c2 states: “it is recommended that Maker Governance aim to recruit and maintain three domain facilitators for each defined domain” --we have and continue to discuss such and hope the Community will provide comments.

Our approach was to create a Lean MVP and felt that a Long-term proper framework would have been difficult and probably taken all of 2021 to develop—an interim Keg like “Interim DAO Operating Budget” would have become the norm for teams/contributors in need of funding—and we felt we needed a Lean MVP that would allow the community to expand via the RFC process—which allows the frameworks to grow organically.

Not sure if I understood your question correctly–but the vision here is that each Core Unit applies via MIP39c2:

Core Unit: The Oracle Team
Mandate: Provide pricing data that determines the amount of Dai that can be drawn against a collateral asset, as well as when an outstanding position is in need of liquidation.

The Smart Contract Team would create their own Core Unit Template, the BD Team creates their own, etc. Each Core Unit will have their own budget and Keg. The core unit facilitators will use best practices and need to lead by example, and make proper proposals.

This does not answer all of your questions–I’ll let others comment on your valid points David.

1 Like

Why do we need to have both Domain Teams and Core Units?
What is the fundamental difference between them?
As far as I see it we can just finance the Domain Teams with MIP34 (Keg) and end up with the same result? What is it that I am not seeing here?

I will transpose my RWA budget under this new framework later this week (and the help of the working group). I feel the model is sufficiently flexible to allow almost anything but still provide a bit a formal structure to keep track of everything.

The model will make more sense when the DAO will grow. We can have a Core Unit that manage a Euro-DAI system for instance or managing a DAI mobile app.

For the core unit naming, I think having something not too specific would be best. If we want redundancy, we need at least 3 core unit per domain. Except if the idea is to have 1 core unit that contains 3 domain facilitators (one being the core unit facilitator). Let’s experiment and we will see what works.

5 Likes

I come with the same question, also i’m thinking if all is going to pass through a vote, i imagine tons of people seeking for approval of the governance, so MKR holders will have to vote a lot more than usual with this right? (if i understood it wrong i’m sorry)

But yeah is like ambiguous from my point of view, at the end why not replace the Domains with the new structure and we all adopt it (it seems more flexible i think), or keep the Domains structure and add the Keg for the payments.

1 Like

So I have a few questions/concerns. I can see the appeal from a governance perspective that detailed Core Units helps governance determine what specific “projects” they want to prioritize and how many resources to allocate to each one. However from an execution point of view this makes it really difficult for teams like mine that span multiple Core Units to wade through the administrative overhead that entails.

Let me elaborate using the Oracle Domain Team as an example. The Oracle Domain Team works on the following items/responsibilities each of which could be its own Core Unit.

  1. General Oracle Protocol development and maintenance
  2. Collateral Onboarding
  3. Developing Oracles as a revenue-generating Business on behalf of the DAO
  4. Creating bespoke Oracle solutions for exotic collateral types (i.e. LP tokens, RWA)
  5. Managing Oracle and Feed upgrades and deployments (usually 2x a month)
  6. Reviewing and Processing Whitelisting Requests for Oracles
  7. Budgeting/Payments: Collecting invoices from Feeds and distributing Oracle payments, onboarding new Feeds, etc.

I’m definitely interesting in spinning out of the Foundation with my team and starting my own independent company to continue executing on all of the current responsibilities listed above. I think my team has been doing an excellent job jugging these different responsibilities. However, it doesn’t make sense to me to have Core Units be so specific that I then have to apply to be a Facilitator for each one, create a budget for each one, and treat each one separately.

For example, let’s say I have 6 engineers on my team that are costing me 800k salary + benefits/insurance. I’d like to be able to tell the DAO I can execute on the above core objectives for $1M rather than piecemeal together a bunch of separate contracts for each Core Unit to try to scrounge together a budget number that may or may not add up to being able to afford to pay my team. It’s possible, but why would I want to waste my time that I could be doing actual work dealing with this kind of overhead. Now let’s say Governance decides to remove one of those Core Units or give that responsibility to another Domain Team. Now I can’t afford to pay my team anymore.

I think it makes more sense to have Core Units be much higher level like an “Oracle Core Unit” for which there is one facilitator, with multiple Domain Teams. The Facilitator comes up with a plan that shows all the responsibilities that Core Unit is responsible for, the resource allocation between each one, and the proposed total budget to execute on that Core Unit. Governance then gives feedback on the proposal and changes are incorporated. After Governance has passed the proposal and Facilitators get access to budgets, Domain Teams that want to do work in that Core Unit basically apply through the Facilitator rather than directly through Governance. This gives a much more stable platform for Domain Teams to build out sustainable-businesses and minimizes the amount of time wasted by Facilitators on governance overhead.

11 Likes

Thanks for your comment, Nik.

I’m working on making this more clear, so your example is great.

To be honest, you almost have the Core Unit going.

Core Unit
Name: Oracles
Mandate: your list.

Facilitator
You. Commitment is quite clear, I think.

Budget
Already outlined.

If someone wants to spin something similar (or different) they can propose their Core Unit with their mandate.

Hope this clears up things.

5 Likes

Hi @NikKunkel (and others), good question.

As @juanjuan already mentioned, your Core Unit is a pretty perfect example of what we have in mind with Core Units.

Just to clarify, I made this video (~13min) where I describe my understanding of the CU operational model, with a specific look at @NikKunkel’s Oracles Core Unit.

I decided to make a quick video because we have already a good amount of text, and perhaps a video can offer a “more direct” insight on what are our (or at least mine) intentions with this CU Operation model.

Video here: https://www.dropbox.com/s/u6i4dre4txgpa92/2021-01-20%2020-17-22.mkv

5 Likes

OK. MIP7 is somewhat restrictive in this respect. But a simple amendment would cover this.

Again. This can be fixed with an amendment to existing MIPs unless I am wrong.

As far as I can see there is nothing in MIP7 that prevents a Domain Team to be a company from California or run from a North Korean prison. A proposal is a proposal. It has traditionally been persons, but it is not explicitly stated that this must be the case. Am I wrong?

:sweat_smile: I surely hope the Maker Community does not approve a North Korean prison as a Core Unit–but I get your drift.

It’s up to the Community on what they will consider qualified, decentralized, and beneficial to the DAO. I do hope that we don’t approve a malicious Core Unit, or Facilitator–and if somehow we mistakenly do–we have the vision and strength to remove them–I believe we have both.

I also believe that we have a good community of honest folks that share the same common goals and are committed to protecting Maker, and moving this DAO forward with diligence and triumph.

The important task here is that we mobilize, use our resources, and push forward on decentralization. The Community needs to run this DAO. And the most important Core Units are the ones we already consider members of our community. You know them, you communicate with them. And they are in my opinion–going to be outstanding at setting a precedent for future Core Units. Can’t wait to see the Smart Contracts Team, The Oracles Team, BD Team, etc., apply for unconditional freedom.

“MakerDAO—Community Owned and Operated.”

1 Like

Awesome, thanks.

2 Likes