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.

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 that notices a problem in the Scope or something that can and should be improved can apply to undergo a process to suggest improvements. 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

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.

1.1.3.3

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.4

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

¤¤¤

Advisory Council project budget:

Maximum Monthly Amount (DAI)	Maximum Monthly Amount (MKR)	Implementation	Start Date	Notes
50,000	N/A	Manual	2023-08-01

¤¤¤

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.

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:

Date	Conserver Role	Identity	Known Aliases	Reasoning Post
2023-06-08	AD	Bulwark	-	Link

¤¤¤

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:

Date	Conserver Role	Identity	Known Aliases	Reasoning Post
2023-06-08	AVC Member	HKUST_EPI_BLOCKCHAIN	-	Link

¤¤¤

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:

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)
TRUEMAKER	0x4eFb12d515801eCfa3Be456B5F348D3CD68f9E8a	Link	Link	5.016
anathem.eth	0xa2fC3b7A5dA35D0418Ec46A9CcFc7f4a53084841	Link	Link	0.313

¤¤¤

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

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
IamMeeoh	0x47f7A5d8D27f259582097E1eE59a07a816982AE9	Link	Link	15.910	AVC Creator
DAI-Vinci	0x9ee47F0f82F1A6F45C4E1D25Ce95C321D8C8356a	Link	Link	0.900 (wallet holds 1 MKR, only verifying 0.9)	Link
twblack88 (Feedblack Loops LLC)	0x80882f2A36d49fC46C3c654F7f9cB9a2Bf0423e1	Link	Link	1	Link
opensky	0x8e67ee3bbeb1743dc63093af493f67c3c23c6f04	Link	Link	1	Link

---

Regenerative Finance AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
ACRE DAOs	0xBF9226345F601150F64Ea4fEaAE7E40530763cbd	Link	Link	2.180	AVC Creator
fhomoney.eth	0xdbD5651F71ce83d1f0eD275aC456241890a53C74	Link	Link	6.000	Link

---

Resiliency AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
Res	0x8c5c8d76372954922400e4654AF7694e158AB784	Link	Link	4.173	AVC Creator
Harmony	0xE20A2e231215e9b7Aa308463F1A7490b2ECE55D3	Link	Link	2.00	Link

---

Sovereign Finance AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
seedlatam.eth	0x0087a081a9b430fd8f688c6ac5dd24421bfb060d	Link	Link	6.800	AVC Creator

---

List of pending AVCs and their members:

RISK AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
HKUST_EPI_BLOCKCHAIN	0xE4594A66d9507fFc0d4335CC240BD61C1173E666	Link	Link	1.007	AVC Creator

---

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

Composable AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
LDF	0xC322E8Ec33e9b0a34c7cD185C616087D9842ad50	Link	Link	1.020	AVC Creator
stefdelev	0xaAA1D204D78De81a6EfF5264928A6B49eE748050	Link	Link	1.000	Link

Growth AVC

AVC Member Name	AVC Member Address	Forum Verification	Verified Signature	Verified MKR Holding (MKR) (3dp)	Approved to Join AVC
StableLab	0xbDE65cf2352ed1Dde959f290E973d0fC5cEDFD08	Link	Link	11.999	AVC Creator
flipsidegov	0x300901243d6CB2E74c10f8aB4cc89a39cC222a29	Link	Link	0.100	Approved

---

¤¤¤

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:

Delegate Name	EA Address	Delegation Contract 1	Delegation Contract 2	Neutral Contracts (if present)	Forum Post
vigilant	Address Signature	Contract Resiliency AVC Signature	Contract KISS AVC Signature	-	Link
QGov	Address Signature	Contract Resiliency AVC Signature	Contract KISS AVC Signature	Formerly Growth AVC	Link
TRUE NAME	Address Signature	Contract Resiliency AVC Signature	Contract Regenerative Finance AVC Signature	-	Link
0xDefensor	Address Signature	Contract Resiliency AVC Signature	Contract Regenerative Finance AVC Signature	-	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
Libertas	Address Signature	Contract Resiliency AVC Signature	Contract ReFi 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
PALC	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
Navigator	Address Signature	Contract ReFi 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 Sovereign Finance AVC Signature	Contract KISS AVC Signature	-	Link
Vision	Address Signature	Contract Resiliency AVC Signature	Contract KISS AVC Signature	-	Link
Nimsen	Address Signature	Contract Kiss AVC Signature	Contract Resiliency AVC Signature	-	Link
Ikagai	Address Signature	Contract Resiliency AVC Signature	Contract Regenerative 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 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):

• 5

¤¤¤

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:

Facilitator	ETH Address	DAI per Month	MKR per Month	One Time Lump Sum (if applicable, only applies to March/April 2023)
JanSky	0xf3F868534FAD48EF5a228Fe78669cf242745a755	42,000	18	N/A
Endgame Edge	0x9E72629dF4fcaA2c2F5813FbbDc55064345431b1	42,000	18	N/A
Ecosystem	0xFCa6e196c2ad557E64D9397e283C2AFe57344b75	42,000	18	N/A

¤¤¤

---

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:

Scope Framework	Responsible Facilitator	ETH Address (if relevant)
Governance	JanSky	0xf3F868534FAD48EF5a228Fe78669cf242745a755
Governance	Endgame Edge	0x9E72629dF4fcaA2c2F5813FbbDc55064345431b1
Support	Ecosystem	0xFCa6e196c2ad557E64D9397e283C2AFe57344b75
Protocol	Ecosystem	0xFCa6e196c2ad557E64D9397e283C2AFe57344b75
Stability	Ecosystem	0xFCa6e196c2ad557E64D9397e283C2AFe57344b75
Accessibility	Ecosystem	0xFCa6e196c2ad557E64D9397e283C2AFe57344b75

¤¤¤

---

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.

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 on a weekly basis 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 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.

---

rune | 2023-11-13 13:28:20 UTC | #3

Stability Scope Bounded Mutable Alignment Artifact

Preamble

MIP#: 104
Title: Stability Scope Bounded Mutable Alignment Artifact
Author(s): @rune
Contributors:
Tags: endgame, scope-framework
Type: General
Status: Accepted
Date Proposed: 2023-02-06
Date Ratified: 2023-03-27
Dependencies:
Replaces:
Ratification Poll URL: https://vote.makerdao.com/polling/Qmbndmkr
Forum URL: https://forum.makerdao.com/t/mip104-the-decentralized-collateral-scope-framework/19685

0: The Stability Scope

The Stability Scope covers the management of the Dai Stablecoin. The Dai Stablecoin must be a permissionless and useful currency available to anyone. Its stability and risk must be managed to generate as much value for MakerDAO and public good as possible.

1: Scope Improvement

1.1: The Stability Advisory Council

The Stability 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 Stability Scope Artifact.

1.1.1: Stability 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 Stability 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 Stability Scope is covering.

1.1.1.3

The Stability 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 Stability 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 Stability 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 Stability 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 Stability 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 Stability 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 Stability Facilitators can choose to remove them at will, if they deem it necessary.

1.1.1.5: Stability Advisory Council Requirements

1.1.1.5.1

Stability Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Stability Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame.

1.1.1.5.2

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

1. Expertise in capital markets, bonds, equities.

2. Experience as a market analyst or economist.

3. Expertise in tokenomics.

4. Expertise in fund management and risk profiles.

5. Deep knowlege of decentralized collateral accounting and finance.

6. Experience in credit risk, market risk, liquidity risk, and operational risk.

7. Deep understanding of principles of portfolio construction, asset allocation, diversification strategies, and performance measurement.

8. Experience in smart contract and DeFi risk management.

9. Experience in economic modeling of high-volatility portfolios.

10. Expertise in Value at Risk analysis with detailed knowledge about the limitations of the method.

1.1.1.6

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

1.1.1.6.1A

¤¤¤

Current list of Advisory Council Members:

Advisory Council Member	ETH Address
BA Labs	0xDfe08A40054685E205Ed527014899d1EDe49B892

¤¤¤

1.1.2: Stability Advisory Council Recognition

1.1.2.1

In order to be eligible for the Stability 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 Stability 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] Stability 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] Stability 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: Stability 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. The Stability 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 Stability Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Stability Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Stability 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

Each Quarter, if they deem it necessary, the Stability 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 Stability Facilitators.

1.1.3.3

In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Stability 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 Stability Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.

1.1.3.4

The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Stability 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 Stability 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 Stability 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

¤¤¤

Advisory Council project budget:

Maximum Monthly Amount (DAI)	Maximum Monthly Amount (MKR)	Implementation	Start Date	Notes
207,000	N/A	DssVest	2023-03-01 (Backdated)	N/A
73,000	15	DssVest	2023-04-01	For Data Related Expenses
83,000	N/A	Manual	2023-05-01	For ALM and RWA related expenses

¤¤¤

1.2: Stability Scope DAO Toolkit Integration

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

2: Dai Stablecoin Reference Asset

This Article must be strengthened to ensure balanced and appropriate funding of proactive research into future reference assets.

3: Core Stability Parameters

Before the launch of AllocatorDAO Vaults, the Core Stability parameters are fixed to help bootstrap the system.

3.1: The Base Rate

The Base Rate is regularly updated by the Stability Facilitator to approximate ((Yield Collateral Yield Benchmark - 0.5%) * 0.78 + Stability Collateral Yield Benchmark * 0.22). The up to date Base Rate is contained in 3.1.1A. Whenever an update to the Base Rate occurs, the Stability Facilitator must trigger an executive vote to update the on-chain Stability Fees of the AllocatorDAO Vaults.

3.1.1A

¤¤¤

The Base Rate is:

• 4.45%

¤¤¤

3.2: The Dai Savings Rate

The Dai Savings Rate is regularly updated to be equal to (Base rate - 0.25%). The up to date Dai Savings Rate is contained in 3.2.1A. Whenever an update to the Dai Savings Rate occurs, the Stability Facilitators must trigger an executive vote to update the on-chain Dai Savings Rate.

3.2.1A

¤¤¤

The Dai Savings Rate is:

• 4.20%

¤¤¤

3.2.2: Enhanced Dai Savings Rate

The Enhanced Dai Savings Rate is a system to temporarily increase the effective DSR available to users in the early bootstrapping stage when DSR utilization is low. The EDSR is determined based on the DSR and the DSR utilization rate, under the control of the Stability Facilitators, and decreases over time as the utilization increases, until it eventually disappears when utilization gets high enough, when triggered by the Stability Facilitators. EDSR is a one-time, one-way temporary mechanism, which means that the EDSR can only decrease over time, it cannot increase again even if DSR utilization goes down.

The Stability Facilitators can take actions related to the EDSR through forum posts signed by their approved Ethereum address.

Other parameters and mechanisms that are dependent on the DSR, such as crypto-collateralized stability fees, are affected by the EDSR. This applies to all crypto-collateralized Vault Types except for Spark Protocol.

Spark Protocol has a borrow rate spread that is 0.5% above the EDSR, as long as the EDSR is active. As long as Spark Protocol remains near its maximum borrow limit, the Stability Facilitators can use the weekly governance cycle to propose to increase its Debt Ceiling to attract more users. If Spark Protocol falls below 200 million active borrowing for an extended period of time, the Stability Facilitators can use the weekly governance cycle to propose a decrease to the borrow rate spread to attempt to incentivize usage to increase above 200 million.

When NewGovToken and SubDAO farming comes into effect, DSR utilization will count both DSR use and NewGovToken and SubDAO farming use.

3.2.2.1: EDSR Upper Limit

The EDSR cannot exceed 5%. If the EDSR formula outputs a number above 5%, the actual effective EDSR implemented in the protocol will be 5% instead.

3.2.2.2: EDSR Utilization-Based Multipliers

Each of the following EDSR multiplier tiers can be triggered by the Stability Facilitators based on the utilization rate. When first adopted, the EDSR begins at tier 1. If at any point in time the DSR utilization stays above the level needed for a different tier for a continuous period of more than 24 hours, the Stability Facilitator can choose to trigger the new tier, and a manual DSR adjustment must then be included in the next executive vote to account for the new tier.

3.2.2.2.1: EDSR tier 1

• Multiplier: 1.75x DSR

• Utilization: 0-35%

3.2.2.2.2: EDSR tier 2

• Multiplier: 1.15x DSR

• Utilization: 35-50%

3.2.2.3

EDSR can be ended permanently by the Stability Facilitators once DSR utilization crosses above 50% for a continuous period of more than 24 hours.

3.2.2.4

The Stability Facilitators can at any time use the weekly governance cycle to disable the EDSR permanently, or modify any of its parameters or logic in 3.2.2 or its subelements, if there are indications that it is not cost-effectively achieving its objectives.

3.3: Dai Savings Rate and Base Rate Changes in Demand Shocks

The Stability Facilitators can use the urgent governance cycle to propose non-standard changes to the Dai Savings Rate and the Base Rate in case of risks to the peg stability of Dai. Once the risks have subsided, the Dai Savings Rate and Base Rate must be reverted to their ordinary values, according to 3.1.1A and 3.2.1A.

3.4: Core Stability Parameters Update Frequency

This element and subelements define the minimum frequency of when they must be updated and implemented in the protocol. All parameters which are derived from the Core Stability Parameters must be updated at the same time, such as Native Vault Engine. Any other element which is more specific to a set of parameters or describes unique instances such as emergencies overrides this element. The Core Stability Parameters update is subject to three different conditions defined in the subelements

3.4.1: Duration Based Condition

Core Stability Parameters must be updated at a minimum of 2 months since the last spell execution which included previous update in the next available executive spell

3.4.2: Base Rate Change Condition

Core Stability Parameters must be updated when the Base Rate Change is greater than +/-5% in the next available executive spell

3.4.3: Stability Scope Language Amendment

Core Stability Parameters must be updated when the language of the Core Stability Parameters or elements containing definitions and formulas for parameter setting which depend on the Core Stability Parameters are amended in the next available executive spell

4: AllocatorDAO Vaults

Before the launch of SubDAOs, AllocatorDAO Vaults function in a bootstrapping mode. They are controlled by AllocatorDAO Advisors, which are special Ecosystem Actors with the ability to advise the Stability Facilitators

4.1: AllocatorDAO Vaults Stability Fee

The AllocatorDAO Vaults have a Stability Fee equal to the Base Rate specified in 3.1.1A.

4.2: AllocatorDAO Advisors

The Stability Facilitator can use the weekly governance cycle to propose to onboard AllocatorDAO Advisors and set up a new AllocatorDAO Vault, based on AllocatorDAO Advisor Proposals made on the Maker Forum. The AllocatorDAO Advisor will be tasked with publishing advice related to the use of their AllocatorDAO vault. The current active AllocatorDAO Advisers and their individual Debt Ceiling Limits are specified in 4.2.2A, and must be updated by the Stability Facilitators when applicable.

4.2.1

The AllocatorDAO Vaults share a total debt ceiling limit equivalent to the Dai Supply, minus all legacy collateral. Each AllocatorDAO Vault has an individual debt ceiling limit of its proportional amount of the total debt ceiling limit.

4.2.2A

¤¤¤

Current active AllocatorDAO Advisors:

N/A

¤¤¤

5: Legal Recourse Assets

Legal Resource Assets are assets used as collateral for the Dai Stablecoin that are enforced through legal recourse by Arranged Structures. They have unique risks that must be safeguarded against.

5.1: Arrangers

Arrangers are Ecosystem Actors that specialize in sourcing, negotiating, structuring of, and reporting on, Legal Recourse Assets and maintaining and monitoring the underlying Arranged Structures used by the Maker Protocol. They must never be able to operate or influence the arranged legal and operational structure’s asset operations in a way that can cause any significant harm or losses to Dai’s stability, after the structures have been built and assets allocated hereto. Arrangers are approved directly by MKR voters, and all LRA collateral exposure must be structured by an approved Arranger.

5.1.1: Active Arranger Management

Arrangers are onboarded or offboarded based on a governance poll by MKR voters, that is initiated by the Stability Facilitators if they deem it necessary. The active state of current approved Arrangers is maintained in 5.1.1.1A.

5.1.1.1A

¤¤¤

List of current active Arrangers:

• Monetalis

• Blocktower

¤¤¤

5.1.2: Arranger Standard Fees

Arrangers may charge a maximum reporting fee of 15 basis points per year on top of other fees charged by the structure and the Asset Manager. The fee is calculated based on the utilized Debt Ceiling of the Arranger Vault, and may not be charged up front without a standalone vote by governance for approval. For stable asset Arranger services, Arrangers may charge up to 10 basis points. Any asset reasonably expected to only maintain or grow value, such stablecoins, US government securities, or bank deposits is a stable asset. In the event a single Arranger structure contains both stable assets and non-stable assets, the maximum fee applies proportionately to each part of the portfolio.

An Arranger that is not compliant with 5.1.4 for 60 days or more will not receive further funding from MakerDAO governance or the entities it reports upon until it becomes compliant. In the event the Arranger reports upon multiple entities, the prohibition applies only to the specific entities and Maker vaults where the Arranger is noncompliant.

5.1.3: Arranger Concentration Risk Management

The Stability Facilitators must take action to search and propose onboarding of additional Arrangers when it is economically feasible to do so, in order to help reduce the concentration risk to individual Arrangers. Strict limits to the amount of assets that each Arranger services for must be developed and implemented in this section over time.

5.1.4: Arranger Reports and Stress Tests

Arrangers must publish monthly reporting on each Arranged Structure they have arranged, and must every six months also publish stress test analysis that shows how the structures would perform based on historical financial crisis scenarios and other example scenarios. The Stability Facilitators must periodically fund independent Ecosystem Actors to review and verify the quality and the results of the stress tests. Should an independent review produce an unfavorable result, the Responsible Facilitators must propose a governance poll for warning, temporarily deactivating, or permanently offboarding the Arranger and/or the Asset Managers connected to the discovered issue.

Monthly reports must satisfy 5.1.4.1 or 5.1.4.2 or 5.1.4.3 to be considered compliant.

5.1.4.1

The following information should be included in the monthly Arranger report. Each item should be provided for at least the beginning and ending date of the reporting period (the first business day after beginning date and last business day before the ending date may be used if the beginning and ending dates fall on days markets are closed):

• Cash balance.

• Cash income over the reporting period. Any income over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expensesi.

• Cash expenses over the reporting period. Any expense over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expenses.

• Market value of publicly traded equities, ETFs, and mutual funds.

• Market value (the closing price) of publicly traded debt securities. Debt securities that are investment grade and less than 12 months from maturity may alternatively be reported at cost basis + linearly recognizing scheduled interest income.

• A valuation for illiquid or privately traded assets. This should utilize a valuation from a reputable third party with relevant expertise or follow a well-defined methodology that is explained in detail in the report.

• CUSIPs, date of purchase, date of maturity, coupon, cost basis, and face value of all publicly traded debt securities in the portfolio for the last day of the reporting period.

• DAI inflows from the Maker protocol during the reporting period.

• Total repayments on-chain to the Maker protocol either to a vault or for surplus. If repayments are derived from multiple sources, they should be broken out into line items for each source.

• Vault debt to the Maker protocol.

The Scope Facilitator must publicly state on the MakerDAO forum that they have reviewed original documentation for accounts that supports the Arranger’s summarization.

5.1.4.2

The following information should be included in the monthly Arranger report:

Copies of original statements for all bank, brokerage, exchange, custodial, or other accounts. The Arranger may redact the names for non-Arranger service providers if and only if that is a requirement of confidentiality agreements with the non-Arranger service providers. DAI inflows from the Maker protocol during the reporting period. Total repayments on-chain to the Maker protocol either to a vault or for surplus. If repayments are derived from multiple sources, they should be broken out into line items for each source. Vault debt to the Maker protocol.

5.1.4.3

The following information must be provided through public read-only access to all accounts:

• All asset balances

• All transaction amounts (non-Arranger service provider names may be redacted)

• Hold-to-maturity yields (for assets with maturity) or current yield (for assets with no maturity)

In addition, Makerburn.com, Daistats.com, or another dashboard must be publicly available to summarize DAI inflows and outflows from the Maker vault.

5.2: Legal Recourse Asset Budget

The Stability Facilitators have a budget available to pay costs related to stress test review, legal research and first time setup of legal structures for arrangers, and other expenses relevant to Legal Recourse Assets. Arrangers that are supported this way must publish all research and conclusions related to the Arranged Structure, to help other arrangers replicate the work and strengthen the Maker Arranger ecosystem. The Legal Recourse Asset Budget is specified in 5.2.1B.

5.2.1B

¤¤¤

The Legal Recourse Asset budget is:

• Up to 1,000,000 DAI available per year.

The full amount is immediately available at the start of the calendar year, and parts of it can be paid out through executive vote bundling when requested by the Stability Facilitators.

¤¤¤

6: AllocatorDAO Effective Junior Capital

The Stability Facilitators and Stability Advisory Council Members must research and develop a framework for determining adequate multipliers for the different sources of AllocatorDAO Effective Junior Capital.

7: AllocatorDAO Collateral and Market Requirements

AllocatorDAO Advisory teams are subject to requirements for how they deploy Dai generated from their AllocatorDAO Vault.

7.1: AllocatorDAO Capitalization Requirements

AllocatorDAOs will have Capitalization Requirements of their Effective Junior Capital based on what kind of exposure they have from their AllocatorDAO Vaults. Before the launch of SubDAOs, AllocatorDAO Advisory Teams can use this framework to deploy collateral that has no Effective Junior Capital Requirement.

7.1.1: ALM Capitalization Requirements

Temporarily, before the launch of SubDAOs, ALM requirements are calculated in a unique way that ignores crypto-collateralized Dai from the overall calculation. Accordingly, the total size of the Dai Collateral Portfolio that is being considered for ALM calculations, called the Dai Non-Crypto collateral Portfolio, is equivalent to total size of the entire Dai Collateral Portfolio, subtracted all ETH, STETH, WBTC, and Spark protocol exposure, plus any other similar crypto collateralized positions. Additionally, crypto-collateralized exposure doesn't count towards any of the ALM tiers.

7.1.1.1: ALM Tier 1 Collateral

7.1.1.1.1

No slippage is allowed for ALM Tier 1 Collateral.

7.1.1.1.2

ALM Tier 1 Collateral must be able to instantly convert to Cash Stablecoins within 30 minutes with no slippage.

7.1.1.1.3

ALM Tier 1 Collateral or higher can be used for 100% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.

7.1.1.1.4

There are no additional Effective Junior Capital Requirements.

7.1.1.2: ALM Tier 2 Collateral

7.1.1.2.1

ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 2 weeks with expected slippage and realized loss of at most 1%.

7.1.1.2.2

ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 6 months with no slippage.

7.1.1.2.3

ALM Tier 2 Collateral or higher can be used for 78% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.

7.1.1.2.3.1

Temporarily before the launch of SubDAOs, the following additional requirement apples: The Arranged Structures holding ALM Tier 2 Collateral must have standing instructions to immediately convert to Dai and repay the necessary amount of ALM Tier 2 Collateral to bring total exposure of the Dai Non-Crypto Collateral Portfolio to ALM Tier 2 Collateral or higher to 78%, whenever the total exposure of the Dai Non-Crypto Collateral Portfolio to collateral of ALM Tier 2 or higher exceeds 82%. The necessary amount that must be converted is split proportionally between all Arranged Structures holding ALM Tier 2 Collateral based on their relative holdings of ALM Tier 2 Collateral.

7.1.1.2.4

If the exposure limit is exceeded, the excess ALM Tier 2 Collateral has an additional 5% Effective Junior Capital Requirement.

7.1.1.3: ALM Tier 3 Collateral

7.1.1.3.1

No slippage is allowed for ALM Tier 3 Collateral.

7.1.1.3.2

ALM Tier 3 Collateral must be able to convert to Cash Stablecoins within at most 12 months with no slippage.

7.1.1.3.3

ALM Tier 3 Collateral or higher can be used for 45% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.

7.1.1.3.4

If the exposure limit is exceeded, the excess ALM Tier 3 Collateral has an additional 10% Effective Junior Capital Requirement.

7.1.1.4: ALM Tier 4 Collateral.

7.1.1.4.1

No slippage is allowed for ALM Tier 4 Collateral.

7.1.1.4.2

ALM Tier 4 Collateral must be able to convert to Cash Stablecoins within at most 3 years with no slippage.

7.1.1.4.3

ALM Tier 4 Collateral or higher can be used for 10% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.

7.1.1.4.4

If the exposure limit is exceeded, the excess ALM Tier 4 Collateral has an additional 20% Effective Junior Capital Requirement.

7.1.2: Risk Capitalization Requirements

7.1.2.1: Risk Tier 1

Risk tier 1 assets have no Effective Junior Capital Requirement. Approved Risk Tier 1 Collateral are specified in the subelements of this element.

7.1.2.1.1

US Government Treasury Bonds, Notes and Bills.

7.1.2.1.2

Money Market Instruments defined as investment-grade, highly liquid, short-term debt instruments that can be exchanged for cash within 5 business days. Allowed Money Market instrument types include: term certificates of deposit, interbank loans, money market funds/ETF, commercial paper, Treasury bills, and securities lending and repurchase agreements (“repos”).

7.1.2.1.3

Overcollateralized ETH and Staked ETH vaults with at least 125% collateral ratio and automated liquidations.

7.1.2.1.4

Overcollateralized major crypto asset vaults with at least 150% collateral ratio and automated liquidations.

7.1.2.1.5

Cash Stablecoins.

7.2: AllocatorDAO Market Requirements

AllocatorDAOs are required to take specific market actions or be penalized. AllocatorDAO Advisor teams must follow these instructions to the best of their ability.

7.2.1: Cash Stablecoin Liquidity Requirements

7.2.1.1: Cash Stablecoin Reserve Requirements

AllocatorDAOs must have a reserve of Cash Stablecoins of at least 18% of their total portfolio.

7.2.1.2: Cash Stablecoin Market Making Requirements

AllocatorDAOs must be actively market making Cash Stablecoins against Dai with at least 18% of their total portfolio. Before the launch of SubDAOs, this requirement must be substituted by temporary solutions determined by the Stability Facilitators and proposed through the Weekly Governance Cycle.

7.2.1.3: Cash Stablecoin Definition

A Cash Stablecoin is a stablecoin listed in 7.2.1.3.1A or a technically secure DeFi token that can be instantly converted to a listed stablecoin, or a custody solution that can be converted into a listed stablecoin within 30 minutes. The Stability Facilitators can modify 7.2.1.3.1A through the weekly cycle to react to changing market conditions, opportunities or risks.

7.2.1.3.1A

¤¤¤

List of Cash Stablecoins:

• USDC - Exposure to USDC in centralized custody solutions is capped at 1.5 billion USDC.

• USDP - Exposure to USDP is capped at 120 million USDP and exposure to USDP requires that a marketing reward of at least 2% is available.

¤¤¤

8: AllocatorDAO Penalties

The Stability Facilitators and Stability Advisory Council Members must research a framework for applying penalties to AllocatorDAOs in alignment with ATL5.8.

9: Surplus Buffer and Smart Burn Engine

9.1: Smart Burn Engine Parameters

The amount of Dai in the Surplus Buffer that causes the Smart Burn Engine to activate, and the rate at which it uses the Dai to improve MKR liquidity, are determined by two parameters defined by the following subelements. The Smart Burn Engine which defines specific parameter configuration requirements of DssFlapper and how it should be altered are also defined in the following subelements.

9.1.1

The Surplus Buffer Upper Limit determines the amount of Dai necessary for the Smart Burn Engine to activate.

9.1.1A

¤¤¤

The Surplus Buffer Upper Limit is:

50 million Dai

¤¤¤

9.1.2

The Rate Of MKR Accumulation determines how much Dai is used to accumulate MKR per unit of system time. Since the Smart Burn Engine pairs the accumulated MKR with Dai directly from the Surplus Buffer, the effective rate of spending from the Surplus Buffer is approximately twice the Rate Of Accumulation. If the Surplus Buffer starts consistently exceeding the Surplus Buffer Upper Limit and continues to increase, without ever reducing the total Surplus back down to the Surplus Buffer Upper Limit, the Stability Facilitators must use the weekly governance cycle to modify 9.1.2A to make sure it is high enough to ensure all surplus exceeding the Surplus Buffer Upper Limit is eventually used up by the Smart Burn Engine.

9.1.2A

The Rate Of MKR Accumulation is:

¤¤¤

60 million Dai per year

¤¤¤

9.1.3

DssFlapper is the current implementation of contract which processes Smart Burn Engine transactions once activated. The DssFlapper includes the following parameters; hop, want, bump, pip and receiver. Stability Facilitators can propose DssFlapper reconfiguration within limits defined in each parameter corresponding subelement directly to the executive vote, except for the receiver and pip, which always require a governance vote except in the state of emergency where changing them prevents loss of funds for the protocol.

9.1.3.1

Flapper.hop: Minimum seconds interval between kicks.

Determines maximum allowed frequency of transactions taking place.

Maximum hop must be set to equal the approximate Effective Rate of MKR Accumulation defined in 9.1 depending on the corresponding configuration of bump parameter.

9.1.3.1A

¤¤¤

The hop parameter is: 6,308

¤¤¤

9.1.3.2

Flapper.want: Relative multiplier of the oracle price needed for the swap.

For example, 0.98 * WAD allows for a 2% worse price than the MKR/USD reference oracle (pip) price used in the system. want must not exceed 2%.

9.1.3.2A

¤¤¤

The want parameter is: 0.98

¤¤¤

9.1.3.3

Vow.bump: Minimum amount of DAI above Surplus Buffer Upper Limit required for eligible market transaction. bump is the amount of DAI used to get MKR. bump must be set in a way where a combination of price impact and transaction costs is minimized, depending on the analysis of network conditions which is provided by the Stability Scope Advisory Council and assumed outlook of mentioned factors.

9.1.3.3A

¤¤¤

The bump parameter is: 20,000

¤¤¤

9.1.3.4

Flappers.pip: A reference price oracle, used for bounding the exchange rate of the swap.

9.1.3.4A

¤¤¤

The pip parameter is:

0xdbBe5e9B1dAa91430cF0772fCEbe53F6c6f137DF

¤¤¤

9.1.3.5

Receiver: address which will receive the Univ2 MKR/DAI LP token.

9.1.3.5A

¤¤¤

The receiver parameter is:

MCD_PAUSE_PROXY: 0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB

¤¤¤

9.1.3.6: Parameter Reconfiguration Methodology & Frequency

The Stability Facilitators must update Smart Burn Engine Dss Flapper related parameters based on the analysis of cost optimization produced by the Advisory Council via first available executive vote. Since the cost optimization factors market impact and gas consumption related components which can be highly volatile, there is no strict condition for frequency. The Advisory Council must monitor the Smart Burn Engine and notify the Stability Facilitators that changes are needed with the corresponding analysis and proposed updated parameter configuration within the defined limits and boundaries.

9.1.3.7

The Smart Burn Engine and corresponding liquidity must be migrated to the New-Stablecoin/New-Governance-Token when this is technically available

10: SubDAO Economic Resilience Models

The Stability Facilitators and Stability Advisory Councils must develop adequate SubDAO Economic Resilience Models.

11: MKR Backstop

The MKR Backstop is temporarily limitless.

12: Dai Stablecoin Decentralization

AllocatorDAOs must be subsidized to ensure they have an incentive to allocate collateral to decentralized assets.

12.1: AllocatorDAO Decentralized Collateral Rebate

A Decentralized Collateral Rebate must be implemented if the Maker Community deems it necessary to protect the resilience of Dai.

13: Sagittarius Engine Dai Generation Risk Parameters

The Stability Facilitators must research how to set the adjustable risk parameters of the Sagittarius Engine Vaults.

14: Scope Bootstrapping

During the bootstrapping phase, the Stability Scope is modified to override the Atlas requirements in some places.

14.1: Yield Benchmarks

14.1.1

The Stability Collateral Yield Benchmark is contained in 14.1.1.1A and is approximately based on the average yield earned on all Cash Stablecoins. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant.

14.1.1.1A

¤¤¤

The Stability Collateral Benchmark Yield is:

• 2.09%

¤¤¤

14.1.2

The Yield Collateral Yield Benchmark is contained in 14.1.2.1A and is approximately based on the 3-month US Government Treasury Bill. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant.

14.1.2.1A

¤¤¤

The Yield Collateral Benchmark Yield is:

• 5.61%

¤¤¤

14.2: Protector Advisors

Before the AllocatorDAO Vault system is ready, Protector Advisors help advise the Stability Facilitators on deploying vaults and modifying risk parameters for Legal Recourse Assets in alignment with the spirit of the articles of the Stability Scope Artifact. The Stability Facilitators can trigger a weekly governance poll to onboard or offboard Protector Advisors. The active Protector Advisors are specified in 14.2.1A.

14.2.1A

¤¤¤

List of active Protector Advisors:

• Spring

• Viridian

¤¤¤

14.3: Native Vault Engine

The Native Vault Engine is controlled by Maker Core temporarily, and will be upgraded to support SubDAO ownership and transferred to the first AllocatorDAO incubated from the Incubator when NewChain launches. While it is under the control of Maker Core it will have a limited set of collateral types and risk parameters that the Stability Facilitators must implement according to the following subelements.

If not otherwise specified, The Stability Facilitators have the ability to trigger an executive vote to update any of the parameters defined in article “14.3.1: Native Vault Engine Parameter Definitions” for any of the Vault Types contained in article “14.3.2: Maker Core Vault Types”.

14.3.1: Native Vault Engine Parameter Definitions

14.3.1.1: Liquidation Ratio (LR)

The Liquidation Ratio parameter limits the maximum amount of DAI debt that a vault user can draw from their vault given the value of their collateral locked in that vault. In practice, it expresses the minimum collateral in percentage terms that can support a given DAI debt. If the ratio of a Vault user's collateral to their debt drops below this value their vault can be liquidated. Each vault type has its own Liquidation Ratio. The Liquidation Ratio for each vault type is expressed as a percentage value of the collateral that must be present in the vault to support its debt.

14.3.1.2: Debt Ceiling Limit

The Debt Ceiling Limit is numerically provided and acts as an upper limit. The Stability Facilitators can propose changes within this limit. Debt Ceiling Limit = Unlimited is defined as substantially large to not be reached in the near future. The DC-IAM methodology contained in 14.3.1.4 acts as a risk mitigation tool in case of an unexpected emergency that can limit the rate at which exposure can increase in a short period of time.

14.3.1.3: Stability Fee (SF)

The SF parameter is an annual percentage fee charged on the DAI generated on Vaults. It is expressed as an annual percentage yield but it is charged on a per-block basis in DAI. The DAI from this fee is minted, added to the DAI debt for the vault, and then transferred into the Surplus Buffer which is under the control of Maker Governance. Each vault type has its own Stability Fee that can be adjusted by the Stability Facilitators. The Stability Facilitators must regularly update Vault Type’s Stability Fee according to the following subelements. While Enhanced Dai Savings Rate (EDSR) is active, it replaces Dai Savings Rate (DSR) in the SF Formulas.

14.3.1.3A

¤¤¤

List of Stability Fee Formulas:

• ETH-A: Dai Savings Rate (EDSR while active) + 0.25%

• ETH-B: Dai Savings Rate (EDSR while active) + 0.75%

• ETH-C: Dai Savings Rate (EDSR while active)

• WSTETH-A: Dai Savings Rate (EDSR while active) + 0.25%

• WSTETH-B: Dai Savings Rate (EDSR while active)

• WBTC-A: Yield Collateral Yield Benchmark + 0.25%

• WBTC-B: Yield Collateral Yield Benchmark + 0.75%

• WBTC-C: Yield Collateral Yield Benchmark

¤¤¤

14.3.1.4: Debt Ceiling Instant Access Module (DC-IAM)

The DC-IAM allows any user to adjust the Debt Ceiling of a supported vault type according to the rules defined in the DC-IAM smart contract logic and parameters set by the Stability Facilitators. The DC-IAM holds three parameters that can be set by Maker governance for each vault type, (i) Maximum Debt Ceiling (line), (ii) Target Available Debt (gap), and (iii) Ceiling Increase Cooldown (ttl).

14.3.1.4.1: Maximum Debt Ceiling (line)

The line parameter refers to the maximum value for the Debt Ceiling that the DC-IAM will allow in the given vault type. When using the DC-IAM to manage the Debt Ceiling of a vault type, the line parameter essentially replaces the Debt Ceiling parameter for that vault type. Rather than Maker governance setting the Debt Ceiling directly, they will need to set the Maximum Debt Ceiling (line) in the DC-IAM. The line parameter is defined in DAI.

The Maximum Debt Ceiling is defined in 14.3.1.2 and is currently unlimited.

14.3.1.4.2: Target Available Debt (gap)

The gap parameter controls how much of a gap the DC-IAM aims to maintain between the current debt usage and the Debt Ceiling of the vault type. The higher this value, the more risk there is from large collateral drops in very short amounts of time. The smaller this value, the more vault use is negatively affected. The gap parameter is defined in DAI.

14.3.1.4.3: Ceiling Increase Cooldown (ttl)

The Ceiling Increase Cooldown (ttl) parameter controls how frequently the Debt Ceiling can be increased by the DC-IAM. If a user attempts to use the DC-IAM to increase the Debt Ceiling of a vault type before this time expires, the transaction will fail to execute and the Debt Ceiling will remain unchanged. The ttl parameter in combination with the gap parameter enforces a maximum rate at which debt usage can increase over time using a given vault type. These parameters should be set such that the maximum increase over time can accommodate all reasonable usage of the vault type in question. The ttl parameter is defined in seconds.

14.3.1.5: Auction Parameters

A clear justification and analysis to determine the validity of the changes must be provided in the case of a proposed change to the parameters contained in article “14.3.1.5: Auction Parameters”. In addition, the Stability Facilitators must first propose a governance poll before adding the proposed parameter changes to an executive vote. However, in the case of an emergency, the Stability Facilitators are granted the ability to add these parameters to an executive vote directly. The parameters contained herein must be regularly monitored and updated if needed.

14.3.1.5.1: Auction Price Function (calc)

The Auction Price Function is the mathematical function that determines how the collateral price changes over time during a collateral auction. Collateral auctions use a falling price auction, where the price starts high and decreases according to the function defined in this parameter. The Exponential Stair Step function contains two key parameters, cut and step, defined in article “14.3.1.5.1: Cut” and “14.3.1.5.2: Step” respectively.

14.3.1.5.1.1: cut

The cut parameter controls the ‘depth’ of each step in the function. A smaller cut means a smoother line, a large one means more pronounced steps. The cut parameter is defined as a multiplicative factor. For example, 0.99 equated to a 1% price drop.

14.3.1.5.1.2: step

The step parameter controls the length of time between price drops. A smaller step means a smoother line, a large one means more pronounced steps. The step parameter is defined in seconds.

14.3.1.5.2: Auction Price Multiplier (buf)

The buf parameter is a multiplier that is applied to the starting price of a collateral auction. Each vault type has its own Auction Price Multiplier that can be adjusted by Maker governance separately. This multiplier is intended to be greater than 1.0x because Liquidations 2.0 uses falling price auctions. This means that it is generally preferable for the auction price to begin above the market price and then fall to the correct value over some amount of time. The buf parameter is defined as a multiplicative factor.

14.3.1.5.3: Max Auction Drawdown (cusp)

The Max Auction Drawdown is the maximum percentage drop in collateral price during a collateral auction before the auction is reset. 'Collateral price' in this context refers to the collateral auction price rather than the collateral market price.

The Max Auction Drawdown parameter overlaps with the Max Auction Duration parameter in that an auction will need to be reset once either maximum is exceeded.

14.3.1.5.4: Max Auction Duration (tail)

The Max Auction Duration parameter sets the maximum time that can elapse before an auction needs to reset for a particular vault type. Expressed in seconds, this parameter determines when an auction can no longer settle and must be reset. The Max Auction Duration parameter overlaps with the Max Auction Drawdown parameter in that an auction will need to be reset once either maximum is exceeded.

14.3.1.5.5: Proportional Kick Incentive (chip)

The Proportional Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. The Proportional Kick Incentive is set as a percentage and represents a portion of DAI based on the debt of the vault that is being liquidated. The DAI is rewarded for each liquidation auction at the point the auction is triggered. Each vault type has its own Proportional Kick Incentive that may be adjusted separately by Maker Governance.

14.3.1.5.6: Flat Kick Incentive (tip)

The Flat Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. The Flat Kick Incentive is a fixed amount of DAI that is rewarded for each liquidation auction at the point the auction is triggered. Each vault type has its own Flat Kick Incentive that may be adjusted separately by Maker Governance.

14.3.1.5.7: Liquidation Penalty (chop)

The Liquidation Penalty parameter controls the fee vault owners must pay when their position is liquidated due to insufficient collateral. For a vault holder to receive any collateral back from the liquidations process, the debt and Liquidation Penalty must be covered by the collateral auction. Each vault type has its own Liquidation Penalty that can be adjusted by Maker Governance.

14.3.1.5.8: Local Liquidation Limit (hole)

The Local Liquidation Limit sets the maximum amount of DAI debt for which collateral auctions can be active at any one time within a particular vault type. When the total DAI value of auctions exceeds this maximum for a particular vault type, no more collateral can be auctioned using that vault type until others are completed. Each vault type has a separate Local Liquidation Limit.

14.3.1.6: Debt Floor (dust)

The Debt Floor parameter controls the minimum amount of DAI that can be minted using a specific vault type for an individual vault. If a user tries to mint DAI and the amount of DAI minted would not put the vault's amount of DAI minted above its Debt Floor, the transaction will fail and no DAI will be minted. Likewise, if a user attempts to pay back debt such that their debt will equal less than the Debt Floor and greater than zero, the transaction will fail and no DAI will be paid back. Each vault type has its own Debt Floor that can be adjusted by Maker Governance.

14.3.2: Maker Core Vault Types

14.3.2.1: ETH-A

¤¤¤

Current ETH-A parameters are:

• Stability Fee: 5.25%

• Liquidation Ratio: 145%

• DC-IAM line: 15,000,000,000

• DC-IAM gap: 150,000,000

• DC-IAM ttl: 21,600 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 40,000,000

• dust: 7,500

¤¤¤

14.3.2.2: ETH-B

¤¤¤

Current ETH-B parameters are:

• Stability Fee: 5.75%

• Liquidation Ratio: 130%

• DC-IAM line: 250,000,000

• DC-IAM gap: 20,000,000

• DC-IAM ttl: 21,600 seconds

• cut: 99.00%

• step: 60 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 4,800 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 15,000,000

• dust: 25,000

¤¤¤

14.3.2.3: ETH-C

¤¤¤

Current ETH-C parameters are:

• Stability Fee: 5.00%

• Liquidation Ratio: 170%

• DC-IAM line: 2,000,000,000

• DC-IAM gap: 100,000,000

• DC-IAM ttl: 28,800 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 35,000,000

• dust: 3,500

¤¤¤

14.3.2.4: WSTETH-A

¤¤¤

Current WSTETH-A parameters are:

• Stability Fee: 5.25%

• Liquidation Ratio: 150%

• DC-IAM line: 750,000,000

• DC-IAM gap: 30,000,000

• DC-IAM ttl: 43,200 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 15,000,000

• dust: 7,500

¤¤¤

14.3.2.5: WSTETH-B

¤¤¤

Current WSTETH-B parameters are:

• Stability Fee: 5.00%

• Liquidation Ratio: 175%

• DC-IAM line: 1,000,000,000

• DC-IAM gap: 45,000,000

• DC-IAM ttl: 43,200 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 10,000,000

• dust: 3,500

¤¤¤

14.3.2.6: WBTC-A

¤¤¤

Current WBTC-A parameters are:

• Stability Fee: 5.86%

• Liquidation Ratio: 145%

• DC-IAM line: 500,000,000

• DC-IAM gap: 2,000,000

• DC-IAM ttl: 86,400 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 30,000,000

• dust: 7,500

¤¤¤

14.3.2.7: WBTC-B

¤¤¤

Current WBTC-B parameters are:

• Stability Fee: 6.36%

• Liquidation Ratio: 130%

• DC-IAM line: 250,000,000

• DC-IAM gap: 2,000,000

• DC-IAM ttl: 86,400 seconds

• cut: 99.00%

• step: 60 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 4,800 sec

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 10,000,000

• dust: 25,000

¤¤¤

14.3.2.8: WBTC-C

¤¤¤

Current WBTC-C parameters are:

• Stability Fee: 5.61%

• Liquidation Ratio: 175%

• DC-IAM line: 500,000,000

• DC-IAM gap: 2,000,000

• DC-IAM ttl: 86,400 seconds

• cut: 99.00%

• step: 90 seconds

• buf: 110.00%

• cusp: 45.00%

• tail: 7,200 seconds

• chip: 0.10%

• tip: 250

• chop: 13%

• hole: 20,000,000

• dust: 3,500

¤¤¤

14.3.3

To protect the protocol from unnecessary complexity, the Stability Facilitators must offboard collateral types above if they fall below a total debt of 20 million.

14.3.4

WBTC-A, WBTC-B and WBTC-C are defined in 14.3 only for the purpose of Stability Fee consistency and are otherwise not considered Native Vault Engine collateral and should be offboarded according to 14.3.5.

14.3.5

All other collateral types must be offboarded when the Stability Facilitators considers it appropriate, and when there are new mechanisms in place that can take over the role the offboarded collateral covered.

14.4: Legacy Legal Recourse Assets

Legacy Legal Recourse Assets are LRA collateral types that were onboarded based on the governance process prior to the Alignment Artifacts going into force. Legacy LRA should be offboarded when it is possible to do so, but in some cases existing LRA can be maintained and even onboarded to preserve business relationships and reputation, as determined by the Stability Facilitators. All Legacy Legal Recourse Assets must be offboarded prior to NewChain Launch. The Stability Facilitators must expand this article to detail all Legacy Legal Recourse Assets and detailed, specific plans for when and how they will be offboarded.