# 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. An exception is in effect for BA Labs, while they are the sole core-level Risk Advisor, as it relates to work with Ethena, as this overlap the Maker Ecosystem a higher possibility to have early transparency and opportunity to react in case of any internal issues with Ethena, as well as allowing BA Labs to bring Ethenas risk strategy to standard aligned with Maker. If other Risk Advisors are added, they will need to take over all relevant risk work related to Ethena. ##### 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 knowledge 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. ## 3: Core Stability Parameters Before the launch of AllocatorDAO Vaults and development of a new Rate System, all Core and Spark related Stability parameters are defined by the Stability Facilitators through the weekly governance process or out-of-schedule executive votes, based on the advice from the Stability Advisory Council. ### 3.2: The Dai Savings Rate The Dai Savings Rate can be modified through the weekly governance process, or directly through executive votes, by the Stability Facilitators. #### 3.2.1A ¤¤¤ The Dai Savings Rate is: - **6.00%** ¤¤¤ ##### 3.2.2.5 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. ## 5: Real World Assets Real World 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, Real World 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: - Blocktower Following the voluntary offboarding of Monetalis as an active Arranger, the Clydesdale RWA Arranged Structure must be wound down by the Support Facilitator in collaboration with Monetalis or another suitable entity that can act as interim arranger to ensure a smooth and orderly wind down of the assets in Clydesdale that minimizes fees and maximizes return. ¤¤¤ #### 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 expenses. - 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](https://makerburn.com/#/), [Daistats.com](https://daistats.com/#/), or another dashboard must be publicly available to summarize DAI inflows and outflows from the Maker vault. ### 5.3: Perpetual yield strategies The Stability Facilitators can implement various perpetual yield strategies, including on-chain and off-chain mechanisms, that enable the protocol to take advantage of high risk-adjusted return on perpetual yield strategies in the crypto markets. Exposure targets specified in this section overrides requirements defined by other Articles of the Stability Scope. #### 5.3.1: Perpetual exposure Direct Accumulation The Stability Facilitators can trigger executive votes that instruct Arranged Structures to set up mechanisms that allow them to take direct exposure to Ethena sUSDe, or use legal rails to get direct exposure through custodians. The level of exposure can be manually adjusted in real time by the Stability Facilitators, by directly editing *5.3.1.1A*, *5.3.1.2A*, and *5.3.1.3A* based on advice from Stability Advisors and other Ecosystem Actors. ##### 5.3.1.1A: Current exposure sUSDe Andromeda ¤¤¤ Current target sUSDe exposure is: 0 ¤¤¤ ##### 5.3.1.2A: Current exposure legal rails Clydesdale ¤¤¤ Current target perpetual exposure for Clydesdale is: 0 ¤¤¤ ##### 5.3.1.3A: Current exposure legal rails Andromeda ¤¤¤ Current target perpetual exposure for Andromeda is: 0 ¤¤¤ #### 5.3.2: Morpho overcollateralized sUSDe or USDe DDM The Stability Facilitators can trigger executive votes that set up DDMs to Morpho Vaults that have overcollateralized exposure to sUSDe or USDe. The level of exposure can be manually adjusted in real time by the Stability Facilitators, by directly editing *5.3.2.1A*, based on advice from Stability Advisors and other Ecosystem Actors. A multisig controlled by Facilitator JanSky to control the parameters of the DDM in real time, with guardrails to prevent abuse, in order to follow the Atlas instructions specified in *5.3.2.1A*. The members of the multisig can be expanded beyond the single JanSky account. The multisig and other relevant control mechanisms can be set up with an executive vote that can be triggered at will by the Stability Facilitator. ##### 5.3.2.1A: Current exposure ¤¤¤ Current target exposure of Morpho sUSDe or USDe vault is: 450,000,000 DAI ¤¤¤ ##### 5.3.2.2: Management of metamorpho vault The parameters of the Metamorpho vault is managed through the multisig controlled by Facilitator JanSky, and must be managed based on instructions by the Stability Facilitator based on advice by the Stability Advisor. ## 7: Collateral Portfolio ### 7.1: Stablecoin collateral MakerDAO must maintain a reserve of at least 20% of the total Dai and NewStable Supply held as Cash Stablecoins, or assets and exposure that can rapidly be converted to Cash Stablecoins. #### 7.1.1: USDC PSM and Coinbase Custody Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools falls below 400 million, USDC must be transferred from Coinbase Custody to the PSM to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools exceeds 700 million, USDC must be transferred from the PSM to Coinbase Custody to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. This mechanism can be fully replaced with an upgraded PSM that obsoletes the Coinbase Custody solution. The Stability Facilitator can directly trigger an executive vote to implement an upgraded PSM. #### 7.1.2: Cash Stablecoin Definition A Cash Stablecoin is a stablecoin listed in *7.1.2A* 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.1.2A* 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.1.2A: List of Cash Stablecoins ¤¤¤ List of Cash Stablecoins: - USDC and USDC in Coinbase Custody ¤¤¤ #### 7.1.3: 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. AllocatorDAO Advisory teams are subject to requirements for how they deploy Dai generated from their AllocatorDAO Vault. #### 7.2: Asset Liability Management To ensure adequate liquidity, Cash Stablecoins are managed through a simple ALM framework that allocates excess Cash Stablecoins into low-risk RWA assets, and draw on these assets to replenish the Cash Stablecoins when they fall too low. #### 7.2.1: Excess Cash Stablecoins If the Dai Collateral portfolio contains more than 30% of Cash Stablecoins as defined above, then any Cash Stablecoins above the 30% mark must be allocated towards the collateral defined in *7.2.3* ##### 7.2.2: Lack of Cash Stablecoins If the Dai Collateral portfolio contains less than 20% Cash Stablecoins, the assets defined in *7.2.3* must be sold off to return the Cash Stablecoin exposure to 25%. ##### 7.2.3: Low Risk RWA Andromeda is the RWA Arranged Structure that can allocate capital into Low-Risk RWA (LRR). LRR is safe, short term treasury strategies of less than 1 year duration. Whenever excess Cash Stablecoins must be allocated into LRR, or whenever LRR must be sold to replenish Cash Stablecoins, the amounts allocated or sold are applied to the Andromeda RWA Arranged Structures. Control of the Andromeda RWA Arranged Structure must be prepared to transition to the Spark SubDAO. ##### 7.2.4: Optimizations The Stability Facilitators can use the weekly governance cycle to modify the Asset Liability Management approach in order to make it more efficient, or more resilient. This involves changing any of the logic defined in *7.2*. #### 7.3: Legacy RWA Old RWA exposure that was added before Endgame must stay for as long as necessary, and optimized for yield if possible. When it is possible the Stability Facilitators should take action to wind down and offboard all Legacy RWA. Governance actions related to optimizations, wind down and offboardings can be done directly in executive votes with no prior poll needed. ## 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: 55 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: ¤¤¤ 200 million Dai per year ¤¤¤ ##### 9.1.2.1: Maximum price The Smart Burn Engine must be turned off, and the Surplus Buffer Upper Limit set to infinity via an executive vote if the MKR price surpasses 8000 USD, or the NewGovToken price surpasses 0.33 USD #### 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: 10,249 seconds ¤¤¤ ##### 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: 65,000 DAI ¤¤¤ ##### 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. ## 13: Lockstake Engine Dai Generation Risk Parameters The Stability Facilitators must research how to set the adjustable risk parameters of the Sagittarius Engine Vaults. The Lockstake Engine and its NewStable Generation Risk Parameters can be implemented using the weekly governance cycle. ## 14: Scope Bootstrapping During the bootstrapping phase, the Stability Scope is modified to override the Atlas requirements in some places. ### 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. The Stability Advisory Council must develop a Rate System for defining various rates in the system, including Core Crypto vaults and future AllocatorDAOs lending engines minimum rate. It must be based on external benchmarks; the risk free rate and currently highest sustainable rate in crypto financial markets, which act as the lowest and highest base rate on which various additional spreads can be attached in order to better reflect the risks involved with the specific lending facility. The Rate System must be dynamic, based on the state of Cash Stablecoins in the system and naturally move the state towards the target Cash Stablecoins defined in *7.2*. ###### 14.3.1.3.1A ¤¤¤ ETH: - `SR` = 0.00% - `K` = 27.43% - `Ka` = 0.00% - `Kb` = 40.00% - `KFa` = 5.50% - `KFb` = 40.50% WSTETH: - `SR` = 0.00% - `K` = 12.46% - `Ka` = 0.00% - `Kb` = 20.00% - `KFa` = 3.50% - `KFb` = 7.50% WBTC: - `SR` = 1.00% - `K` = 2.65% - `Ka` = 3.00% - `Kb` = 10.00% - `KFa` = 3.50% - `KFb` = 35.50% ¤¤¤ ###### 14.3.1.3.2A ¤¤¤ 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.3.3A ¤¤¤ 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.42% WSTETH-B Spread: - LR Spread is 0.00% - Exposure Spread is 1.49% - Asset Spread is 0.42% 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: 6.25% - Liquidation Ratio: 145% - DC-IAM `line`: 15,000,000,000 DAI - DC-IAM `gap`: 150,000,000 DAI - 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 DAI - `dust`: 7,500 DAI ¤¤¤ ##### 14.3.2.2: ETH-B ¤¤¤ Current ETH-B parameters are: - Stability Fee: 6.75% - Liquidation Ratio: 130% - DC-IAM `line`: 250,000,000 DAI - DC-IAM `gap`: 20,000,000 DAI - 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 DAI - `dust`: 25,000 DAI ¤¤¤ ##### 14.3.2.3: ETH-C ¤¤¤ Current ETH-C parameters are: - Stability Fee: 6.00% - Liquidation Ratio: 170% - DC-IAM `line`: 2,000,000,000 DAI - DC-IAM `gap`: 100,000,000 DAI - 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 DAI - `dust`: 3,500 DAI ¤¤¤ ##### 14.3.2.4: WSTETH-A ¤¤¤ Current WSTETH-A parameters are: - Stability Fee: 7.25% - Liquidation Ratio: 150% - DC-IAM `line`: 750,000,000 DAI - DC-IAM `gap`: 30,000,000 DAI - 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`: 30,000,000 DAI - `dust`: 7,500 DAI ¤¤¤ ##### 14.3.2.5: WSTETH-B ¤¤¤ Current WSTETH-B parameters are: - Stability Fee: 7.00% - Liquidation Ratio: 175% - DC-IAM `line`: 1,000,000,000 DAI - DC-IAM `gap`: 45,000,000 DAI - 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`: 20,000,000 DAI - `dust`: 3,500 DAI ¤¤¤ ##### 14.3.2.6: WBTC-A ¤¤¤ Current WBTC-A parameters are: - Stability Fee: 7.75% - Liquidation Ratio: 145% - DC-IAM `line`: 0 DAI - DC-IAM `gap`: 4,000,000 DAI - 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`: 10,000,000 DAI - `dust`: 7,500 DAI ¤¤¤ ##### 14.3.2.7: WBTC-B ¤¤¤ Current WBTC-B parameters are: - Stability Fee: 8.25% - Liquidation Ratio: 130% - DC-IAM `line`: 0 DAI - DC-IAM `gap`: 2,000,000 DAI - 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`: 5,000,000 DAI - `dust`: 25,000 DAI ¤¤¤ ##### 14.3.2.8: WBTC-C ¤¤¤ Current WBTC-C parameters are: - Stability Fee: 7.50% - Liquidation Ratio: 175% - DC-IAM `line`: 0 DAI - DC-IAM `gap`: 8,000,000 DAI - 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`: 10,000,000 DAI - `dust`: 3,500 DAI ¤¤¤ #### 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.3.6: Native Vault Engine Oracles The Native Vault Engine collateral types of ETH, STETH, WBTC will specifically use the Chronicle v3 oracle solution, until at least January 1st 2026. The Native Vault Engine collateral types must be migrated to the new version of the Chronicle v3 oracle when it is feasible to do so. Other oracle solutions, including diversified oracles, will only be considered until January 1st 2026 in case of unresolvable security concerns with the Chronicle v3 oracles.