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:
Deep understanding of MakerDAO, both at the protocol and governance level.
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.
Hands-on experience in running a DAO or another plurality protocol. Examples include DeSoc movement, Twitter Community Notes, and Wikipedia.
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.
Deep understanding of voting systems and their effects on candidate selection.
Experience in people and resource management.
Leadership skills and ability to handle pressure.
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.
Deep understanding of consensus systems and game theory.
Longstanding experience in moderation of high velocity and/or high impact forums or chats.
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
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.
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
Any Maker Governance participant can request an Atlas Interpretation from the Governance Facilitators by submiting a post on the Maker Forum. In order for the Governance Facilitators to be bound to comply with the interpretation request, it must be endorsed or supported by at least one AVC Member or Aligned Delegate. In all cases the Facilitator can voluntarily proceed with the interpretation.
2.2.2
When a binding request for an Atlas Interpretation is submitted to the Maker Forum, Governance Facilitators have up to 30 days for review and provide the intepretation.The Governance Facilitators may extend this deadline, if necessary, by 15 days, provided that they have published the justification in the Maker Forum.
2.2.3
Following the conclusion of the review period, the Governance Facilitators are required to publicly post their response to the Atlas Interpretation request on the Maker Forum. This response must include a detailed rationale for the decision reached, reflecting a comprehensive review of the request. The post must also transparently indicate the voting results among the Facilitators, listing which Facilitators were in favor of or against the decision. This process is designed to ensure accountability and transparency in the decision-making process.
2.2.3.1
In instances where Aligned Delegates or AVC Members proffer specific interpretation proposals subsequent to an original request for interpretation, the Governance Facilitators are obligated to consider these proposals earnestly. The final resolution posted by the Governance Facilitators must include explicit reasoning detailing why each of these additional interpretation proposals was either accepted or dismissed. This justification is crucial to maintain a transparent and inclusive decision-making process, providing insights into the rationale and ensuring that all proposals are given due consideration.
2.2.4
If the Governance Facilitators cannot reach a majority decision regarding an Atlas Interpretation, a vote shall be triggered involving Maker Governance in the final decision.
2.2.5
A majority of Governance Facilitators can trigger a vote to add a new subelement if it is necessary to resolve Atlas ambiguity. Atlas interpretation precedent approved through MKR vote is contained as Strengthening subelements of this clause.
2.2.6
Atlas Interpretation precedent made directly by the Governance Facilitators is contained in 2.2.6.1A.
2.2.6.1A
¤¤¤
List of Atlas Interpretations:
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.
¤¤¤
2.2.7
Backtracking mechanism:any Maker Governance participant may request a re-evaluation of an adopted Atlas Interpretation on the Maker Forum, outlining the identified adverse effects and proposed amendments.
2.2.8
The Governance Facilitators will review the request, engage the community, and post the final decision on maintaining, amending, or revoking the interpretation, along with the rationale and any required action plan, in a maximum of 30-days period of the request.
3: Scope Bounded Mutable Alignment Artifact (Scope Artifact)
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 disabled until the launch of the Easy Governance Frontend when Voter Incentives are turned on.
6: Aligned Delegates (ADs)
The Governance Facilitators must ensure that all the rules of ADs are followed.
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. Following the temporary removal of AVCs, Governance Facilitators must remove the Delegation Contract 2 when feasible, and use Delegation Contract 1 as the main Delegate Contract
6.1.2A
¤¤¤
List of current ADs:
| Delegate Name | EA Address | Delegation Contract 1 | Forum Post | |---|---|---|---|---|---| | vigilant | Address Signature | Contract Resiliency AVC Signature | Contract KISS AVC Signature | - | Link | | QGov | Address Signature | Contract Resiliency AVC Signature | Contract Regenerative Finance AVC Signature | Formerly Growth AVC | Link | | Bonapublica | Address Signature | Contract Regenerative Finance AVC Signature | Contract KISS AVC Signature | - | Link | | PBG | Address Signature | Contract Resiliency AVC Signature | Contract Regenerative Finance AVC Signature | Formerly Growth AVC | Link | | Pf | Address Signature | | No current active Contract 2 - banned by KISS AVC Link | Formerly Growth AVC | | | UPMaker | Address Signature | Contract Regenerative Finance AVC Signature | Contract Resiliency AVC Signature | - | Link | | WBC | Address Signature | Contract ReFi AVC Signature | Contract Resiliency AVC Signature | Formerly Growth AVC | Link | | BLUE | Address Signature | Contract KISS AVC Signature | Contract Sovereign Finance AVC Signature | - | Link | | JAG | Address Signature | Contract Sovereign Finance AVC Signature | Contract Resiliency AVC Signature | - | Link | | Skynet | Address Signature | Contract Resiliency AVC Signature | Contract ReFi AVC Signature | - | Link | | Cloaky | Address Signature | Contract Regenerative Finance AVC Signature | Contract Sovereign Finance AVC Signature | - | Link | | Penguin Soldier | Address Signature | Contract Resiliency AVC Signature | Contract KISS AVC Signature | - | Link | | Vision | Address Signature | Contract Resiliency AVC Signature | No current active Contract 2 - banned by KISS AVC Link | - | Link | | Nimsen | Address Signature | No current active Contract 1 - banned by KISS AVC Link) | Contract Resiliency AVC Signature | - | Link | | Ikagai | Address Signature | Contract Resiliency AVC Signature | Contract Regenerative Finance AVC Signature | - | Link | | Byteron | Address Signature | Contract ReFi AVC Signature | Contract Resiliency AVC Signature | - | Link | | Shanah | Address Signature | Contract Resiliency AVC Signature | Contract Regenerative Finance AVC Signature | - | Link | | Pipkin | Address Signature | Contract Resiliency AVC Signature | Contract Sovereign Finance AVC Signature | - | Link | | JuliaChang | Address Signature | Contract Regenerative Finance AVC Signature | Contract Sovereign Finance AVC Signature | - | Link | | StoneWill | Address Signature | Contract Regenerative Finance AVC Signature | Contract KISS Finance AVC Signature | - | Link |
¤¤¤
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 applicant must deploy at least 1 Protocol Delegation System smart contract.
6.2.1.3
The submission message must be cryptographically signed by the deploying Ethereum address.
6.2.1.3.1
Aligned Delegates should cryptographically demonstrate that they control the Ethereum address that controls their deployed Protocol Delegation System smart contract(s).
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 Governance Facilitators must rework this document to be in line with the removal of AVCs. A single edit of this kind can be done at will by consensus of the Governance Facilitators, executed through directly modifying the content of this Document (6.2.1.5)
The submission message must follow this template:
¤¤¤
6.3: Prime Delegate and Reserve Delegate Slots
The number of PD and RD slots is modifiable over time, and must be adjusted to align with the talent available. 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. 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):
3
¤¤¤
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: Facilitator Management
During the pregame, the Governance Scope manages and provides the budget for 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 MIP102 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 MIP102 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 Delegates (ADs), FacilitatorDAOs and Advisory Council
The Governance Facilitators must ensure to follow and enforce the principles described in the Atlas 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. The whitelist is defined in 10.2.3.1A and can be changed via the Weekly Governance Cycle.
10.2.3.1A: Debt Ceiling Breaker Vault Types Whitelist
¤¤¤
PSM (USDC) - PSM-USDC-A
PSM (PAX) - PSM-PAX-A
PSM (GUSD) - PSM-GUSD-A
ETH-A
ETH-B
ETH-C
WSTETH-A
WSTETH-B
WBTC-A
WBTC-B
WBTC-C
¤¤¤
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 Freezer Mom
The SparkLend Freezer Mom contract allows Maker Governance to bypass the GSM delay to either freeze or pause any markets in SparkLend. The contract also allows the undoing of such actions for any market in SparkLend.
This functionality allows Maker Governance to react faster in an emergency. Freezing markets does not allow for new supplies or borrows, while pause restricts all market functionality, including deposits/withdrawals/borrows/repays and liquidations.
10.2.9: Smart Burn Engine Breaker
The FlapperMom contract allows for the disabling of the Smart Burn Engine without the GSM delay.
This functionality is available so that Maker governance can react to emergencies regarding the Smart Burn Engine.
10.3: SparkDAO
Spark is one of the initial AllocatorDAOs which is focusing on developing crypto on-chain lending engines and will be governed by SparkDAO token holders to the extent and limitations allowed by the rules defined in the Atlas.
SparkLend protocol is the first such engine, structured as a Conduit in the upcoming Allocation System. SparkLend will be adopted by SparkDAO once AllocatorDAOs are launched.
The subelements below outline the governance security framework procedures specifically developed for the SparkLend Protocol.
10.3.1: Multisig Freeze of SparkLend
In addition to the SparkLend Freezer Mom contract defined in 10.2.8, an External Security Access Multisig that allows for pausing and/or freezing SparkLend markets must be researched and implemented. The Multisig Freeze feature of SparkLend should exist alongside the SparkLend Freezer Mom contract, ensuring that the Maker community can take timely action in case of an emergency which requires immediate intervention.
The implementation must be justified by research and argumentation. The solution must be implemented in a way where Maker Governance preserves the ability to disable the solution without argumentation and GSM delay, and preserves total control over the protocol.
The solution can only be used in cases of extreme emergencies such as potential code exploits which have existential threat potential. The solution must be ratified by Maker Governance with an on-chain poll before being deployed.
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.4: Alignment Conserver (AC) Bootstrapping Focus
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.
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.
12.5: Multiple Conflicting Atlas Edit Proposals
When multiple conflicting Atlas edit proposals are approved within a short period of each other, the Governance Facilitators can decide to merge parts of the proposals together to ensure that the aggregate changes incorporate the best updates form each of the conflicting proposals.
12.6 Governance Security & Ecosystem Actor Embedding
As a temporary bootstrapping measure, incubating Ecosystem Actor Atlas Axis will be embedded in Governance Facilitator-permissioned communication channels where spells-coordination work is performed. Atlas Axis will have no decision-making authority in the spells workstreams. The objective is solely to facilitate Atlas Axis’ preparation of comprehensive, robust and resilient Atlas data for Governance Security by enabling it to directly observe patterns and issues as they arise. This bootstrapping provision ends with the launch of NewChain.
Last updated