MIP113: Governance Scope

0: The Governance Scope

The Governance Scope covers rules that regulate the critical balance of power, and adjudicate on appeals processes related to misalignment in the ecosystem.

1: Scope Improvement

1.1: The Governance Advisory Council

The Governance Advisory Council is a group of Ecosystem Actors that have been approved by Maker Governance to carry out advisory work related to improving the content of the Governance Scope Artifact.

1.1.1: Governance Advisory Council Membership Management

Members of the Advisory Council are directly approved by Maker Governance through a governance poll, and must fulfill specific criteria.

1.1.1.1

The Governance Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions as per 1.1.1.3.

1.1.1.2

Advisory Council Members must be Ecosystem Actors that are not involved in any business, political, or other governance-related activity that could result in a conflict of interest, either directly or indirectly. They must also have relevant skills for providing professional expert input on the content that the Governance Scope is covering.

1.1.1.3

The Governance Facilitators must periodically, when it is relevant, review the Advisory Council Applications, and if they find applications that are suitable, bring them to a vote through an MKR governance poll. When Advisory Council Applications are posted on the Maker Forum, which must follow the template as per 1.1.2.4.1A, the Governance Facilitators have a review period of 30 days. During this review period, the applicant must host a Community Q&A and shall answer as many questions and doubts as possible.

1.1.1.3.1

The Governance Facilitators can extend this deadline, if necessary, by 15 days, provided they posted the justification in the Maker Forum.

1.1.1.3.2

Once the review period is ended, the Governance Facilitators must publish the response to the application on the Forum, along with a description of the reasoning behind the decision. If approved, the application will continue with the Governance Process and proceed to a vote as per 1.1.1.3.

1.1.1.3.3

Upon a successful vote, the Governance Facilitators must arrange a service contract with the Advisory Council member, which must be made public. Approved Advisory Council Members are added to 1.1.1.6.1A.

1.1.1.3.4

Approved Advisory Council members have a term of service of 18 months from the time they are approved by Maker Governance. If desired, the Advisory Council Member can submit a new application for re-election when their term has between 60 and 30 days remaining. The re-election application must also fulfill 1.1.2 requirements and will open a new review period of 30 days where the Maker Community can provide feedback. The applicant shall again host a Community Q&A and respond to as many questions and doubts as possible. If approved, the re-election application will continue with the Governance Process and proceed to a vote as per 1.1.1.3.

1.1.1.4

The Governance Facilitators may, if they deem it necessary, trigger a vote to remove an Advisory Council Member. If an Advisory Council Member has not done any paid work for the Scope for at least 1 year, then the Governance Facilitators can choose to remove them at will, if they deem it necessary.

1.1.1.5: Governance Advisory Council Requirements

1.1.1.5.1

Governance Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Governance Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. The Governance Scope Advisory Council is crucial in this stage of changes that Maker Governance is going through. This council should be composed of highly skilled entities who can quickly adapt to constant changes. They should have or be willing to attain a deep understanding of the Maker Ecosystem and its endgame goals. They should also be aligned with the Atlas and Scope Artifacts. Ideally, the council should include at least one external member who may not be familiar with Maker initially but exhibits a quick learning aptitude. The addition of an external member could provide an unbiased viewpoint and facilitate out-of-the-box thinking.

1.1.1.5.2

Desired competencies for members of the Governance Advisory Council, as many of the following as possible:

  1. Deep understanding of MakerDAO, both at the protocol and governance level.

  2. Deep and proven thought leadership in the field of decentralized governance, common good stewardship or other processes that coordinate a very large number of independent and often unpaid actors.

  3. Hands-on experience in running a DAO or another plurality protocol. Examples include DeSoc movement, Twitter Community Notes, and Wikipedia.

  4. Specializations in any of the following fields: political science - particularly specializing in power dynamics, international trade, law, psychology, business administration, philosophy - ideally specializing in game theory, and any other science that can benefit governance.

  5. Deep understanding of voting systems and their effects on candidate selection.

  6. Experience in people and resource management.

  7. Leadership skills and ability to handle pressure.

  8. Strong reading comprehension, excellent writing skills, and the ability to interpret whitepapers or large documents. Proven ability to communicate well and distill complex matters into simple, applicable terms, even under pressure.

  9. Deep understanding of consensus systems and game theory.

  10. Longstanding experience in moderation of high velocity and/or high impact forums or chats.

  11. Understanding of legal philosophy or arbitration processes.

1.1.1.6

The current approved Governance Advisory Council Members are recorded in 1.1.1.6.1A.

1.1.1.6.1A

¤¤¤

Current list of Advisory Council Members:

N/A

¤¤¤

1.1.2: Governance Advisory Council Recognition

1.1.2.1

In order to be eligible for the Governance Advisory Council as per 1.1.1.3, an Ecosystem Actor must post a recognition submission message publicly on the Maker Governance Forum.

1.1.2.2

The submission message must be cryptographically signed by the Ecosystem Actor address.

1.1.2.3

The cryptographically signed Governance Advisory Council Recognition Submission Messages must contain the information specified in 1.1.2.3.1 and 1.1.2.3.2.

1.1.2.3.1

The following text must be included: “[Name] Governance Advisory Council Recognition"

1.1.2.3.2

A timestamp recording the time and date that the message was signed.

1.1.2.4

The submission message must follow the template 1.1.2.4.1A

1.1.2.4.1A

Title: [Name] Governance Advisory Council Recognition Submission
        - [Ecosystem Actor Ethereum address]
        - [Cryptographically signed Advisory Council Recognition Submission Message]
        - Applicant's name: [Company, team, or individual]
        - Any other relevant identifying details:
            - Twitter:
            - Website:
            - Email:
            - Maker Forum:
            - Telegram:
            - LinkedIn:
            - Discord:
            - Github:
            - Other:
        - Presentation: [Introduction]
        - Ethos and Vision:
        - Team: [Founders and team members. Brief description of their skills and backgrounds]
        - Services: [What is your company specialized in? What kind of services do you offer?]
        - Experience: [A detailed history of relevant previous experience]
        - Client References: [Who are your clients, what projects have you done and can you show the results of any of them?]
        - Explain how your skills will contribute to improving the selected Scope: [Which specific aspect of the Scope do you intend to enhance, and what is the rationale behind your choice? How do you plan to improve the chosen aspect? Provide milestones, if applicable].
        - Payment Details: [How shall the compensation for your contributions be structured?  How many hours shall the work entail? Detail as much as possible]
        - Emergency Availability: [Would you be available on short notice to provide advisory support in the event of an unforeseen emergency? How short of a notice? What would be your hourly rate for emergency advisory services rendered?]

1.1.3: Governance Advisory Council Projects and Funding

The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework.

1.1.3.1

Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any entity can notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. There are also sometimes specific pieces of advisory work listed in 1.1.3.2 that can be taken on by applicants. The Governance Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Governance Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Governance Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Governance Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process.

1.1.3.2: Advisory Work for Governance Advisory Council Members

None yet identified.

1.1.3.3

Each Quarter, if they deem it necessary, the Governance Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Governance Facilitators. The Governance Facilitators must communicate in the first 15 days of a quarter if they believe no Advisory Council work is needed for that quarter.

1.1.3.4

In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Governance Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Governance Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.

1.1.3.5

The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Governance Facilitators must either transcribe it themselves, or hire an Ecosystem Actor to perform the transcription. This role does not require pre approval by Maker Governance.

1.1.4

The Governance Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content.

1.1.5

The Governance Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in 1.1.5.1B.

1.1.5.1B

¤¤¤

Applicants should note that budgets for Advisory Councils are intentionally accommodative across the board in order to avoid having to delay by a full monthly governance cycle in unforeseen circumstances. They are not meant to be fully spent, and attempts to spend full budgets are less likely to be approved.

Advisory Council project budget:

¤¤¤

1.1.6: Advisory Work for Governance Advisory Council Members

None yet identified.

1.2: Governance Scope DAO Toolkit Integration

The Governance Scope DAO Toolkit module must be built to give a full and accessible overview of all data and processes relevant to the Governance Scope.

1.2.1

The DAO Toolkit should contain a section displaying all polls and executive votes along with associated threads and relevant items. For executive votes, a specific section should display relevant spell constants, the smart contract repository, smart contract address, and code hash.

The DAO Toolkit module, within the Governance Scope, will encompass all data related to the Scope. This includes information on Governance Facilitators, Advisory Council Members, their proposals, project statuses, budget, and Atlas Interpretations. Additionally, the DAO Toolkit should contain a section displaying all polls and executive votes along with associated threads and relevant items. For executive votes, a specific section should display relevant spell constants, the smart contract repository, smart contract address, and code hash.

1.2.2

The DAO Toolkit should contain a section presenting all active ADs, their current and past rankings. This section should also provide actions that an AD can perform, such as stepping down or requesting tech ops support.

The DAO Toolkit module should seamlessly integrate with the ongoing governance processes of MakerDAO. This includes real-time updates and alerts for important governance events. Furthermore, the DAO Toolkit should contain a section presenting all active ADs, their current and past rankings. This section should also provide actions that an AD can perform, such as stepping down or requesting tech ops support. Another section should show all active AVCs and their members. This section should facilitate AVC members to perform actions such as submitting formal decisions, filing quarterly reports, stepping down, or requesting tech ops support.

1.2.3

The DAO Toolkit should contain a section showing all active AVCs and their members. This section should facilitate AVC members to perform actions such as submitting formal decisions, filing quarterly reports, stepping down, requesting tech ops support, and disacknowledging a delegate.

2: Atlas Immutable Alignment Artifact

The Atlas Immutable Alignment Artifact is the foundation of the Maker Governance process, and aims to guarantee a long term decentralized governance equilibrium. Atlas Interpretation is used to disambiguate elements in the Atlas with expanded definitions, in connection with specific decisions or disputes relying on language from the Atlas. To make the Atlas as solid and immutable as possible, all Atlas Interpretation is recorded to set a precedent about the spirit of the Atlas and how future interpretations should be made.

2.1: Principles of Atlas Interpretation

Atlas Interpretation should only be employed when the Scope Artifacts themselves do not offer enough clarity. The resolution of Scope Artifact ambiguity or disputes must be fully congruent with the spirit of the Atlas and prior precedent, while also clearly setting new precedent and help to prevent future ambiguous situations from occurring. Depending on the level of ambiguity, an MKR vote may be needed to establish the precedent.

2.2: Atlas Interpretation Process

This section contains the processes for proposing and settling Atlas Interpretations.

2.2.1

Atlas interpretation precedent approved through MKR vote is contained as Strengthening subelements of this clause. A majority of Governance Facilitators can trigger a vote to add a new subelement if it is necessary to resolve Atlas ambiguity.

2.2.2

Atlas Interpretation precedent made directly by the Governance Facilitators is contained in 2.2.2.1A.

2.2.2.1A

¤¤¤

List of direct Atlas Interpretations:

  1. Payments denominated in NewGovToken in the Atlas or the Scopes will be made in MKR prior to the launch of NewGovToken at the proscribed conversion rate listed in The Atlas.

¤¤¤

3: Scope Bounded Mutable Alignment Artifact (Scope Artifact)

3.1: Scope Artifact Appeals

Scope Artifact appeals are a process that allows any Maker Governance participant to trigger a review of a Scope Artifact. This can be in connection with the Scope Artifact failing to follow the Atlas Boundaries, or if it contains biased or otherwise conflicted elements. It can either be a general misalignment of the language of the Scope Artifact, or a specific situation where the Scope Artifact is being misinterpreted or otherwise violated.

3.1.1: Scope Artifact Appeals Process

Scope Artifact appeal proposals are submitted by AVC Members, and can be accepted or rejected by a majority of the Governance Facilitators. If a Scope Artifact appeal is accepted, the Governance Facilitators must review it. Governance Facilitators can also directly choose to review a Scope Artifact for adherence with Scope boundaries and Atlas alignment.

3.1.1.1

The Governance Facilitators can by consensus directly edit a Scope Artifact to align its content with the Scope boundaries and other Atlas requirements such as neutrality.

3.1.1.2

A majority of the Responsible Facilitators can trigger an MKR governance poll to implement an edit to the appealed Scope Artifact that will align it with the Scope boundaries and other Atlas requirements such as neutrality.

4: Alignment Conservers

The Governance Facilitators must ensure the rules of Alignment Conservers specified in ATL2.4 are followed. Governance Facilitators must act against Alignment Conservers if they break rules specified in the Atlas or the Scope Artifacts, or act misaligned. Any Governance Facilitator may do this directly.

4.1: Alignment Conserver Derecognition

4.1.1

Derecognition notices are issued publicly and justification and reasoning must be provided by the issuing Governance Facilitator.

4.1.2

Derecognitions are recorded by adding the identity and known aliases or associated entities to 4.1.3A

4.1.3A:

¤¤¤

List of derecognized Alignment Conservers:

¤¤¤

4.2: Alignment Conserver Formal Warnings

4.2.1

Formal warnings are issued publicly and justification and reasoning must be provided by the issuing Governance Facilitator.

4.2.2

Formal warnings are recorded by adding the identity and known aliases or associated entities to 4.2.3A

4.2.3A

¤¤¤

List of formally warned Alignment Conservers:

¤¤¤

5: Aligned Voter Committees (AVCs)

AVCs are standardized Voter Committees made up of Alignment Conservers that hold MKR and participate in the Maker Governance process as actors that are deeply aligned with MKR holders. They are subject to specific requirements, and receive various benefits, resources and support from the Support Scope. They have significant formal powers, but no direct physical power, making them well suited to be in control and making key decisions during normal conditions.

AVCs focus on making sure that the day to day Letter of the Rules of the scopes are aligned with the spirit of rules and Universal Alignment. The AVCs impact on Maker Governance is to make marginal improvements to the Alignment Artifacts that strengthen them. As AVCs make detailed Universal Alignment interpretations, they must all follow a particular Strategic Perspective that informs their subjective definition of Universal Alignment.

The Stability Facilitators must ensure that the processes related to Aligned Voter Committees specified in ATL2.5 are followed.

5.1: Aligned Voter Committee Decisions

AVC splits are disabled until the launch of NewChain.

5.2: Aligned Voter Committee Member Recognition

5.2.1

To become recognized as an Unaffiliated AVC Member, an Ecosystem Actor must post a recognition submission message publicly on the Maker Governance Forum.

5.2.1.1

A recognition submission message must be cryptographically signed by an Ethereum address containing at least 1 MKR, or that has delegated at least 1 MKR.

5.2.1.2

The cryptographically signed AVC Member Recognition Message must contain the information specified in 5.2.1.2.1 and 5. 4.1.2.2. The information specified in 5.2.1.2.3 and 5.2.1.2.4 is optional.

5.2.1.2.1

The following text must be included: "AVC Member Recognition".

5.2.1.2.2

A timestamp recording the time and date that the message was signed.

5.2.1.2.3

The desired name of the AVC Member.

5.2.1.2.4

The AVC that the AVC Member wishes to join, if applicable.

5.2.1.3

A recognition submission message must use the format described in 5.2.1.4.

5.2.1.4

Title: AVC Member Recognition submission
AVC member recognition submission
[Ethereum address]
[Cryptographically signed AVC Member Recognition Message]

5.2.2

The Governance Facilitators must maintain the list of Unaffiliated AVC Members contained in 5.2.2.1A.

5.2.2.1A

¤¤¤

List of Unaffiliated AVC Members:

¤¤¤

5.2.3

An Unaffiliated AVC Member may join an AVC through the process described in 4.5 or start a new AVC through the process described in 4.4.

5.2.4: AVC Management

The Governance Facilitators must monitor and record the status of each AVC.

5.2.4.1

An AVC is marked as active status if it has fulfilled every requirement under 4.3 in the previous quarter.

5.2.4.2

An AVC is marked as inactive status if it has failed to fulfill the requirements under 4.3 for the most recent quarter, but has fulfilled the requirements for one or more prior quarters.

5.2.4.3

An AVC is marked as pending status if it has been in existence for less than one full quarter.

5.2.4.4

An AVC that has failed to fulfill the requirements under 5.2.4 for two consecutive quarters is no longer considered an AVC and is removed from the list in 5.2.4.6.1A.

5.2.4.5

The list of all AVCs is contained in 5.2.4.6.1A, broken down by current status. The Arbitration Facilitators must keep the list current based on AVC creation, adherence with requirements, and AVC Decisions.

5.2.4.6.1A

¤¤¤

List of active AVCs and their members:

KISS AVC

Regenerative Finance AVC

Resiliency AVC

Sovereign Finance AVC

List of pending AVCs and their members:

RISK AVC

List of inactive AVCs and their members prior to becoming inactive:

Composable AVC

Growth AVC

¤¤¤

5.3: Aligned Voter Committee Activation

If 2 or fewer AVCs are active, then newly created AVCs are instantly Active from the moment of creation. If 3 or more AVCs are active, then new AVCs have to comply with the activation requirements for a full quarterly governance cycle before becoming Active.

6: Aligned Delegates (ADs)

The Governance Facilitators must ensure that all the rules of ADs are followed as specified in ATL2.6

6.1: Aligned Delegate Recognition

The Governance Facilitators must maintain a list of Recognized Aligned Delegates, and maintain the process for applying for Recognition as an Aligned Delegate

6.1.1

The current state of ADs is maintained by the Governance Facilitators.

6.1.2

The list of all current recognized ADs is maintained in 6.1.2A.

6.1.2A

¤¤¤

List of current ADs:

¤¤¤

6.2: Recognition of Aligned Delegates

6.2.1

Aligned Delegates must be recognized by the Governance Facilitators if they fulfill the following requirements:

6.2.1.1

An Ecosystem Actor must publicly post a AD Recognition Submission Message on the Maker Governance Forum.

6.2.1.2

An Ecosystem Actor must deploy exactly 2 Protocol Delegation System smart contracts and specify which AVC Governance Strategy each of them follows as part of the submission message.

6.2.1.3

The submission message must be cryptographically signed by the deploying Ethereum address.

6.2.1.3.1

Since an Ethereum address may only control a single Protocol Delegation System smart contract, Aligned Delegates should cryptographically demonstrate that they control the Ethereum address that controls each of their deployed Protocol Delegation System smart contracts.

6.2.1.4

The cryptographically signed Aligned Delegate Recognition Submission Messages must contain the information specified in 6.2.1.4.1 and 6.2.1.4.2.

6.2.1.4.1

The following text must be included: "Aligned Delegate Recognition".

6.2.1.4.2

A timestamp recording the time and date that the message was signed.

6.2.1.5

The submission message must follow this template:

Title: AD Recognition Submission
AD Recognition Submission
[Ecosystem Actor Ethereum address]
[Ethereum address of Delegation Contract 1]:[Followed AVC 1]
[Ethereum address of Delegation Contract 2]:[Followed AVC 2]
[Cryptographically signed AD Recognition Submission Message from the Ethereum address controlling Delegation Contract 1]
[Cryptographically signed AD Recognition Submission Message from the Ethereum address controlling Delegation Contract 2]
[Cryptographically signed AD Recognition Submission Message from the Ecosystem Actor Ethereum address, where this address is not one of the addresses controlling a Delegation Contract]

6.3: Prime Delegate and Reserve Delegate Slots

The number of PD and RD slots is modifiable over time, and must be increased or decreased as the income of PDs increases or decreases, in accordance with the Atlas. The current number of PD and RD slots is specified in 6.3.1A. This single number applies separately to the number of PDs, and RDs, and also determines (by taking its double) the amount of AVC Member reward slots. The Governance Facilitators can unanimously, directly increase or decrease the number with 1 every 3 months. The Governance Facilitators can trigger a weekly governance poll to change the number to a new arbitrary number.

6.3.1A

¤¤¤

The current number of Prime Delegate and Reserve Delegate slots (applies separately to both):

  • 4

¤¤¤

6.3.2: Temporary Prime Delegate, Reserve Delegate, and AVC Member Compensation Modifications

As a temporary measure, Prime Delegate, Reserve Delegate, and AVC Member Compensation is reduced by 20% from the amounts specified in the Atlas.

7: FacilitatorDAOs and Facilitators

The Governance Facilitators must ensure that all the rules of FacilitatorDAOs and Facilitators are followed as specified in ATL2.7

7.1: Active Facilitators

Before the Launch of SubDAOs, Maker Governance directly chooses the Facilitators that are responsible for each of the Scopes.

7.1.1: Core Units and Facilitator Management

During the pregame, the Governance Scope manages and provides the budget for Core Units and Facilitators, while designating their responsible Scopes.

7.1.1.1

The Ecosystem Actor name, Ethereum address and budgets are contained in 7.1.1.1.1A. The Active Element is changed through the ordinary AVC process. Facilitator budgets are paid out even if the recipients are not active Facilitators, as long as they are using the budget to perform useful work for the Maker Ecosystem.

7.1.1.1.1A

¤¤¤

List of Facilitator budgets:

¤¤¤

7.1.2

The Scopes and their responsible Facilitators, or Responsible Facilitator Core Units, are contained in 7.1.2.1A. The Active Element is changed through the ordinary AVC process.

7.1.2.1A

¤¤¤

List of Responsible Facilitators:

¤¤¤

7.1.3

If all Facilitators of a Scope are unresponsive and not taking care of their duties, a majority of the remaining Facilitators can choose amongst themselves an interim Facilitator, that will then temporarily become the Responsible Facilitator for the Scope.

7.1.4

Reserve Facilitators can help protect the continuity of Maker Governance in case other Facilitators become unavailable. If the main Facilitators of a scope become unresponsive or otherwise unavailable, the Reserve Facilitators can initiate a take over as interim Facilitators by posting their observations of inactivity or unavailability to the Maker Core forum. If the take over is not disputed by the existing Facilitators within 48 hours, the Reserve Facilitators are changed to Facilitators in 7.1.2.1A, and must take care of the duties of the role until a new Facilitator is selected using the ordinary AVC process.

7.1.4.1

The Governance Facilitators can propose expedited onboarding of Reserve Facilitators in order to ensure enough Facilitators are available to guarantee governance continuity. This is done by posting the name(s), ethereum address(es) and scope(s) of responsibility of the proposed Reserve Facilitators to the Maker Core forum. This triggers a Governance Poll following the Weekly Governance Cycle. If the Governance Poll is approved, the Reserve Facilitators are added to 7.1.2.1A.

8: Professional Ecosystem Actors

The Governance Facilitators must put in place processes to monitor the Ecosystem Actors for risks of conflict of interest between Advisory Council Members and Active Ecosystem Actors, and ensure that the Scope Artifacts and the checks they place on Active Ecosystem Actors are in Universal Alignment with the Atlas.

9: Interaction of Aligned Voter Committees (AVCs), Aligned Delegates (ADs), FacilitatorDAOs and Advisory Council

The Governance Facilitators must ensure to follow and enforce the principles described in ATL2.9 to prevent misalignment of the core governance decision process.

10: Core Governance Security

The Governance Facilitators must ensure that adequate funding and research goes towards developing a long term solid and scalable Core Governance Security Framework, that must be specified in this Article and be in accordance with ATL2.11.

10.1: GSM (Governance Security Module) Pause Delay

The GSM (Governance Security Module) Pause Delay parameter sets the minimum amount of time after an executive vote has passed before changes will come into effect in the Maker Protocol. Once an executive spell passes, the GSM Pause Delay must pass before the changes within that executive spell can affect the Maker Protocol. The Maker Protocol only has one GSM Pause Delay, and all parameter changes are subject to it. The GSM Pause Delay is usually expressed in terms of hours.

It is possible to move functionality outside of the GSM Pause Delay; however, this requires additional engineering work. A list of exceptional functionality can be found in article “10.2: GSM Exceptions”.

10.1.1: Adjusting the GSM Pause Delay

Adjusting the GSM Pause Delay parameter is a manual process that requires an executive vote. Changes to the GSM Pause Delay are subject to the pre-change GSM Pause Delay.

An increase to the GSM Pause Delay parameter should be considered if the risk of governance attack is considered especially high for whatever reason. In the past, the GSM Pause Delay has been increased due to the risk from flash loans combined with increasing liquidity of the MKR token on the open market.

A decrease should be considered if time-critical governance actions are projected to be needed in the near future. For example, if extreme market volatility is expected, it may be beneficial to reduce the GSM Pause Delay temporarily to allow Governance to better react to the changing conditions.

10.1.1A

¤¤¤

The GSM Pause Delay is: 48 hours

¤¤¤

10.2: GSM Exceptions

This article lists the current exceptions to the GSM Pause Delay.

10.2.1: Executive Drop

The MCD_PAUSE contract manages the general governance timelock of the GSM Pause Delay; however, it also contains an in-built exception to its own rule.

The executive drop functionality allows a successful governance proposal to cancel a previous governance proposal that has not yet passed the GSM Pause Delay period and been executed. Like any other, the new executive proposal must be the hat proposal, meaning more MKR is voting for it than is voting for any other executive proposal.

This functionality allows Maker Governance to prevent a malicious attack on the protocol if they are able to exceed the attacker's MKR weight before the GSM Pause Delay expires.

The risk opened up by this exceptional functionality is that a malicious attacker may be able to delay or permanently block a legitimate governance proposal.

10.2.2: Oracle Freeze

The OSM_MOM contract manages the freezing of MakerDAO's oracles. The freeze functionality allows a successful governance proposal to immediately freeze the oracle price for any or all of the vault types in the Maker Protocol. Once frozen, the oracle price will remain at its current value.

The oracle cannot be unfrozen without waiting for the GSM Pause Delay as part of a regular governance proposal.

The risk opened up by this exceptional functionality is that the oracles may be frozen by an attacker in order to either:

  • Prevent an expensive liquidation.

  • Take advantage of a significant drop in collateral prices to mint unbacked Dai.

10.2.3: Debt Ceiling Breaker

The LINE_MOM contract manages the breaker for the Debt Ceilings of a configurable subset of the vault types in the Maker Protocol. This Debt Ceiling Breaker allows a successful governance proposal to reduce the debt ceilings of a pre-configured whitelist of vault types to zero without waiting for the GSM Pause Delay to expire.

The Debt Ceiling Breaker affects both the Debt Ceiling and the Maximum Debt Ceiling of a given vault type when activated, disabling the Dynamic Debt Ceiling functionality for that vault type if enabled. To reverse the effect, parameters of affected vault types must be reconfigured with an executive vote which is subject to GSM Pause Delay.

The whitelist may be configured via a successful governance proposal, but must wait the GSM Delay before changes come into effect. At time of writing, the following vault types are whitelisted on the Debt Ceiling Breaker:

  • PSM (USDC) - PSM-USDC-A

  • PSM (PAX) - PSM-PAX-A

  • PSM (GUSD) - PSM-GUSD-A

10.2.4: Liquidations Circuit Breaker

The CLIPPER_MOM contract manages the circuit breaker for vault types using Liquidations 2.0. The circuit breaker functionality allows a successful governance proposal to impose Maker Governance's choice of limitations on liquidations for any or all of the vault types in the Maker Protocol.

  • Level 0 - Liquidations Enabled - The breaker is not tripped, new vaults can be liquidated and old liquidations can proceed.

  • Level 1 - New Liquidations Disabled - No new liquidations can take place.

  • Level 2 - New Liquidations and Resets Disabled - No new liquidations can take place. No existing auctions can be reset if they expire.

  • Level 3 - All Liquidations Disabled - No new liquidations, no resets, no bidding in active auctions.

This functionality is exceptional because liquidations at non-market prices have the potential to be irreversibly damaging to both users and the Maker Protocol. The circuit breaker allows Maker Governance to attempt to limit the damage in the event of an issue affecting liquidations without waiting for the GSM Pause Delay.

Additionally, the contract allows for permissionless activation of the circuit breaker, if the price decrease in a collateral exceeds a preset percentage value between oracle price updates. The permissionless activation triggers the circuit breaker at Level 2 because both new auctions and resets reference the current oracle price.

When Level (0, 1, 2, 3) of liquidations circuit breaker is altered via executive vote, governance has the ability to set locked time, which is a specified duration which needs to pass until the liquidations circuit breaker can be triggered again via permissionless activation.

The risk opened up by this exceptional functionality is that liquidations may be halted by an attacker in order to either:

  • Prevent an expensive liquidation.

  • Take advantage of a significant drop in collateral prices to mint unbacked Dai.

10.2.4.1: Breaker Price Tolerance

Breaker Price Tolerance is a parameter which determines the condition for the permissionless activation of circuit breaker. Adjusting the Breaker Price Tolerance requires an executive vote, which is subject to GSM Pause Delay.

The Breaker Price Tolerance is expressed as a number between zero and one, and works with the following equation: next_oracle_price < current_oracle_price * breaker_price_tolerance.

In instance where the price oracle model does not support the price delay function, the permissionless activation of the liquidation circuit breaker ceases to function, since there is no next oracle price.

10.2.4.1A

¤¤¤

The Breaker Price Tolerance is: 0.5

¤¤¤

10.2.5: Direct Deposit Breaker

The DIRECT_MOM contract manages the breaker for Direct Deposit Modules (D3Ms). The breaker functionality allows a successful governance proposal to disable any or all of the active D3Ms. In practice, this will set the bar parameter to zero, which (contrary to intuition) disables the module by setting the allowed Debt Ceiling to zero. At this point, no further DAI can be minted through the Direct Deposit Module. To reverse the effect, parameters of affected Direct Deposit Modules must be reconfigured with an executive vote which is subject to GSM Pause Delay.

The risk opened up by this exceptional functionality is that a given line of DAI credit is unexpectedly shut down, this has the potential to disrupt the protocol in question which may impact Maker indirectly.

10.2.6: Starknet Circuit Breaker

The STARKNET_ESCROW_MOM contract manages the breaker for the StarkNet-DAI bridge. The breaker functionality allows a successful governance proposal to freeze withdrawals from the L1 Starknet bridge contract without waiting for the GSM Pause Delay to expire.

The risk opened up by this exceptional functionality is that DAI withdrawals from Starknet to mainnet are unexpectedly blocked with circumstance or timing that benefits an attacker, and inconveniences others.

10.2.7: Dynamic Debt Ceiling

The MCD_IAM_AUTO_LINE contract manages the debt ceiling parameters for many of MakerDAO's vault types according to preset rules. Keepers can use the contract to attempt to maintain a Target Available Debt in a given vault type. The contract modifies the debt ceiling up or down to maintain a level of available debt.

This functionality is exceptional so that the Maker protocol can react to changes in debt demand more quickly than waiting for the GSM delay.

The risk opened up by this exceptional functionality is a theoretical griefing attack on the IAM that prevents debt from being accessible in affected vault types.

10.2.8: SparkLend Specific

GSM Exceptions for SparkLend must be researched and implemented, which are required for mitigating extreme instances in the case of identified exploits which could result in loss of assets for users, Spark or MakerDAO.

GSM Exceptions should include but are not limited to Market Pause and Market Freeze supported by the research and argumentation.

11: SubDAO Governance Security

The Governance Facilitators must ensure that adequate funding and research goes towards developing a long term solid and scalable SubDAO Governance Security Framework, that must be specified in this Article and be in accordance with ATL2.11.

12: Scope Bootstrapping

12.1: Bootstrapping Governance Votes

Governance Facilitators are empowered to use broad judgment when exercising their ability to make direct Atlas interpretations and edits to the Atlas and the Scope Artifacts, when this relates to unintended consequences or mistakes in the affected documents.

12.1.1

In case of unintended consequences or mistakes in the Atlas and Scope Artifacts causing Maker Governance to function incorrectly, the Governance Facilitators can at any time run a Governance Poll to enable MKR holders to make a decision that will alleviate and resolve unintended consequences or mistakes.

12.1.2

The Governance Facilitators can at any time propose to edit any content of a Scope Artifact through a Governance Poll.

12.2: Aligned Delegate Privacy Transition

As a one-time event, in the moment this version of the Scope Artifact is accepted by Maker Governance, all existing PDs and RDs receive one months payout at their prior rate of compensation, based on their ranking at the moment the Scope Artifact is accepted.

12.3: Aligned Delegate bootstrapping Seasons

The first Aligned Delegate season lasts from the moment this Scope Artifact is accepted, until the first deployment of the Sagittarius Engine. After the first deployment of the Sagittarius Engine, the next Aligned Delegate season then lasts until Q2 of the following year.

12.4: Alignment Conserver (AC) Bootstrapping Focus

During bootstrapping, until the Scope Improvement Articles of each Scope Artifact are well developed, AVCs must focus on making Aligned Scope Proposals that improve the Scope Improvement Articles. ADs must not follow instructions by AVCs, through Aligned Governance Strategies or Aligned Scope Proposals, that cover subjects other than improvements to the Scope Improvement Articles and/or Scope Advisory Councils. Instead, for matters not related to Scope Improvement Articles and/or Scope Advisory Councils, ADs must vote according to their own understanding of Universal Alignment and the spirit of the Atlas in a way that best pushes forward the Maker Ecosystem towards the Endgame State and strengthens the Alignment Artifacts. ADs must make use of the ability of MIP102 edits to distinguish between Article 1 edits and General edits of Scope Artifacts, to make sure they follow their AVCs GSL instructions for Article 1 edits, and treat General edits separately.

Additionally, all ACs must devote significant work and resources towards the development of an AI-enabled Next Generation Atlas that is machine readable and has improved consistency and data quality. PDs, RDs and Facilitators must all generate and publish output that brings the community closer to being able to properly adopt a Next Generation Atlas solution. PDs have the highest such responsibility, followed by Facilitators, and then RDs. If an AC in a particular category is not outputting work that is up to the same standard, and at the same frequency and volume, as the majority of the ACs in their category, they can be considered misaligned and derecognized by the Governance Facilitators after a warning. AVCs must devote the majority of their time and energy towards discussing and understanding how the Next Generation Atlas will work and how to incorporate AI efficiently into long term governance and AVC operations, as well as assisting in the creation of the Next Generation Atlas. This priority supersedes their other responsibilities, and if an AVC Member has been deeply involved in Atlas creation and improvement, they can be made completely exempt from other AVC duties, when qualifying for AVC Member compensation. This exemption is determined retroactively by a Governance Facilitator when calculating AC compensation, and guidance for obtaining the exemption can be provided in advance given specific, Atlas-related KPIs, published by a Governance Facilitator.

Last updated