MIP104: Stability Scope

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. There are also sometimes specific pieces of advisory work listed in 1.1.3.2 that can be taken on by applicants. 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: Advisory Work for Stability Advisory Council Members

• Liquidity risk is very important in maintaining a strong peg. DAI should be pegged 1:1 to USD, but allowing fluctuations for very short periods of time; specifically, a depeg of up to 10% for at most 48 hours is the most DAI should ever depeg. To this aim, Advisory work is required on how we should classify/de-average collateral - which can use the five defined ALM tiers as a starting point - and how much we could allocate to each classification to optimize revenues while maintaining these standards for the peg. This work should be prioritized very highly.

• Design a framework for MakerDAO and SubDAOs to adequately monitor RWAs with minimal conflicts of interest. Part of the framework should include the necessity of giving access to all required data to a completely unaffiliated 3rd party. The list of accepted/trusted unaffiliated 3rd parties is regularly published by MakerDAO. It should also include penalties of some sort for non-compliance. The advisor should also recommend a 3rd party to hire as an ecosystem actor to onboard onto the list of accepted/trusted unaffiliated 3rd parties and execute the monitoring, alongside the criteria for the recommendation should we choose not to directly accept the recommendation.

1.1.3.3

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. The Stability Facilitators must communicate in the first 15 days of a quarter if they believe no Advisory Council work is needed for that quarter.

1.1.3.4

In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the 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.5

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

¤¤¤

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:

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.18%

¤¤¤

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:

• 3.93%

¤¤¤

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 follows the Exposure Model methodology (14.3.1.3) and is defined as: Spark DAI Effective borrow APY = Dai Savings Rate (EDSR while active) + Liquidation Ratio Spread + Asset Spread.

3.2.2A

¤¤¤

Spark:

• SR = 0.00%

• K = 10.00%

• Ka = 0.00%

• Kb = 30.00%

• KFa = 0.0015%

• KFb = 0.07%

¤¤¤

3.2.2B

¤¤¤

Spark DAI Effective Borrow APY: Dai Savings Rate (EDSR while active) + Spark LR Spread + Asset Spread

¤¤¤

3.2.2C

¤¤¤

Spark Spread:

• LR Spread is 0.50%

• Asset Spread is 0.60%

¤¤¤

3.2.2.1

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%, or when the Exposure Spread or Asset Spread change is greater than +/-10% 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

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 applies: 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.2.5

Crypto-collateral counts as ALM Tier 2 Collateral, and Debt Ceilings for Crypto Collateral cannot increase if it would cause an overexposure to ALM Tier 2 Collateral. Additionally, if ALM Tier 2 Collateral is overexposed, the Stability Facilitators may choose to use the weekly cycle to propose extraordinary increases in Stability Fees to crypto-collateral in order to incentivize the exposure to go below the permitted amount of ALM Tier 2 Collateral.

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

MakerDAO must maintain a reserve of at least 18% of the total Dai Supply held as Cash Stablecoins, or assets and exposure that can rapidly be converted to Cash Stablecoins.

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. This can include adding or removing Cash Stablecoins, or changing the terms of existing Cash Stablecoins on the list.

7.2.1.3.1A

¤¤¤

List of Cash Stablecoins:

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

¤¤¤

7.2.1.3.2: Cash Stablecoin Peg Stability Module Upgrades

The mechanism for holding and making Cash Stablecoins available to support the liquidity of Dai can be upgraded to a superior technical, financial or legal solution by a proposal from the Stability Facilitators through the weekly cycle.

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: 15,768

¤¤¤

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: 30,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:

• 1.15%

¤¤¤

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.54%

¤¤¤

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. Stability Fee is determined through an exposure based model which slightly differs between vault types and Effective Spark APY Borrow Rate. The model works as follows:

Stability Fee = Initial Rate + Liquidation Ratio Spread + Exposure Spread + Asset Spread

Initial Rate is defined as the rate on top of which additional spreads are layered and is equal to Dai Savings Rate (EDSR while active) for Native Vault types and Yield Collateral Yield Benchmark for Non-Native vault types.

Liquation Ratio Spread is defined based on specified Liquidation Ratios of vault types which are divided into three tiers, namely normal (0.25%), low (0.00%), and high (0.75%). Exposure Spread (ES) represents the total exposure as percentage of total DAI minted of a specific core asset and is currently used for ETH (calculated by summing up ETH and wstETH) and WBTC vault types. It is a piecewise function calculated as:

ES = SR+(K-Ka)*KFa*H(K-Ka)*[1-H(K-Kb)] + [(Kb-Ka)*KFa+(K-Kb)*KFb]*H(K-Kb)

With Parameters:

• SR equal to a starting rate

• K equal to the %Exposure (rounded to two decimal places)

• Ka equal to the First Kink

• Kb equal to the Second Kink

• KFa equal to the Linear increase after the First Kink

• KFb equal to the Linear increase after the Second Kink

• When 0% ≤ K < Ka, both H(K - Ka) and H(K - Kb) are 0, so the equation reduces to ER = SR.

• When Ka ≤ K < Kb, H(K - Ka) is 1 and H(K - Kb) is 0, so the equation becomes ER = SR + (K - Ka) * KFa.

• When Kb ≤ K ≤ 100%, both H(K - Ka) and H(K - Kb) are 1, so the equation becomes ER = SR + (Kb - Ka) × KFa + (K - Kb) x KFb.

• Asset spread (AS) represents individual asset exposure as percentage of total DAI minted and is currently used for Liquid Staking Tokens (WSTETH-A, WSTETH-B) and to calculate the Spark DAI borrow

• Effective APY. It is a piecewise function calculated as:

  • AS = SR+(K-Ka)*KFa*H(K-Ka)*[1-H(K-Kb)] + [(Kb-Ka)*KFa+(K-Kb)*KFb]*H(K-Kb)

  • With Parameters:

    • SR equal to a starting rate

    • K equal to the %Exposure (rounded to two decimal places)

    • Ka equal to the First Kink

    • Kb equal to the Second Kink

    • KFa equal to the Linear increase after the First Kink

    • KFb equal to the Linear increase after the Second Kink

    • When 0% ≤ K < Ka, both H(K - Ka) and H(K - Kb) are 0, so the equation reduces to ER = SR.

    • When Ka ≤ K < Kb, H(K - Ka) is 1 and H(K - Kb) is 0, so the equation becomes ER = SR + (K - Ka) * KFa.

    • When Kb ≤ K ≤ 100%, both H(K - Ka) and H(K - Kb) are 1, so the equation becomes ER = SR + (Kb - Ka) * KFa + (K − Kb) * KFb.

14.3.1.3A

¤¤¤

ETH:

• SR = 0.00%

• K = 24.92%

• Ka = 0.00%

• Kb = 40.00%

• KFa = 0.01375%

• KFb = 0.0875%

WSTETH:

• SR = 0.00%

• K = 12.12%

• Ka = 0.00%

• Kb = 20.00%

• KFa = 0.00875%

• KFb = 0.0250%

WBTC:

• SR = 1.00%

• K = 1.95%

• Ka = 3.00%

• Kb = 10.00%

• KFa = 0.00875%

• KFb = 0.08%

¤¤¤

14.3.1.3B

¤¤¤

List of Stability Fee Formulas according to the current conditions and chosen meta-parameters:

• ETH-A: Dai Savings Rate (EDSR while active) + Normal LR Spread + Exposure Spread

• ETH-B: Dai Savings Rate (EDSR while active) + Low LR Spread + Exposure Spread

• ETH-C: Dai Savings Rate (EDSR while active) + High LR Spread + Exposure Spread

• WSTETH-A: Dai Savings Rate (EDSR while active) + Normal LR Spread + Exposure Spread + Asset Spread

• WSTETH-B: Dai Savings Rate (EDSR while active) + High LR Spread + Exposure Spread + Asset Spread

• WBTC-A: Yield Collateral Yield Benchmark + Normal LR Spread + Exposure Spread

• WBTC-B: Yield Collateral Yield Benchmark + Low LR Spread + Exposure Spread

• WBTC-C: Yield Collateral Yield Benchmark + High LR Spread + Exposure Spread

¤¤¤

14.3.1.3C

¤¤¤

ETH-A Spread:

• LR Spread is 0.25%

• Exposure Spread is 1.49%

• Asset Spread is 0.00%

ETH-B Spread:

• LR Spread is 0.75%

• Exposure Spread is 1.49%

• Asset Spread is 0.00%

ETH-C Spread:

• LR Spread is 0.00%

• Exposure Spread is 1.49%

• Asset Spread is 0.00%

WSTETH-A Spread:

• LR Spread is 0.25%

• Exposure Spread is 1.49%

• Asset Spread is 0.32%

WSTETH-B Spread:

• LR Spread is 0.00%

• Exposure Spread is 1.49%

• Asset Spread is 0.32%

WBTC-A Spread:

• LR Spread is 0.25%

• Exposure Spread is 1.00%

• Asset Spread is 0.00%

WBTC-B Spread:

• LR Spread is 0.75%

• Exposure Spread is 1.00%

• Asset Spread is 0.00%

WBTC-C Spread:

• LR Spread is 0.00%

• Exposure Spread is 1.00%

• Asset Spread is 0.00%

¤¤¤

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.79%

• 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.29%

• 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.54%

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