Road to DAO: the Core Unit Operating Model

Maker Improvement Proposals
, , , , ,
#8

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
#9

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
#10

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
#11

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
#12

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?

#13

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
#14

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
#15

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
SourceCred distribution for week ending Jan 24th, 2021 [Updated payout formula]
#16

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
#17

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
#18

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?

#19

: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
#20

Awesome, thanks.

2 Likes
#21

That’s just a duplicate of a domain team though, except with a budget component, no?

P.S. @NikKunkel I really like your suggestion at the end of your comment to flip the structure, that makes a lot more sense to me from a bureaucratic-overhead perspective. Also it gives Domain Teams the ability to split work between each-other more clearly.

#22

In this specific case (@NikKunkel 's group), yes, the new Core Unit might be a duplicate of an existing Domain Team.

But Core Units are in principle larger ‘containers’, they can include several teams (even companies, etc). They should not be necessarily identified with the Domain Teams considered so far in MakerDAO.

In particular, you should not force yourself to “adapt” all MIPs related to Domain teams and “search/replace” with [Domain Team / Core Unit]. Or, at least, this was not in our intentions.

3 Likes
#23

That was a very nice video @iammeeoh it helped clarify things. I do however feel the Core Unit principle is still too similar to the good old Domain Team structure. But OK.

#24

I don’t think this is necessarily a bad thing.

As the first stages of using this, I see all of the existing domain teams proposing themselves as Core Units (with budgets) so they can be paid by the protocol. As the DAO evolves, I expect to see the actual working structures in the DAO expand out into this framework over time.

I consider this the best possible outcome when moving to a new framework. There should always be a way of transferring what currently exists 1-to-1 into the new framework. If the framework is good then what currently exists will adapt to the framework over time.

6 Likes
#25

It seems this approach is a governance-centric approach, designed from a technical perspective, which was the original role of EIP/MIP. Credit to Mr. St.Louis here, a very successful job getting it to this point. @charlesstlouis

Yet, Maker still lacks the framework and operational skeleton to bootstrap daily operations in a substantive way. Right now you have unpaid contributors working for a “de-cent” organization that makes profit—not good or decent.

The DAO needs to bring on a single project team under a substantial proposal to deliver an operational skeleton akin to the initial MIPS skeleton. This is the way to produce the work and constrain paths and research for Maker governance to vote on (similar to collateral on-boarding, but much, much more work).

Pro-bono work will not work to get Maker over the hump and will leave it in a graveyard.

Clear mutual incentives, win-win, works (e.g. RWA and Rabinowitz success) . These iterative improvements (domain team to core unit) represent the worst part of decentralization and government: a glacial pace that loses pace with innovation through a prohibitive and restrictive bureaucracy. LFW is right in suggesting that iterative improvements allow for easy transition, they also allow for minimum incremental novelty–the death of innovation. It should not be understated, a glacial pace allows for and affords protection. A blanket approach of slow motion is not advantageous. This risk reward does not need to be the same in each domain (risk, technical protocol, business ops).

True decentralization isn’t the worst features of democracy concentrated, but the best features of centralization, de-risked. To date, you have fully centralized de-centralized decision making in every aspect, with burdensome documentation, not easily data, and you are still relying on trust (the opposite goal of decentralization and redundancy). It is better to assign responsibility, and align incentives so trust is not an issue. Trusting people with the expertise to execute and scoping which decisions are made at which level, is the key to empowering management and unlocking productivity. The Risk team seems to do this well and has been empowered since the early days to do so.

In order to get a real operational skeleton in place, you need to delegate the project, fund it, and then run the project as it were an MIP with comment periods, then have governance vote on the concrete and proposed findings. Note here again how effective Rabinowitz was in delivering real results.

If this is something the community and DAO is interested, delivering on operational promise and keeping the DAO competitive… let me know.

-Dao abides in non-action,
Yet nothing is left undone.-

1 Like
#26

Hi @Eschaton,

there is no doubt that it is always possible to do better.

Also, there is no doubt that @mrabino1 has done great work.

Given these two premises, and your proposal:

Yes, please. It is critically important that we collect the best ideas.

One thing you could do, with what is available now is:

  1. Propose to create a “DAO Research CoreUnit”,
  2. Propose yourself as the Facilitator
  3. Convince governance, with a sketch of your ideas, to fund your Core Unit with the amount of money you think is needed/adequate.
  4. Present your results when finished.

I believe I can safely say that everybody here is eager for good ideas, that can scale well and fast.

Thanks!

3 Likes
#27

+1 this thought. Thinking in the future of the DAO without the Foundation, having this Core Units and Domain Teams moving to them (like just a change of tittle we can say), and if all the frameworks looks good and easy to understand it might help governance to understand what the Protocol is going to pay and outsiders to consider joining the DAO and making Maker even much stronger.

2 Likes