MIP41: Facilitator Framework

MIP41: Facilitator Framework

Preamble

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

References

MIP41c4-SP-Template
MIP41c5-SP-Template

Sentence Summary

MIP41: Facilitator Framework contains a framework with subproposal processes for managing Facilitators and modifying them in the DAO Primitives State MIP.

Paragraph Summary

MIP41: Facilitator Framework contains a framework with subproposal processes for managing Facilitators and modifying them in the DAO Primitives State MIP. Facilitators are the accountable individuals responsible for interfacing between Maker Governance and the Contributors and different resources to achieve the Core Objectives of the Protocol. Facilitators are always attached to one or more Core Units and cannot exist in a void, i.e., Facilitators are Facilitators only inasmuch as they are attached to at least one Core Unit.

Component Summary

MIP41c1: The Facilitator Framework
Gives an overview of the important characteristics of the Facilitator Framework MIP.

MIP41c2: Facilitator Governance Powers
Specifies the unique powers that Facilitators have when interacting with the Maker Governance processes.

MIP41c3: Governance Facilitator Governance Powers
Specifies the special case of Governance Facilitators and their central role in the Maker Governance processes.

MIP41c4: Facilitator Onboarding
A process component that defines the process for onboarding a new Facilitator to a Core Unit or moving an existing Facilitator to a different Core Unit.

MIP41c5: Facilitator Offboarding (Subproposal Process)
A process component that defines the process for removing a Facilitator from a Core Unit.

MIP41c6: Interim Facilitators and the Fallback Decision Process
Specifies how Interim Facilitators function, the situations where they are necessary, and how they are invoked.

Motivation

A Facilitator is the most trusted actor in the MakerDAO community; they are given a high degree of autonomy and have resources and governance powers at their disposal. This Framework provides Governance with a simple way of managing and holding Facilitators accountable through the MIPs process.

Specification / Proposal Details

MIP41c1: The Facilitator Framework

Facilitators play a key role in the Maker ecosystem by acting as the link between Maker Governance and the Contributors. Facilitators are always attached to a Core Unit that defines their primary responsibility and their Budget and Governance Powers.

The Core Unit Budget allows the facilitators to meet their responsibilities by hiring Contributors and purchasing services and products. Facilitators attached to a Core Unit administer the Budget for that Core Unit. How this is implemented in practice depends on the specific Budget Implementation.

The Facilitator Commitment is an essential part of a Facilitator proposal, where the Facilitator specifies their perspective, in as great detail as possible, on how to successfully achieve the Core Unit Mandate of the Core Unit they are proposing to onboard to, and how they plan to organize and provide accountability into their use of the budget.

The Facilitator Governance Powers enable the Facilitators to efficiently interact with Maker Governance processes related to their Core Unit.


MIP41c2: Facilitator Governance Powers

Facilitators have special privileges in the Maker Governance Framework due to their trusted status in the Community and the requirements of their role as Facilitator of a Core Unit.

Facilitators have the power to propose expedited, urgent or emergency Executive Votes (defined in MIP24) related to their Core Unit.

Facilitators have the power to propose weekly non-standard Governance Polls (defined in MIP16) related to their Core Units.

Facilitators have the power to propose weekly Executive Votes (defined in MIP16) related to their Core Units.

Facilitator governance powers for particular Core Units can be extended through MIPs. They may include technical access to smart contracts like multisigs or other privileges in the governance process.


MIP41c3: Governance Facilitator Governance Powers

The Governance Facilitator role is a special case of a Facilitator attached to a Core Unit that contains GOV in the Core Unit ID in the DAO Primitives State MIP.

Governance Facilitators are fundamental to the operation of the various governance processes and have powers and responsibilities defined in multiple MIPs in relation to this. This includes:

  • The MIPs Framework (MIP0).
  • The weekly governance cycle (MIP16).
  • The urgent and emergency voting processes (MIP24).

Governance Facilitators interpret the meaning of MIPs and their practical consequences.

Governance Facilitators decide whether a Facilitator’s proposal to the weekly cycle is related to the Facilitators Core Unit, and therefore valid.


MIP41c4: Facilitator Onboarding

This process component allows Governance to onboard a new facilitator with a Facilitator Commitment.

Practical control of the budget of the Core Unit is transferred as a part of this Subproposal process. Depending on the Budget Implementations, a Subproposal may contain a technical state change to modify the Budget Implementation control to correspond to the new Facilitator.

The proposal parameters are:

  • Minimum feedback period: 1 month
  • Minimum frozen period: 1 week

Once a Subproposal passes, the MIP Editor or Governance Facilitators modify the Core Unit’s entry specified with the new Facilitator’s name and information, and the new Facilitator Commitment.


MIP41c5: Facilitator offboarding

This process component allows Governance to offboard a Facilitator.

Depending on the Core Unit’s Budget Implementations, this Subproposal may include a technical state change to remove control of the Budget Implementations from the offboarded Facilitator.

The proposal parameters are:

  • Minimum feedback period: 1 month
  • Minimum frozen period: 1 week

Once a Subproposal passes, the MIP Editor or Governance Facilitators modify the Core Unit’s entry specified by removing the Facilitator’s name and information, and their Commitment.


MIP41c6: Interim Facilitators and the Fallback Decision Process

Interim Facilitators

When the Facilitator of a Core Unit becomes unavailable, an existing permanent Facilitator of another Core Unit is temporarily attached to allow the aforementioned Core Unit to maintain the continuity.

The Interim Facilitator controls the budget to continue doing regular payouts to core Contributors and pay for other critical expenses and infrastructure while a permanent Core Unit Facilitator is sought.

The Fallback Decision Process

Interim Facilitators are designated based on the Fallback Decision Process, where a simple majority of all currently active Facilitators have to reach an agreement. The Fallback Decision Process can instantly designate an existing Facilitator (who must agree to the decision) and assign them as an Interim Facilitator to a Core Unit that is without a Facilitator, or that has a Facilitator who has gone missing.

The Transition

Once an Interim Facilitator has been assigned to a Core Unit through the Fallback Decision Process, the Community must then work together to transition over the critical responsibilities that must be maintained to continue operations of the Protocol until a permanent Facilitator can be found to replace the Interim Facilitator.

Budget Implementations Transitions

Most importantly, this change involves transitioning control of the Budget Implementations that need to continue to run smoothly to pay out Core Unit’s Contributors properly. How this is done in practice depends on the particular Budget Implementation. For example, it could involve using a multisig authority to change control of the Budget Implementation directly. Or propose an executive vote to the Weekly Governance Cycle. Or, in very time-sensitive cases (such as active embezzlement, Facilitator missing), an urgent/emergency executive vote that changes the control of the Budget Implementation, or another appropriate solution that works with the specific Budget Implementations.

Governance Powers

The Interim Facilitator may also need to use Governance Powers of the Core Unit to keep existing operational processes running smoothly during the interim period.




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.

5 Likes

MIP41c4: Facilitator Onboarding (Subproposal Process) Template

Preamble

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

Specification

Motivation

  • Why are you applying to become a Facilitator?

Core Unit ID

  • Specify the Core Unit ID.
  • This element specifies which Core Unit you are proposing to onboard to as a Facilitator.

Facilitator name and information

  • This element must contain the Forum name of the Facilitator, as well as other names and IDs in Maker related communication channels. Additionally it must contain the Facilitators Ethereum address used for Budget Implementation control and other authorizations.

Facilitator Commitment

  • The Facilitator Commitment is a detailed description and plan of what the Facilitator plans to do in order to achieve success for the Core Unit. There is a lot of flexibility in what a Facilitator can write in their commitment, including organizational structure and theory, plans for the budget, hiring and infrastructure plans, etc.
  • The Facilitator commitment should also contain targets and goals that can be observed by Governance, if appropriate. This helps Governance to see whether the Facilitator is living up to their expectations.
  • A crucial part of the Facilitator Commitment are clear commitments to transparency. The Facilitator should commit to an effective plan that will allow Governance and other stakeholders, such as contributors contemplating doing work, to gain direct insight into what is being worked on and who are taking care of what responsibilities.

MIP41c5: Facilitator offboarding (Subproposal Process) Template

Preamble

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

Specification

Motivation

  • Why are you proposing to offboard this Facilitator?

Core Unit ID

  • Please specify the Core Unit ID.
  • This element specifies which Core Unit you are proposing to offboard the Facilitator from.
1 Like

Needs more detail. This doesn’t really touch on the motivations at all.

Is this 1 facilitator can only facilitate 1 core unit?

Interesting idea, this is in addition to the mandate, right? Feels a bit like facilitators needing to pitch themselves to do the domain, which I don’t love as a facilitator. I can see why it might be good from a community perspective though.

I’m not sure that this is always true of all Core Units. We should maybe be careful stating that it extends to all Core Units.

This could use clarifying. There is only 1 executive vote per week, so what they are proposing isn’t necessarily a weekly executive vote, but rather contents to that vote, or an out-of-schedule executive. I would also suggest that this is limited to Governance Facilitators. Also this may change with DssGov.

These should maybe be clarified to be more wide-spread than governance powers. For example the power to adjust a risk parameter within a certain range maybe isn’t a governance power necessarily, but it is privileged access to the Protocol.

This is difficult to parse, and slightly ambiguous. Suggest using quotation marks to denote the name. I would also specify that it is exactly this name. Something like: The Governance Facilitator role is a special case of a Facilitator attached to a Core Unit with the exact name ‘Governance’ in the DAO Primitives State MIP.

MIP5 was replaced.

This should be clarified: “Governance Facilitators interpret the meaning of MIPs and their practical consequences in the case where there is ambiguity or differing understandings of how a MIP operates on the part of the community.”

This should be clarified. This covers expedited, urgent and emergency Executive Votes and Governance Polls. Also, in the event of duplicated Core Units saying different things, do the Governance Facilitators adjudicate? If we have two Risk Core Units, and one is saying ‘we need to propose this’ and the other is saying ‘we think proposing this is a bad idea’ who makes the call?

Who makes this change?

So I don’t believe that we should enforce a one-facilitator to one-core-unit rule, this is especially true for Governance, but probably also true for other domains. There are lots of reasons I feel this is important, it’s a non-trivial argument though, so I’ll try to cover it elsewhere once I can write it up in detail.

I’m also not convinced this is a good idea at this stage. We don’t have that many people who would make good facilitators, we may want some individuals to wear multiple hats, especially at this stage.

Also, these requirements should be stated more clearly outside of this component (IE that it’s 1-1 mapping between facilitators and core units.

This should be reworded. If this is being proposed by someone other than the facilitator themselves, it should always include a transfer of control for the budget.

This should be explicitly gated by the Governance Facilitators. The main argument as to why facilitators get this power is because they are experts in the core unit area, this isn’t necessarily true for interim facilitators, so this power should probably not automatically be granted.

So I have a question regarding potential conflicts between the DAO’s intentions and legacy contracting/entities. Let’s say that a Facilitator creates an entity and then uses this entity to run their Core Unit. This entity signs long term contracts, perhaps with development firms or other service providers. If this Facilitator is removed by the DAO, how will you transfer the contracts and IP from the removed Facilitator’s entity to its replacement? It seems to me as though these agreements would remain with the original Facilitator’s entity, that they wholly own, and the DAO could potentially find itself without valuable assets that it spent significant resources to acquire. It could also find itself in breach of agreements if the removed Facilitator stops making payments due to having their budget cut off.

4 Likes

We answered this during Know Your MIP KYM#03: The Core Operating Unit Model - Monday Jan. 25 2021 at 20:00 UTC, but the short version of the answer:

IP

In terms of Intellectual Property, we will most likely have to sign contracts where all the IP belongs to the Dai Foundation. There might be exceptions and different cases, but this will not be covered by this MIP Set. @juank (and others) are working on tackling this.

Business Continuity

Regarding the potential transition to another Facilitator, it will depend on the transition itself. It is quite difficult to anticipate all the possible scenarios but, worst-case scenario, every contract can be signed again with the Contributors and make sure that the funds keep flowing to maintain the services.
There are several much more “elegant” solutions that can be achieving by setting up the Core Units / Legal Entities / Contracts.

This has been addressed better in the reviewed version of this MIP. Thanks @g_dip for the comment.

1 Like

Edited incorporating feedback + PR in github.

1 Like