MIP39: Core Unit Framework

Maker Improvement Proposals Archive
, , ,
#1

MIP39: Core Unit Framework

Preamble

MIP#: 39
Title: Core Unit Framework
Author(s): @juanjuan
Contributors: @elprogreso, @iammeeoh
Type: Process
Status: Formal Submission
Date Proposed: <2021-01-18>
Date Ratified: <yyyy-mm-dd>
Dependencies: MIP38, MIP40, MIP41, MIP4c2-SP10, MIP4c2-SP12
Replaces: n/a

References

MIP39c2-SP-Template
MIP39c3-SP-Template
MIP39c4-SP-Template

Sentence Summary

MIP39: Core Unit Framework contains a framework for managing Core Units and modifying them in the DAO Primitives State MIP.

Paragraph Summary

MIP39: Core Unit Framework contains a framework for managing Core Units and modifying them in the DAO Primitives State MIP. The Core Unit is the basic building block for organizing work for the DAO. It denotes particular long-term objectives that Maker Governance has decided for the protocol to be secure and successful.

Component Summary

MIP39c1: Core Units
Gives an overview of the most important characteristics of Core Units.

MIP39c2: Adding Core Units (Subproposal Process)
The process for adding new Core Units to the DAO primitives State.

MIP39c3: Modifying Core Units (Subproposal Process)
The process for modifying Core Units in the DAO primitives State.

MIP39c4: Removing Core Units (Subproposal Process)
The process for removing Core Units from the DAO primitives State.

Motivation

As the Foundation dissolves, MakerDAO must take over the tasks and responsibilities no longer fulfilled. We believe MakerDAO’s current structure is too ill-defined to be able to integrate these successfully. A new scheme is needed for MakerDAO to achieve this crucial integration on its way to full autonomy.

Core Units are DAO Primitives designed to be easy-to-transition-to and capable of accommodating both the current structures and the Foundation’s newly delegated operations within a coherent framework.

Core Units define long-term work areas and cover a broad set of responsibilities or focus. They are the basic units of work that Maker Governance is able to oversee, manage and prioritize.

Specification / Proposal Details

MIP39c1: Core Units

What is a Core Unit?

A Core Unit is a structure that has a budget attached to it, managed by one or more Facilitators, that coordinate and pay contributors working to achieve a long-term goal within MakerDAO.

Core Units are proposed by community members and voted on by Maker Governance. Each Core Unit may have a budget (MIP40). The Facilitators (MIP41) of a Core Unit may have additional permissions over the Maker Protocol or Governance Processes depending on their Core Unit’s nature.

Core Unit Mandates

Core Unit Mandates set the direction of the work that Facilitators must help carry out by using their budget and exercising their Governance Powers.

Mandates should be high-level and avoid trying to micromanage the Core Unit processes; instead, they should be broad, open-ended and give room for manoeuvre so as not to stifle the Facilitators’ ability to come up with innovative solutions and efficient processes.

Mandates can be regarded as “questions” for Facilitators to “answer” with their Facilitator Commitment (MIP41) when proposing to be onboarded to a given Core Unit.

Mandates from different Core Units can overlap to create redundancy and parallelize and decentralize work within the DAO.

Core Objectives and Domains

Core Objectives and Domains are not directly defined in the DAO Primitives MIP Set but are flexible concepts that emerge through the interaction of DAO Primitives.

Core Units are at the intersection of Domains (which denote skillsets and capabilities) and Objectives (which denote cross-domain long term workstreams.)

A Core Unit can participate in multiple objectives and can fall under one or more domains.

MIP39c2: Adding/Modifying Core Units (Subproposal Process)

  • This subproposal process allows Governance to create or modify an existing Core Unit by setting its Mandate and/or its name.

    Care should be taken so that names and Mandates don’t end up drifting apart from each other.

  • Once a subproposal is approved, the Governance Facilitator or the MIP Editor modifies the DAO Primitives State (MIP38) to append a new entry with the Core Unit specified in the subproposal. The Operational Support Core Unit, or the MIP Editor or Governance Facilitator, will also assign a Core Unit ID (e.g.: GOV1) to uniquely identify the given Core Unit.
  • The proposal parameters are:
    • Minimum feedback period: 1 month.
    • Minimum frozen period: 1 week.

MIP39c3: Removing Core Units (Subproposal Process)

  • This subproposal process allows Governance to remove a Core Unit from the DAO Primitives State (MIP38). A Core Unit can only be removed if it has no active budget implementations (see MIP40) and no active facilitators (see MIP41).
  • The proposal parameters are:
    • Minimum feedback period 1 month
    • Minimum frozen period: 1 week

Edit: Incorporated feedback for clarity, added to my github (accepting PRs) and also PRed the Maker Github.
Thanks to @blimpa, @Deimos, @LongForWisdom, and everyone else that helped with the revision.
Edit2: removed the MIP4c2-SP11 from dependencies, moved to formal submission.

3 Likes
Weekly MIPs Update #30
Maker Relay Ep. 36 - en español
Maker Relay Ep 36
Weekly MIPs Update #29
Maker Relay Ep. 35 - en español
[Agenda/Discussion] Scientific Governance and Risk #131 - Thursday, March 4 17:00 UTC
Maker Relay Ep 35
[Agenda/Discussion] Scientific Governance and Risk #130 - Thursday, February 25 17:00 UTC
Maker Relay Ep. 34 - en español
Maker Relay Ep 34
Weekly MIPs Update #28
Maker Relay Ep. 33 - en español
Maker Relay Ep 33
Weekly MIPs Update #27
Maker Relay Ep. 32 - en español
Maker Relay Ep 32
Maker Relay Ep. 31- en español
Maker Relay Ep 31
Maker Relay Ep. 30 - en español
Maker Relay Ep 30
Maker Governance Review: January 2021
Weekly MIPs Update #26
TL;DR Core Unit MIPs Submission Process
Maker Relay Ep. 29 - en español
Maker Relay Ep 29
Know Your MIP KYM#03: The Core Operating Unit Model - Monday Jan. 25 2021 at 20:00 UTC
Maker Relay Ep. 28 - en español
Maker Relay Ep 28
Road to DAO: the Core Unit Operating Model
Maker Relay Ep. 37 - en español
Maker Relay Ep 37
#2

MIP39c2: Adding/Modifying Core Units

Preamble

MIP39c2-SP#: #
Author(s):
Contributors:
Status:
Date Applied: <yyyy-mm-dd>
Date Ratified: <yyyy-mm-dd>

Specification

Motivation

  • Why are you proposing this Core Unit?

Core Unit ID

  • To be assigned by the MIP Editor / Governance Facilitator when new.
  • Specify the Core Unit ID if modifying an existing Core Unit.

Core Unit Name

  • Please write the proposed name of the Core Unit, being as specific as possible about the essence of what the Core Unit will be doing.

Core Unit Mandate

  • The Core Unit Mandate is the broad scope of what problems the Core Unit must solve, and what must be operated and maintained for the Core Unit to contribute to the success of the project.
  • The Core Unit Mandate should be specific enough to ensure that Maker Governance has clarity about what problems it is solving when delegating resources to the Core Unit.
  • Beyond that, the Core Unit Mandate should be as broad as possible in order to leave room for Facilitators to implement a flexible approach to solve the problems as the environment change.
  • The Core Unit Mandate can also contain directives, guidelines or suggestions from Governance that helps inform Facilitators and Contributors of the Core Unit how to act in certain situations.
Road to DAO: the Core Unit Operating Model
TL;DR Core Unit MIPs Submission Process
#3

MIP39c3: Removing Core Units (Subproposal Process) Template

Preamble

MIP39c3-SP#: #
Author(s):
Contributors:
Status:
Date Applied: <yyyy-mm-dd>
Date Ratified: <yyyy-mm-dd>

Specification

Motivation

  • Why are you proposing to remove this Core Unit?

Core Unit ID

  • Specify the Core Unit ID.
  • This element specifies which Core Unit you are proposing to remove.
Road to DAO: the Core Unit Operating Model
#4

Edit: Adding + Modifying have been merged into one subproposal.

Road to DAO: the Core Unit Operating Model
#5

You mention domains here, I think somewhere later you confirm that these are not strictly defined, but I wonder if this might cause confusion to include it in a summary. Maybe just refer to the DAO, rather than domains?

I’d be tempted to combine these (assuming that you can ‘amend-via-replace’) just to cut down on the number of templates + text in this MIP.

This should maybe try to be more in-depth. Why the Core Unit structure over the existing domain structure, why this over other structures, etc.

Short word on formatting. I would avoid long lists of bullet points. It’s better than wall-of-text, but breaking up the content more naturally would make it easier to engage with.

Having read the section, I’m also not sure these qualify as definitions.

What does primary mean in this context?

I’m not sure this adds much, and might make things less clear. I think it’s trying to communicate that Core Units can cover domains and objectives? And also sort of define domains and objectives. If those are the aims they can probably be achieved with more clarity by rewording.

Might be better as its own component? Or at least it’s own subheading on ‘Core Unit Mandates.’ Budgets and Governance powers haven’t really been defined at this point. I would also seriously consider including a reference to some example good versus bad mandates here.

Redundancy is good, I’m not sure duplicating core units with identical mandates is the best way to achieve it (especially at this stage of the DAO’s development). I’ll come back to this in later feedback.

Please try to match the layout used for other process components in other MIPs. Also, these process components should specify which template must be used for the subproposal.

Be specific, whose job is it to update the DAO Primitives State MIP? If it’s not defined, it’s less likely to be done.

Should this have restrictions around existing budgets? For example, if governance votes in a mandate to do one thing, and the mandate is modified, should there be a requirement to update the budget? If so, this requirement should be explicitly noted.

How does this interact if Governance wishes to remove a Core Unit, but the Facilitator is not willing to step down? Also up to this point ‘active budget implementations’ has not been defined.

#6

Hi, I have a question about overlapping and redundancy. Is that ideal as conventional wisdom tends to avoid redundancy rather than embracing it?

#7

“conventional wisdom” does not apply necessarily to blockchains/decentralised organisations.

E.g.,

  1. Blockchains (Bitcoin, Ethereum) are based on a redundant (in fact, as redundant as possible!) set of nodes, each having the copy of the same data. This is because any of these nodes could go offline, be corrupted, be malicious, be censored, etc
 So you need redundancy to make sure things work even when bad stuff happens.

  2. Similarly, in a DAO, you can’t necessarily prevent a Core Unit from, e.g., disappearing at any time. After all, there are no “real word contracts” being signed, the contributors could be anonymous, etc
 Some degree of redundancy is needed to make sure that operations are maintained up even if something goes wrong somewhere.

4 Likes
#8

Probably @iammeeoh’s answer is more complete, but the short answer is:

“If a contributor wants to create it, and Governance wants to fund it
”

This is a framework to make the process more transparent / clear / manageable.

3 Likes
#9

Indeed, conventional wisdom is just a belief that has been around for a while, which isn’t necessarily true. Based on what you said, redundancy is insurance, protecting MakerDAO from something supposed to work but isn’t. These are still early days, but I see that the community will probably find a way to balance risk and efficiency. Thanks for your reply.

4 Likes
#10

I think it’s a balance: the ideal is not applicable to everything. There are some instances where you can’t have overlapping. That being said, adding to @iammeeoh thoughts, I can think of four types of instances:

  1. Like sports teams - there’s one set of primary starters and one may be “bench” to provide backup or additional people ramping up into the primary place.
  2. Having more than one team work on something (like a collateral evaluation or audits) provides multiple sets of data that could be helpful to compare.
  3. Unstoppable / distributed information - Instead of two teams running two different forums - maybe there’s always a copy backing up or it’s hosted in multiple places so if and when a server comes down or one of the owner stops/leaves, it continues for the greater group.
  4. Same function, different value propositions - if there’s one core unit that offers x value proposition (specific relationship, price, nuanced expertise or approach), you can have another different core unit that offers y value prop. Governance may pay twice for one function, but it is actually gaining a wider reach.

Ideally, we still have collaboration (and coordination at minimum) between teams. That’s what Operational Support is trying to help balance :slight_smile:

3 Likes
#11

What, if anything, is being done to protect core units from the sort of legal/regulatory liabilities we currently rely on the Foundation to navigate?

1 Like
#12

It will be up to the Core Unit based on several factors:

  • How they want to organize themselves
  • Where they are located
  • Where are their Contributors located
  • Others.

We’re trying to facilitate different resources based on the needs of each Core Unit.

Feel free to reach out, @seth if you want to discuss something more in depth.
I’ll be happy to put you in touch with the pros.

#13

Edited incorporating feedback + PR in github.

#14

Love it!

How do we utilize this AND ensure the DAO doesn’t get plagued in bureaucracy and incumbent thinking? The DAO needs top talent and to be nimble, no doubt
 and at the same time, every group / core unit (and every mandated actor) should be accountable to the DAO (and maybe on a reoccurring (annual?) basis reconfirm roles with the DAO voting)?

4 Likes
#15

Thanks, @mrabino1.

This Framework is trying to address exactly that:

  • It provides the DAO a “Core Unit” directory (MIP38), with their mandates, budgets, and facilitators to provide an overview.
  • It allows the DAO to turn on/off any Core Unit / Budget / Facilitators in a simple way (MIP39, MIP40, MIP41).
  • Reporting should give the DAO a good overview of how each unit is performing.

Then there are possibilities of overlapping Core Units for redundancy, healthy competition, etc. We’ll see how that pans out in the future.

#16

What I am referencing is not so much a turn off
 as it is a re-apply
 Turning off implies that the community dislikes certain outcomes / people. More than anything I want to ensure the DAO doesn’t get a bloated budget by endlessly staffing folks with somewhat the expectation of perpetual income.

By integrating a re-application process, two things happen.
1.) The actors / units have ~certainty of their engagement for X time.
2.) Both the actor and the DAO both know, things can and will change with time.

(~certainty being of course conditioned upon the DAO not terminating mid-stream)

4 Likes
#17

“Default-divorce” can be a good approach.

#18

This is my recommendation.

#19

On the other end of the spectrum is “Governance votes every single day”.

What do you think it’s a good trade-off (regarding time)? How often should these votes happen?
6 months? 12 months? 18 months?

#20

This has the perception that someone is “fired”
 and that is politically challenging to present
 we need a way to keep things sharp and efficient.

re timing

no more frequently than annual
 in my eyes
 actors need (some degree of) certainty


2 Likes