MIP104: Stability Scope

1: Scope Improvement

1.1: The Stability Advisory Council

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

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 a the weekly governance process, or directly through executive votes, by the Stability Facilitators.

3.2.1A

¤¤¤

The Dai Savings Rate is:

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

  • Monetalis

  • Blocktower

¤¤¤

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.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: 0

¤¤¤

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.2.1.3.1A or a technically secure DeFi token that can be instantly converted to a listed stablecoin, or a custody solution that can be converted into a listed stablecoin within 30 minutes. The Stability Facilitators can modify 7.2.1.3.1A through the weekly cycle to react to changing market conditions, opportunities or risks. This can include adding or removing Cash Stablecoins, or changing the terms of existing Cash Stablecoins on the list.

7.1.2: List of Cash Stablecoins

¤¤¤

List of Cash Stablecoins:

  • USDC and USDC in Coinbase Custody

¤¤¤

7.2.1.3.2: Cash Stablecoin Peg Stability Module Upgrades

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

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

Clydesdale and andromeda are two RWA Arranged Structures that can allocate capital into Low-Risk RWA (LRR), 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 split equally among the two RWA Arranged Structures. As as a result, the two RWA Arranged Structures should generally always track the same amount of exposure into LRR, although short term discrepancies for operational reasons are acceptable.

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:

11,826

¤¤¤

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: 75,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.

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: 13.25%

  • Liquidation Ratio: 145%

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

  • DC-IAM gap: 150,000,000

  • DC-IAM ttl: 21,600 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 40,000,000

  • dust: 7,500

¤¤¤

14.3.2.2: ETH-B

¤¤¤

Current ETH-B parameters are:

  • Stability Fee: 13.75%

  • Liquidation Ratio: 130%

  • DC-IAM line: 250,000,000

  • DC-IAM gap: 20,000,000

  • DC-IAM ttl: 21,600 seconds

  • cut: 99.00%

  • step: 60 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 4,800 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 15,000,000

  • dust: 25,000

¤¤¤

14.3.2.3: ETH-C

¤¤¤

Current ETH-C parameters are:

  • Stability Fee: 13.00%

  • Liquidation Ratio: 170%

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

  • DC-IAM gap: 100,000,000

  • DC-IAM ttl: 28,800 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 35,000,000

  • dust: 3,500

¤¤¤

14.3.2.4: WSTETH-A

¤¤¤

Current WSTETH-A parameters are:

  • Stability Fee: 14.25%

  • Liquidation Ratio: 150%

  • DC-IAM line: 750,000,000

  • DC-IAM gap: 30,000,000

  • DC-IAM ttl: 43,200 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 30,000,000

  • dust: 7,500

¤¤¤

14.3.2.5: WSTETH-B

¤¤¤

Current WSTETH-B parameters are:

  • Stability Fee: 14.00%

  • Liquidation Ratio: 175%

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

  • DC-IAM gap: 45,000,000

  • DC-IAM ttl: 43,200 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 20,000,000

  • dust: 3,500

¤¤¤

14.3.2.6: WBTC-A

¤¤¤

Current WBTC-A parameters are:

  • Stability Fee: 14.75%

  • Liquidation Ratio: 145%

  • DC-IAM line: 500,000,000

  • DC-IAM gap: 4,000,000

  • DC-IAM ttl: 86,400 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 10,000,000

  • dust: 7,500

¤¤¤

14.3.2.7: WBTC-B

¤¤¤

Current WBTC-B parameters are:

  • Stability Fee: 15.25%

  • Liquidation Ratio: 130%

  • DC-IAM line: 250,000,000

  • DC-IAM gap: 2,000,000

  • DC-IAM ttl: 86,400 seconds

  • cut: 99.00%

  • step: 60 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 4,800 sec

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 5,000,000

  • dust: 25,000

¤¤¤

14.3.2.8: WBTC-C

¤¤¤

Current WBTC-C parameters are:

  • Stability Fee: 14.50%

  • Liquidation Ratio: 175%

  • DC-IAM line: 500,000,000

  • DC-IAM gap: 8,000,000

  • DC-IAM ttl: 86,400 seconds

  • cut: 99.00%

  • step: 90 seconds

  • buf: 110.00%

  • cusp: 45.00%

  • tail: 7,200 seconds

  • chip: 0.10%

  • tip: 250

  • chop: 13%

  • hole: 10,000,000

  • dust: 3,500

¤¤¤

14.3.3

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

14.3.4

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

14.3.5

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

Last updated