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:
Expertise in capital markets, bonds, equities.
Experience as a market analyst or economist.
Expertise in tokenomics.
Expertise in fund management and risk profiles.
Deep knowlege of decentralized collateral accounting and finance.
Experience in credit risk, market risk, liquidity risk, and operational risk.
Deep understanding of principles of portfolio construction, asset allocation, diversification strategies, and performance measurement.
Experience in smart contract and DeFi risk management.
Experience in economic modeling of high-volatility portfolios.
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:
¤¤¤
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
1.1.3: Stability Advisory Council Projects and Funding
The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework.
1.1.3.1
Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any entity can notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. The Stability Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Stability Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Stability Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Stability Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process.
1.1.3.2
Each Quarter, if they deem it necessary, the Stability Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Stability Facilitators.
1.1.3.3
In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Stability Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Stability Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.
1.1.3.4
The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Stability Facilitators must either transcribe it themselves, or hire an Ecosystem Actor to perform the transcription. This role does not require pre approval by Maker Governance.
1.1.4
The Stability Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content.
1.1.5
The Stability Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in 1.1.5.1B.
1.1.5.1B
¤¤¤
Advisory Council project budget:
¤¤¤
1.2: Stability Scope DAO Toolkit Integration
The Stability Scope DAO Toolkit module must be built to give a full and accessible overview of all data and processes relevant to the Stability Scope.
2: Dai Stablecoin Reference Asset
This Article must be strengthened to ensure balanced and appropriate funding of proactive research into future reference assets.
3: Core Stability Parameters
Before the launch of AllocatorDAO Vaults, the Core Stability parameters are fixed to help bootstrap the system.
3.1: The Base Rate
The Base Rate is regularly updated by the Stability Facilitator to approximate ((Yield Collateral Yield Benchmark - 0.5%) * 0.78 + Stability Collateral Yield Benchmark * 0.22). The up to date Base Rate is contained in 3.1.1A. Whenever an update to the Base Rate occurs, the Stability Facilitator must trigger an executive vote to update the on-chain Stability Fees of the AllocatorDAO Vaults.
3.1.1A
¤¤¤
The Base Rate is:
4.45%
¤¤¤
3.2: The Dai Savings Rate
The Dai Savings Rate is regularly updated to be equal to (Base rate - 0.25%). The up to date Dai Savings Rate is contained in 3.2.1A. Whenever an update to the Dai Savings Rate occurs, the Stability Facilitators must trigger an executive vote to update the on-chain Dai Savings Rate.
3.2.1A
¤¤¤
The Dai Savings Rate is:
4.20%
¤¤¤
3.2.2: Enhanced Dai Savings Rate
The Enhanced Dai Savings Rate is a system to temporarily increase the effective DSR available to users in the early bootstrapping stage when DSR utilization is low. The EDSR is determined based on the DSR and the DSR utilization rate, under the control of the Stability Facilitators, and decreases over time as the utilization increases, until it eventually disappears when utilization gets high enough, when triggered by the Stability Facilitators. EDSR is a one-time, one-way temporary mechanism, which means that the EDSR can only decrease over time, it cannot increase again even if DSR utilization goes down.
The Stability Facilitators can take actions related to the EDSR through forum posts signed by their approved Ethereum address.
Other parameters and mechanisms that are dependent on the DSR, such as crypto-collateralized stability fees, are affected by the EDSR. This applies to all crypto-collateralized Vault Types except for Spark Protocol.
Spark Protocol has a borrow rate spread that is 0.5% above the EDSR, as long as the EDSR is active. As long as Spark Protocol remains near its maximum borrow limit, the Stability Facilitators can use the weekly governance cycle to propose to increase its Debt Ceiling to attract more users. If Spark Protocol falls below 200 million active borrowing for an extended period of time, the Stability Facilitators can use the weekly governance cycle to propose a decrease to the borrow rate spread to attempt to incentivize usage to increase above 200 million.
When NewGovToken and SubDAO farming comes into effect, DSR utilization will count both DSR use and NewGovToken and SubDAO farming use.
3.2.2.1: EDSR Upper Limit
The EDSR cannot exceed 5%. If the EDSR formula outputs a number above 5%, the actual effective EDSR implemented in the protocol will be 5% instead.
3.2.2.2: EDSR Utilization-Based Multipliers
Each of the following EDSR multiplier tiers can be triggered by the Stability Facilitators based on the utilization rate. When first adopted, the EDSR begins at tier 1. If at any point in time the DSR utilization stays above the level needed for a different tier for a continuous period of more than 24 hours, the Stability Facilitator can choose to trigger the new tier, and a manual DSR adjustment must then be included in the next executive vote to account for the new tier.
3.2.2.2.1: EDSR tier 1
Multiplier: 1.75x DSR
Utilization: 0-35%
3.2.2.2.2: EDSR tier 2
Multiplier: 1.15x DSR
Utilization: 35-50%
3.2.2.3
EDSR can be ended permanently by the Stability Facilitators once DSR utilization crosses above 50% for a continuous period of more than 24 hours.
3.2.2.4
The Stability Facilitators can at any time use the weekly governance cycle to disable the EDSR permanently, or modify any of its parameters or logic in 3.2.2 or its subelements, if there are indications that it is not cost-effectively achieving its objectives.
3.3: Dai Savings Rate and Base Rate Changes in Demand Shocks
The Stability Facilitators can use the urgent governance cycle to propose non-standard changes to the Dai Savings Rate and the Base Rate in case of risks to the peg stability of Dai. Once the risks have subsided, the Dai Savings Rate and Base Rate must be reverted to their ordinary values, according to 3.1.1A and 3.2.1A.
3.4: Core Stability Parameters Update Frequency
This element and subelements define the minimum frequency of when they must be updated and implemented in the protocol. All parameters which are derived from the Core Stability Parameters must be updated at the same time, such as Native Vault Engine. Any other element which is more specific to a set of parameters or describes unique instances such as emergencies overrides this element. The Core Stability Parameters update is subject to three different conditions defined in the subelements
3.4.1: Duration Based Condition
Core Stability Parameters must be updated at a minimum of 2 months since the last spell execution which included previous update in the next available executive spell
3.4.2: Base Rate Change Condition
Core Stability Parameters must be updated when the Base Rate Change is greater than +/-5% in the next available executive spell
3.4.3: Stability Scope Language Amendment
Core Stability Parameters must be updated when the language of the Core Stability Parameters or elements containing definitions and formulas for parameter setting which depend on the Core Stability Parameters are amended in the next available executive spell
4: AllocatorDAO Vaults
Before the launch of SubDAOs, AllocatorDAO Vaults function in a bootstrapping mode. They are controlled by AllocatorDAO Advisors, which are special Ecosystem Actors with the ability to advise the Stability Facilitators
4.1: AllocatorDAO Vaults Stability Fee
The AllocatorDAO Vaults have a Stability Fee equal to the Base Rate specified in 3.1.1A.
4.2: AllocatorDAO Advisors
The Stability Facilitator can use the weekly governance cycle to propose to onboard AllocatorDAO Advisors and set up a new AllocatorDAO Vault, based on AllocatorDAO Advisor Proposals made on the Maker Forum. The AllocatorDAO Advisor will be tasked with publishing advice related to the use of their AllocatorDAO vault. The current active AllocatorDAO Advisers and their individual Debt Ceiling Limits are specified in 4.2.2A, and must be updated by the Stability Facilitators when applicable.
4.2.1
The AllocatorDAO Vaults share a total debt ceiling limit equivalent to the Dai Supply, minus all legacy collateral. Each AllocatorDAO Vault has an individual debt ceiling limit of its proportional amount of the total debt ceiling limit.
4.2.2A
¤¤¤
Current active AllocatorDAO Advisors:
N/A
¤¤¤
5: Legal Recourse Assets
Legal Resource Assets are assets used as collateral for the Dai Stablecoin that are enforced through legal recourse by Arranged Structures. They have unique risks that must be safeguarded against.
5.1: Arrangers
Arrangers are Ecosystem Actors that specialize in sourcing, negotiating, structuring of, and reporting on, Legal Recourse Assets and maintaining and monitoring the underlying Arranged Structures used by the Maker Protocol. They must never be able to operate or influence the arranged legal and operational structure’s asset operations in a way that can cause any significant harm or losses to Dai’s stability, after the structures have been built and assets allocated hereto. Arrangers are approved directly by MKR voters, and all LRA collateral exposure must be structured by an approved Arranger.
5.1.1: Active Arranger Management
Arrangers are onboarded or offboarded based on a governance poll by MKR voters, that is initiated by the Stability Facilitators if they deem it necessary. The active state of current approved Arrangers is maintained in 5.1.1.1A.
5.1.1.1A
¤¤¤
List of current active Arrangers:
Monetalis
Blocktower
¤¤¤
5.1.2: Arranger Standard Fees
Arrangers may charge a maximum reporting fee of 15 basis points per year on top of other fees charged by the structure and the Asset Manager. The fee is calculated based on the utilized Debt Ceiling of the Arranger Vault, and may not be charged up front without a standalone vote by governance for approval. For stable asset Arranger services, Arrangers may charge up to 10 basis points. Any asset reasonably expected to only maintain or grow value, such stablecoins, US government securities, or bank deposits is a stable asset. In the event a single Arranger structure contains both stable assets and non-stable assets, the maximum fee applies proportionately to each part of the portfolio.
An Arranger that is not compliant with 5.1.4 for 60 days or more will not receive further funding from MakerDAO governance or the entities it reports upon until it becomes compliant. In the event the Arranger reports upon multiple entities, the prohibition applies only to the specific entities and Maker vaults where the Arranger is noncompliant.
5.1.3: Arranger Concentration Risk Management
The Stability Facilitators must take action to search and propose onboarding of additional Arrangers when it is economically feasible to do so, in order to help reduce the concentration risk to individual Arrangers. Strict limits to the amount of assets that each Arranger services for must be developed and implemented in this section over time.
5.1.4: Arranger Reports and Stress Tests
Arrangers must publish monthly reporting on each Arranged Structure they have arranged, and must every six months also publish stress test analysis that shows how the structures would perform based on historical financial crisis scenarios and other example scenarios. The Stability Facilitators must periodically fund independent Ecosystem Actors to review and verify the quality and the results of the stress tests. Should an independent review produce an unfavorable result, the Responsible Facilitators must propose a governance poll for warning, temporarily deactivating, or permanently offboarding the Arranger and/or the Asset Managers connected to the discovered issue.
Monthly reports must satisfy 5.1.4.1 or 5.1.4.2 or 5.1.4.3 to be considered compliant.
5.1.4.1
The following information should be included in the monthly Arranger report. Each item should be provided for at least the beginning and ending date of the reporting period (the first business day after beginning date and last business day before the ending date may be used if the beginning and ending dates fall on days markets are closed):
Cash balance.
Cash income over the reporting period. Any income over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expensesi.
Cash expenses over the reporting period. Any expense over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expenses.
Market value of publicly traded equities, ETFs, and mutual funds.
Market value (the closing price) of publicly traded debt securities. Debt securities that are investment grade and less than 12 months from maturity may alternatively be reported at cost basis + linearly recognizing scheduled interest income.
A valuation for illiquid or privately traded assets. This should utilize a valuation from a reputable third party with relevant expertise or follow a well-defined methodology that is explained in detail in the report.
CUSIPs, date of purchase, date of maturity, coupon, cost basis, and face value of all publicly traded debt securities in the portfolio for the last day of the reporting period.
DAI inflows from the Maker protocol during the reporting period.
Total repayments on-chain to the Maker protocol either to a vault or for surplus. If repayments are derived from multiple sources, they should be broken out into line items for each source.
Vault debt to the Maker protocol.
The Scope Facilitator must publicly state on the MakerDAO forum that they have reviewed original documentation for accounts that supports the Arranger’s summarization.
5.1.4.2
The following information should be included in the monthly Arranger report:
Copies of original statements for all bank, brokerage, exchange, custodial, or other accounts. The Arranger may redact the names for non-Arranger service providers if and only if that is a requirement of confidentiality agreements with the non-Arranger service providers. DAI inflows from the Maker protocol during the reporting period. Total repayments on-chain to the Maker protocol either to a vault or for surplus. If repayments are derived from multiple sources, they should be broken out into line items for each source. Vault debt to the Maker protocol.
5.1.4.3
The following information must be provided through public read-only access to all accounts:
All asset balances
All transaction amounts (non-Arranger service provider names may be redacted)
Hold-to-maturity yields (for assets with maturity) or current yield (for assets with no maturity)
In addition, Makerburn.com, Daistats.com, or another dashboard must be publicly available to summarize DAI inflows and outflows from the Maker vault.
5.2: Legal Recourse Asset Budget
The Stability Facilitators have a budget available to pay costs related to stress test review, legal research and first time setup of legal structures for arrangers, and other expenses relevant to Legal Recourse Assets. Arrangers that are supported this way must publish all research and conclusions related to the Arranged Structure, to help other arrangers replicate the work and strengthen the Maker Arranger ecosystem. The Legal Recourse Asset Budget is specified in 5.2.1B.
5.2.1B
¤¤¤
The Legal Recourse Asset budget is:
Up to 1,000,000 DAI available per year.
The full amount is immediately available at the start of the calendar year, and parts of it can be paid out through executive vote bundling when requested by the Stability Facilitators.
¤¤¤
6: AllocatorDAO Effective Junior Capital
The Stability Facilitators and Stability Advisory Council Members must research and develop a framework for determining adequate multipliers for the different sources of AllocatorDAO Effective Junior Capital.
7: AllocatorDAO Collateral and Market Requirements
AllocatorDAO Advisory teams are subject to requirements for how they deploy Dai generated from their AllocatorDAO Vault.
7.1: AllocatorDAO Capitalization Requirements
AllocatorDAOs will have Capitalization Requirements of their Effective Junior Capital based on what kind of exposure they have from their AllocatorDAO Vaults. Before the launch of SubDAOs, AllocatorDAO Advisory Teams can use this framework to deploy collateral that has no Effective Junior Capital Requirement.
7.1.1: ALM Capitalization Requirements
Temporarily, before the launch of SubDAOs, ALM requirements are calculated in a unique way that ignores crypto-collateralized Dai from the overall calculation. Accordingly, the total size of the Dai Collateral Portfolio that is being considered for ALM calculations, called the Dai Non-Crypto collateral Portfolio, is equivalent to total size of the entire Dai Collateral Portfolio, subtracted all ETH, STETH, WBTC, and Spark protocol exposure, plus any other similar crypto collateralized positions. Additionally, crypto-collateralized exposure doesn't count towards any of the ALM tiers.
7.1.1.1: ALM Tier 1 Collateral
7.1.1.1.1
No slippage is allowed for ALM Tier 1 Collateral.
7.1.1.1.2
ALM Tier 1 Collateral must be able to instantly convert to Cash Stablecoins within 30 minutes with no slippage.
7.1.1.1.3
ALM Tier 1 Collateral or higher can be used for 100% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.
7.1.1.1.4
There are no additional Effective Junior Capital Requirements.
7.1.1.2: ALM Tier 2 Collateral
7.1.1.2.1
ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 2 weeks with expected slippage and realized loss of at most 1%.
7.1.1.2.2
ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 6 months with no slippage.
7.1.1.2.3
ALM Tier 2 Collateral or higher can be used for 78% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.
7.1.1.2.3.1
Temporarily before the launch of SubDAOs, the following additional requirement apples: The Arranged Structures holding ALM Tier 2 Collateral must have standing instructions to immediately convert to Dai and repay the necessary amount of ALM Tier 2 Collateral to bring total exposure of the Dai Non-Crypto Collateral Portfolio to ALM Tier 2 Collateral or higher to 78%, whenever the total exposure of the Dai Non-Crypto Collateral Portfolio to collateral of ALM Tier 2 or higher exceeds 82%. The necessary amount that must be converted is split proportionally between all Arranged Structures holding ALM Tier 2 Collateral based on their relative holdings of ALM Tier 2 Collateral.
7.1.1.2.4
If the exposure limit is exceeded, the excess ALM Tier 2 Collateral has an additional 5% Effective Junior Capital Requirement.
7.1.1.3: ALM Tier 3 Collateral
7.1.1.3.1
No slippage is allowed for ALM Tier 3 Collateral.
7.1.1.3.2
ALM Tier 3 Collateral must be able to convert to Cash Stablecoins within at most 12 months with no slippage.
7.1.1.3.3
ALM Tier 3 Collateral or higher can be used for 45% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.
7.1.1.3.4
If the exposure limit is exceeded, the excess ALM Tier 3 Collateral has an additional 10% Effective Junior Capital Requirement.
7.1.1.4: ALM Tier 4 Collateral.
7.1.1.4.1
No slippage is allowed for ALM Tier 4 Collateral.
7.1.1.4.2
ALM Tier 4 Collateral must be able to convert to Cash Stablecoins within at most 3 years with no slippage.
7.1.1.4.3
ALM Tier 4 Collateral or higher can be used for 10% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement.
7.1.1.4.4
If the exposure limit is exceeded, the excess ALM Tier 4 Collateral has an additional 20% Effective Junior Capital Requirement.
7.1.2: Risk Capitalization Requirements
7.1.2.1: Risk Tier 1
Risk tier 1 assets have no Effective Junior Capital Requirement. Approved Risk Tier 1 Collateral are specified in the subelements of this element.
7.1.2.1.1
US Government Treasury Bonds, Notes and Bills.
7.1.2.1.2
Money Market Instruments defined as investment-grade, highly liquid, short-term debt instruments that can be exchanged for cash within 5 business days. Allowed Money Market instrument types include: term certificates of deposit, interbank loans, money market funds/ETF, commercial paper, Treasury bills, and securities lending and repurchase agreements (“repos”).
7.1.2.1.3
Overcollateralized ETH and Staked ETH vaults with at least 125% collateral ratio and automated liquidations.
7.1.2.1.4
Overcollateralized major crypto asset vaults with at least 150% collateral ratio and automated liquidations.
7.1.2.1.5
Cash Stablecoins.
7.2: AllocatorDAO Market Requirements
AllocatorDAOs are required to take specific market actions or be penalized. AllocatorDAO Advisor teams must follow these instructions to the best of their ability.
7.2.1: Cash Stablecoin Liquidity Requirements
7.2.1.1: Cash Stablecoin Reserve Requirements
AllocatorDAOs must have a reserve of Cash Stablecoins of at least 18% of their total portfolio.
7.2.1.2: Cash Stablecoin Market Making Requirements
AllocatorDAOs must be actively market making Cash Stablecoins against Dai with at least 18% of their total portfolio. Before the launch of SubDAOs, this requirement must be substituted by temporary solutions determined by the Stability Facilitators and proposed through the Weekly Governance Cycle.
7.2.1.3: Cash Stablecoin Definition
A Cash Stablecoin is a stablecoin listed in 7.2.1.3.1A or a technically secure DeFi token that can be instantly converted to a listed stablecoin, or a custody solution that can be converted into a listed stablecoin within 30 minutes. The Stability Facilitators can modify 7.2.1.3.1A through the weekly cycle to react to changing market conditions, opportunities or risks.
7.2.1.3.1A
¤¤¤
List of Cash Stablecoins:
USDC - Exposure to USDC in centralized custody solutions is capped at 1.5 billion USDC.
USDP - Exposure to USDP is capped at 120 million USDP and exposure to USDP requires that a marketing reward of at least 2% is available.
¤¤¤
8: AllocatorDAO Penalties
The Stability Facilitators and Stability Advisory Council Members must research a framework for applying penalties to AllocatorDAOs in alignment with ATL5.8.
9: Surplus Buffer and Smart Burn Engine
9.1: Smart Burn Engine Parameters
The amount of Dai in the Surplus Buffer that causes the Smart Burn Engine to activate, and the rate at which it uses the Dai to improve MKR liquidity, are determined by two parameters defined by the following subelements. The Smart Burn Engine which defines specific parameter configuration requirements of DssFlapper and how it should be altered are also defined in the following subelements.
9.1.1
The Surplus Buffer Upper Limit determines the amount of Dai necessary for the Smart Burn Engine to activate.
9.1.1A
¤¤¤
The Surplus Buffer Upper Limit is:
50 million Dai
¤¤¤
9.1.2
The Rate Of MKR Accumulation determines how much Dai is used to accumulate MKR per unit of system time. Since the Smart Burn Engine pairs the accumulated MKR with Dai directly from the Surplus Buffer, the effective rate of spending from the Surplus Buffer is approximately twice the Rate Of Accumulation. If the Surplus Buffer starts consistently exceeding the Surplus Buffer Upper Limit and continues to increase, without ever reducing the total Surplus back down to the Surplus Buffer Upper Limit, the Stability Facilitators must use the weekly governance cycle to modify 9.1.2A to make sure it is high enough to ensure all surplus exceeding the Surplus Buffer Upper Limit is eventually used up by the Smart Burn Engine.
9.1.2A
The Rate Of MKR Accumulation is:
¤¤¤
60 million Dai per year
¤¤¤
9.1.3
DssFlapper is the current implementation of contract which processes Smart Burn Engine transactions once activated. The DssFlapper includes the following parameters; hop, want, bump, pip and receiver. Stability Facilitators can propose DssFlapper reconfiguration within limits defined in each parameter corresponding subelement directly to the executive vote, except for the receiver and pip, which always require a governance vote except in the state of emergency where changing them prevents loss of funds for the protocol.
9.1.3.1
Flapper.hop: Minimum seconds interval between kicks.
Determines maximum allowed frequency of transactions taking place.
Maximum hop must be set to equal the approximate Effective Rate of MKR Accumulation defined in 9.1 depending on the corresponding configuration of bump parameter.
9.1.3.1A
¤¤¤
The hop parameter is: 6,308
¤¤¤
9.1.3.2
Flapper.want: Relative multiplier of the oracle price needed for the swap.
For example, 0.98 * WAD allows for a 2% worse price than the MKR/USD reference oracle (pip) price used in the system. want must not exceed 2%.
9.1.3.2A
¤¤¤
The want parameter is: 0.98
¤¤¤
9.1.3.3
Vow.bump: Minimum amount of DAI above Surplus Buffer Upper Limit required for eligible market transaction. bump is the amount of DAI used to get MKR. bump must be set in a way where a combination of price impact and transaction costs is minimized, depending on the analysis of network conditions which is provided by the Stability Scope Advisory Council and assumed outlook of mentioned factors.
9.1.3.3A
¤¤¤
The bump parameter is: 20,000
¤¤¤
9.1.3.4
Flappers.pip: A reference price oracle, used for bounding the exchange rate of the swap.
9.1.3.4A
¤¤¤
The pip parameter is:
0xdbBe5e9B1dAa91430cF0772fCEbe53F6c6f137DF
¤¤¤
9.1.3.5
Receiver: address which will receive the Univ2 MKR/DAI LP token.
9.1.3.5A
¤¤¤
The receiver parameter is:
MCD_PAUSE_PROXY: 0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB
¤¤¤
9.1.3.6: Parameter Reconfiguration Methodology & Frequency
The Stability Facilitators must update Smart Burn Engine Dss Flapper related parameters based on the analysis of cost optimization produced by the Advisory Council via first available executive vote. Since the cost optimization factors market impact and gas consumption related components which can be highly volatile, there is no strict condition for frequency. The Advisory Council must monitor the Smart Burn Engine and notify the Stability Facilitators that changes are needed with the corresponding analysis and proposed updated parameter configuration within the defined limits and boundaries.
9.1.3.7
The Smart Burn Engine and corresponding liquidity must be migrated to the New-Stablecoin/New-Governance-Token when this is technically available
10: SubDAO Economic Resilience Models
The Stability Facilitators and Stability Advisory Councils must develop adequate SubDAO Economic Resilience Models.
11: MKR Backstop
The MKR Backstop is temporarily limitless.
12: Dai Stablecoin Decentralization
AllocatorDAOs must be subsidized to ensure they have an incentive to allocate collateral to decentralized assets.
12.1: AllocatorDAO Decentralized Collateral Rebate
A Decentralized Collateral Rebate must be implemented if the Maker Community deems it necessary to protect the resilience of Dai.
13: Sagittarius Engine Dai Generation Risk Parameters
The Stability Facilitators must research how to set the adjustable risk parameters of the Sagittarius Engine Vaults.
14: Scope Bootstrapping
During the bootstrapping phase, the Stability Scope is modified to override the Atlas requirements in some places.
14.1: Yield Benchmarks
14.1.1
The Stability Collateral Yield Benchmark is contained in 14.1.1.1A and is approximately based on the average yield earned on all Cash Stablecoins. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant.
14.1.1.1A
¤¤¤
The Stability Collateral Benchmark Yield is:
2.09%
¤¤¤
14.1.2
The Yield Collateral Yield Benchmark is contained in 14.1.2.1A and is approximately based on the 3-month US Government Treasury Bill. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant.
14.1.2.1A
¤¤¤
The Yield Collateral Benchmark Yield is:
5.61%
¤¤¤
14.2: Protector Advisors
Before the AllocatorDAO Vault system is ready, Protector Advisors help advise the Stability Facilitators on deploying vaults and modifying risk parameters for Legal Recourse Assets in alignment with the spirit of the articles of the Stability Scope Artifact. The Stability Facilitators can trigger a weekly governance poll to onboard or offboard Protector Advisors. The active Protector Advisors are specified in 14.2.1A.
14.2.1A
¤¤¤
List of active Protector Advisors:
Spring
Viridian
¤¤¤
14.3: Native Vault Engine
The Native Vault Engine is controlled by Maker Core temporarily, and will be upgraded to support SubDAO ownership and transferred to the first AllocatorDAO incubated from the Incubator when NewChain launches. While it is under the control of Maker Core it will have a limited set of collateral types and risk parameters that the Stability Facilitators must implement according to the following subelements.
If not otherwise specified, The Stability Facilitators have the ability to trigger an executive vote to update any of the parameters defined in article “14.3.1: Native Vault Engine Parameter Definitions” for any of the Vault Types contained in article “14.3.2: Maker Core Vault Types”.
14.3.1: Native Vault Engine Parameter Definitions
14.3.1.1: Liquidation Ratio (LR)
The Liquidation Ratio parameter limits the maximum amount of DAI debt that a vault user can draw from their vault given the value of their collateral locked in that vault. In practice, it expresses the minimum collateral in percentage terms that can support a given DAI debt. If the ratio of a Vault user's collateral to their debt drops below this value their vault can be liquidated. Each vault type has its own Liquidation Ratio. The Liquidation Ratio for each vault type is expressed as a percentage value of the collateral that must be present in the vault to support its debt.
14.3.1.2: Debt Ceiling Limit
The Debt Ceiling Limit is numerically provided and acts as an upper limit. The Stability Facilitators can propose changes within this limit. Debt Ceiling Limit = Unlimited is defined as substantially large to not be reached in the near future. The DC-IAM methodology contained in 14.3.1.4 acts as a risk mitigation tool in case of an unexpected emergency that can limit the rate at which exposure can increase in a short period of time.
14.3.1.3: Stability Fee (SF)
The SF parameter is an annual percentage fee charged on the DAI generated on Vaults. It is expressed as an annual percentage yield but it is charged on a per-block basis in DAI. The DAI from this fee is minted, added to the DAI debt for the vault, and then transferred into the Surplus Buffer which is under the control of Maker Governance. Each vault type has its own Stability Fee that can be adjusted by the Stability Facilitators. The Stability Facilitators must regularly update Vault Type’s Stability Fee according to the following subelements. While Enhanced Dai Savings Rate (EDSR) is active, it replaces Dai Savings Rate (DSR) in the SF Formulas.
14.3.1.3A
¤¤¤
List of Stability Fee Formulas:
ETH-A:
Dai Savings Rate (EDSR while active) + 0.25%ETH-B:
Dai Savings Rate (EDSR while active) + 0.75%ETH-C:
Dai Savings Rate (EDSR while active)WSTETH-A:
Dai Savings Rate (EDSR while active) + 0.25%WSTETH-B:
Dai Savings Rate (EDSR while active)WBTC-A:
Yield Collateral Yield Benchmark + 0.25%WBTC-B:
Yield Collateral Yield Benchmark + 0.75%WBTC-C:
Yield Collateral Yield Benchmark
¤¤¤
14.3.1.4: Debt Ceiling Instant Access Module (DC-IAM)
The DC-IAM allows any user to adjust the Debt Ceiling of a supported vault type according to the rules defined in the DC-IAM smart contract logic and parameters set by the Stability Facilitators. The DC-IAM holds three parameters that can be set by Maker governance for each vault type, (i) Maximum Debt Ceiling (line), (ii) Target Available Debt (gap), and (iii) Ceiling Increase Cooldown (ttl).
14.3.1.4.1: Maximum Debt Ceiling (line)
The line parameter refers to the maximum value for the Debt Ceiling that the DC-IAM will allow in the given vault type. When using the DC-IAM to manage the Debt Ceiling of a vault type, the line parameter essentially replaces the Debt Ceiling parameter for that vault type. Rather than Maker governance setting the Debt Ceiling directly, they will need to set the Maximum Debt Ceiling (line) in the DC-IAM. The line parameter is defined in DAI.
The Maximum Debt Ceiling is defined in 14.3.1.2 and is currently unlimited.
14.3.1.4.2: Target Available Debt (gap)
The gap parameter controls how much of a gap the DC-IAM aims to maintain between the current debt usage and the Debt Ceiling of the vault type. The higher this value, the more risk there is from large collateral drops in very short amounts of time. The smaller this value, the more vault use is negatively affected. The gap parameter is defined in DAI.
14.3.1.4.3: Ceiling Increase Cooldown (ttl)
The Ceiling Increase Cooldown (ttl) parameter controls how frequently the Debt Ceiling can be increased by the DC-IAM. If a user attempts to use the DC-IAM to increase the Debt Ceiling of a vault type before this time expires, the transaction will fail to execute and the Debt Ceiling will remain unchanged. The ttl parameter in combination with the gap parameter enforces a maximum rate at which debt usage can increase over time using a given vault type. These parameters should be set such that the maximum increase over time can accommodate all reasonable usage of the vault type in question. The ttl parameter is defined in seconds.
14.3.1.5: Auction Parameters
A clear justification and analysis to determine the validity of the changes must be provided in the case of a proposed change to the parameters contained in article “14.3.1.5: Auction Parameters”. In addition, the Stability Facilitators must first propose a governance poll before adding the proposed parameter changes to an executive vote. However, in the case of an emergency, the Stability Facilitators are granted the ability to add these parameters to an executive vote directly. The parameters contained herein must be regularly monitored and updated if needed.
14.3.1.5.1: Auction Price Function (calc)
The Auction Price Function is the mathematical function that determines how the collateral price changes over time during a collateral auction. Collateral auctions use a falling price auction, where the price starts high and decreases according to the function defined in this parameter. The Exponential Stair Step function contains two key parameters, cut and step, defined in article “14.3.1.5.1: Cut” and “14.3.1.5.2: Step” respectively.
14.3.1.5.1.1: cut
The cut parameter controls the ‘depth’ of each step in the function. A smaller cut means a smoother line, a large one means more pronounced steps. The cut parameter is defined as a multiplicative factor. For example, 0.99 equated to a 1% price drop.
14.3.1.5.1.2: step
The step parameter controls the length of time between price drops. A smaller step means a smoother line, a large one means more pronounced steps. The step parameter is defined in seconds.
14.3.1.5.2: Auction Price Multiplier (buf)
The buf parameter is a multiplier that is applied to the starting price of a collateral auction. Each vault type has its own Auction Price Multiplier that can be adjusted by Maker governance separately. This multiplier is intended to be greater than 1.0x because Liquidations 2.0 uses falling price auctions. This means that it is generally preferable for the auction price to begin above the market price and then fall to the correct value over some amount of time. The buf parameter is defined as a multiplicative factor.
14.3.1.5.3: Max Auction Drawdown (cusp)
The Max Auction Drawdown is the maximum percentage drop in collateral price during a collateral auction before the auction is reset. 'Collateral price' in this context refers to the collateral auction price rather than the collateral market price.
The Max Auction Drawdown parameter overlaps with the Max Auction Duration parameter in that an auction will need to be reset once either maximum is exceeded.
14.3.1.5.4: Max Auction Duration (tail)
The Max Auction Duration parameter sets the maximum time that can elapse before an auction needs to reset for a particular vault type. Expressed in seconds, this parameter determines when an auction can no longer settle and must be reset. The Max Auction Duration parameter overlaps with the Max Auction Drawdown parameter in that an auction will need to be reset once either maximum is exceeded.
14.3.1.5.5: Proportional Kick Incentive (chip)
The Proportional Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. The Proportional Kick Incentive is set as a percentage and represents a portion of DAI based on the debt of the vault that is being liquidated. The DAI is rewarded for each liquidation auction at the point the auction is triggered. Each vault type has its own Proportional Kick Incentive that may be adjusted separately by Maker Governance.
14.3.1.5.6: Flat Kick Incentive (tip)
The Flat Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. The Flat Kick Incentive is a fixed amount of DAI that is rewarded for each liquidation auction at the point the auction is triggered. Each vault type has its own Flat Kick Incentive that may be adjusted separately by Maker Governance.
14.3.1.5.7: Liquidation Penalty (chop)
The Liquidation Penalty parameter controls the fee vault owners must pay when their position is liquidated due to insufficient collateral. For a vault holder to receive any collateral back from the liquidations process, the debt and Liquidation Penalty must be covered by the collateral auction. Each vault type has its own Liquidation Penalty that can be adjusted by Maker Governance.
14.3.1.5.8: Local Liquidation Limit (hole)
The Local Liquidation Limit sets the maximum amount of DAI debt for which collateral auctions can be active at any one time within a particular vault type. When the total DAI value of auctions exceeds this maximum for a particular vault type, no more collateral can be auctioned using that vault type until others are completed. Each vault type has a separate Local Liquidation Limit.
14.3.1.6: Debt Floor (dust)
The Debt Floor parameter controls the minimum amount of DAI that can be minted using a specific vault type for an individual vault. If a user tries to mint DAI and the amount of DAI minted would not put the vault's amount of DAI minted above its Debt Floor, the transaction will fail and no DAI will be minted. Likewise, if a user attempts to pay back debt such that their debt will equal less than the Debt Floor and greater than zero, the transaction will fail and no DAI will be paid back. Each vault type has its own Debt Floor that can be adjusted by Maker Governance.
14.3.2: Maker Core Vault Types
14.3.2.1: ETH-A
¤¤¤
Current ETH-A parameters are:
Stability Fee: 5.25%
Liquidation Ratio: 145%
DC-IAM
line: 15,000,000,000DC-IAM
gap: 150,000,000DC-IAM
ttl: 21,600 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 40,000,000dust: 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,000DC-IAM
gap: 20,000,000DC-IAM
ttl: 21,600 secondscut: 99.00%step: 60 secondsbuf: 110.00%cusp: 45.00%tail: 4,800 secondschip: 0.10%tip: 250chop: 13%hole: 15,000,000dust: 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,000DC-IAM
gap: 100,000,000DC-IAM
ttl: 28,800 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 35,000,000dust: 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,000DC-IAM
gap: 30,000,000DC-IAM
ttl: 43,200 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 15,000,000dust: 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,000DC-IAM
gap: 45,000,000DC-IAM
ttl: 43,200 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 10,000,000dust: 3,500
¤¤¤
14.3.2.6: WBTC-A
¤¤¤
Current WBTC-A parameters are:
Stability Fee: 5.86%
Liquidation Ratio: 145%
DC-IAM
line: 500,000,000DC-IAM
gap: 2,000,000DC-IAM
ttl: 86,400 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 30,000,000dust: 7,500
¤¤¤
14.3.2.7: WBTC-B
¤¤¤
Current WBTC-B parameters are:
Stability Fee: 6.36%
Liquidation Ratio: 130%
DC-IAM
line: 250,000,000DC-IAM
gap: 2,000,000DC-IAM
ttl: 86,400 secondscut: 99.00%step: 60 secondsbuf: 110.00%cusp: 45.00%tail: 4,800 secchip: 0.10%tip: 250chop: 13%hole: 10,000,000dust: 25,000
¤¤¤
14.3.2.8: WBTC-C
¤¤¤
Current WBTC-C parameters are:
Stability Fee: 5.61%
Liquidation Ratio: 175%
DC-IAM
line: 500,000,000DC-IAM
gap: 2,000,000DC-IAM
ttl: 86,400 secondscut: 99.00%step: 90 secondsbuf: 110.00%cusp: 45.00%tail: 7,200 secondschip: 0.10%tip: 250chop: 13%hole: 20,000,000dust: 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.
Last updated