MIP17: Weekly Actual Debt Ceiling and Actual Risk Premium Adjustments

MIP17: Weekly Actual Debt Ceiling and Actual Risk Premium Adjustments

Preamble

MIP#:17
Title: Weekly Actual Debt Ceiling and Actual Risk Premium Adjustments
Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL)
Contributors:
Type: Process
Status: Formal Submission (FS)
Date Proposed: 2020-07-02
Date Ratified: <yyyy-mm-dd>
Dependencies:
Replaces:

References

Sentence Summary

MIP17 defines a process and solution for enabling weekly Debt Ceiling and utilization based Actual Risk Premium adjustments.

Paragraph Summary

This proposal defines and formalizes a solution using the Weekly Governance Cycle (MIP16) for making weekly Actual Debt Ceiling and Actual Risk Premium Adjustments. Additionally, the proposal describes how to propose modifications to the actual calculation logic behind the debt ceiling and risk premium adjustments.

Component Summary

MIP17c1: Definitions
Defines key terms related to the Weekly Actual Debt Ceiling and Actual Risk Premium Adjustments.

MIP17c2: Actual Debt Ceiling Adjustments
Defines the calculation logic on how to modify the Actual Debt Ceiling securely.

MIP17c3: Actual Debt Ceiling Adjustments Calculation Logic Modification Process
Defines the process for altering the calculation logic for the Actual Debt Ceiling.

MIP17c4: Actual Risk Premium Adjustments
Defines the calculation logic on how to modify the Actual Risk Premium securely.

MIP17c5: Actual Risk Premium Adjustments Calculation Logic Modification Process
Defines the process for altering the calculation logic for the Actual Risk Premium.

Motivation

The purpose of this MIP is to introduce an initial version of secure Actual Debt Ceiling adjustments and Actual Risk Premium curves. The Actual Risk Premium curves improve the Maker Governance system to more effectively and dynamically adjust Debt Ceilings and Risk Premiums to better match user patterns.

Specification / Proposal Details

MIP17c1: Definitions

  • Risk Parameters: Each type of collateral added to the Maker Protocol is associated with its own set of risk parameters, influenced by the collateral token’s financial and technical characteristics. Risk parameters are calculated by a Risk Domain Team, typically using the collateral type’s information provided by the collateral proposer (via a MIP6 application).
  • Actual Debt Ceiling: The Actual Debt Ceiling is the current Debt Ceiling set in the Maker Protocol. Note this is different from the Target Debt Ceiling and current existing system Debt.
  • Target Debt Ceiling: This is a risk parameter that is set by MIP12 subproposals, which regulates the adjustment of the Actual Debt Ceiling and the Actual Risk Premium in the Weekly Governance Cycle (MIP16).
  • Current Debt: The current outstanding Debt in the Maker Protocol (this is not the same as the Debt Ceiling).
  • Actual Risk Premium: The Actual Risk Premium is the Maker Protocol’s current Risk Premium. It is adjusted based on the utilization of the collateral type and used to calculate the Stability Fees in the Maker Protocol. The Actual Risk Premium is the value that is added to the Base Rate to get the Stability Fee value.
  • Target Risk Premium: A risk parameter set by MIP12 subproposals which regulates the Actual Risk Premium’s adjustment.
  • Actual Debt Ceiling Adjustment: An adjustment process to securely modify the Actual Debt Ceiling so that it minimizes the system’s attack surface while still enabling growth and not frustrating users.
  • Actual Risk Premium Adjustment: The Actual Risk Premium calculation is based on the Target Debt Ceiling utilization.

MIP17c2: Actual Debt Ceiling Adjustments

The Actual Debt Ceiling Adjustment calculation logic is used to securely manage the free Debt Ceilings of collateral assets in the Protocol, except for those onboarded as non-standard assets (such as USDC-B). The adjustment process uses a parameter called the Target Debt Ceiling and introduces a weekly cadence for making changes to the Actual Debt Ceiling. When the calculation logic outputs an adjustment value of the Actual Debt Ceiling for one or more Collateral types, the changes are put up in a single (bundled) Weekly Cycle Poll on the Monday of the weekly cycle. Note that the Actual Debt Ceiling Adjustment will be calculated and proposed by a mandated governance domain actor. If the weekly poll passes successfully, the poll contents will be put up in an Executive Vote on the Friday of the same weekly cycle, according to the processes defined in MIP16. The Actual Debt Ceiling Adjustment calculation logic is further explained below.

Calculation Logic

Values are based on the protocol state Monday at 8 am UTC.

If the Actual Debt Ceiling minus the Current Debt fulfills any one of the following conditions:

  • For collateral types with more than 20 million Target Debt Ceiling:

    1. Less than, or equal to, 10% of the Target Debt Ceiling or,
    2. More than, or equal to, 16% of the Target Debt Ceiling

If one of the conditions are met, the new Actual Debt Ceiling is calculated as Current Debt Ceiling + 15%

  • For collateral types with less than 20 million Target Debt Ceiling (Inclusive):

    1. Less than, or equal to, 2 million
    2. More than, or equal to, 3.2 million

If one of the conditions are met, the new Actual Debt Ceiling is calculated as Current Debt Ceiling +15%

Notes:

  • The Actual Debt Ceiling can surpass the Target Debt Ceiling.
  • The Actual Debt Ceiling Adjustment calculation logic may be modified by using the subproposal process defined in MIP17c3: Actual Debt Ceiling Modification Process.

Example Scenarios

  • Example 1: A collateral type has a Target Debt Ceiling of 150 million, an Actual Debt Ceiling of 80 million, and a current debt of 75 million. The next weekly poll would then propose to adjust the Actual Debt Ceiling to 97.5 million.
  • Example 2: A collateral type has a target debt ceiling of 200 million, an actual debt ceiling of 100 million, and the current debt of 65 million. The next weekly poll would then adjust the Actual Debt Ceiling to 95 million.

MIP17c3: Actual Debt Ceiling Adjustments Calculation Logic Modification Process

The modification process for the Actual Debt Ceiling adjustment calculation is completed by using a subproposal, in which MIP17c3 subproposals are submitted to the Monthly Governance Cycle like any other proposal.

MIP17c3 subproposals have the following parameters:

  • Default Feedback Period: 3 months
  • Frozen Period: 1 month

MIP17c3 subproposals must use the template located at MIP17c3-Subproposal-Template.md. This template is considered ratified once this MIP moves to Accepted status.


MIP17c4: Actual Risk Premium Adjustments

Actual Risk Premium is the Risk Premium used to calculate the Stability Fee of collateral assets in the Maker protocol. It is calculated as a function of the Actual Debt Ceiling, the Target Debt Ceiling, and the Target Risk Premium. Any time there is a proposal to adjust the Actual Debt Ceiling of one or more collateral types, there will also be corresponding adjustments to the Actual Risk Premium of those collateral types. The Actual Risk Premium Adjustments will be calculated and then proposed in a Weekly Poll by a mandated governance domain actor. If the Weekly Poll passes, then the adjustments will be put up in an Executive Vote on the Friday of the week to determine if it should be officially implemented to the Maker Protocol.

Glossary of Terms:

  • ARP = Actual Risk Premium
  • TRP = Target Risk Premium
  • ADC = Actual Debt Ceiling
  • TDC = Target Debt Ceiling

The new Actual Risk Premium is calculated using the following formula:

  • Formula: ARP = TRP*2^(2*((ADC-TDC)/TDC))

ARP Formula Examples

Example 1:

  • TRP = 5%
  • ADC = 3000000
  • TDC = 2000000
  • Calculation: 10% = 5% * 2^(2*((3000000-2000000)/2000000))
  • Curve Output:

Example 2:

  • TRP = 5%
  • ADC = 40000000
  • TDC = 20000000
  • Calculation: 20% = 5% * 2^(2*((4000000-2000000)/2000000))
  • Curve Output:

Example 3:

  • TRP = 7.5%
  • ADC = 6000000
  • TDC = 3000000
  • Calculation: 30% = 7.5% * 2^(2*((6000000-3000000)/3000000))
  • Curve Output:

Example 4:

  • TRP = 10%
  • ADC = 13456034
  • TDC = 10000000
  • Calculation: 16.15% = 10% * 2^(2*((13456034-10000000)/10000000))
  • Curve Output:

Example 5:

  • TRP = 0.75%
  • ADC = 19148224.3
  • TDC = 12000000
  • Calculation: 1.71% = 0.75% * 2^(2*((19148224.3-12000000)/12000000))
  • Curve Output:

Example 6:

  • TRP = 5%
  • ADC = 1000000
  • TDC = 15000000
  • Calculation: 1.37% = 5% * 2^(2((1000000-15000000)/15000000))
  • Curve Output:

Notes:

  • Values are based on the Maker Protocol’s state each Monday at 8 am UTC.
  • ARP output is rounded to the nearest two decimals.

MIP17c5: Actual Risk Premium Calculation Logic Modification Process

MIP17c5 is a Process MIP component that allows community members and domain teams to modify the Actual Risk Premium calculation logic (formula).

MIP17c5 subproposals have the following parameters:

  • Default Feedback Period: 3 months
  • Frozen Period: 1 month

MIP17c5 subproposals must use the template located at MIP17c5-Subproposal-Template.md. This template is considered ratified once this MIP moves to Accepted status.


MIP17 source in the MIPs Github Repository: https://github.com/makerdao/mips/tree/RFC/MIP17

10 Likes

I’m super excited about this proposal! Should definitely help Maker roll with the punches.

My only concern is that snapshots at a know time could be vulnerable to manipulation. That being said, a manipulated value could be voted down by governance, so this setup seems pretty safe overall.

2 Likes

As always, great work Charles. Your hard work and dedication is super appreciated by the community.

Question? What would happen if there’s an emergency Debt Ceiling Adjustment needed, say mid-week? Can you override and not have to wait till Monday at 8AM UTC?

Also, would it be possible to run the Adjustments on a Testnet, and pay a bounty to anyone who can manipulate such? Maybe I’m asking for too much–but just wondering if it’s possible.

4 Likes

Very beautiful proposal, which is very important for the future development of the MAKER community. Thank you.

1 Like

I must admit I could not find this definition anywhere in either MIP12 or the proposed MIP16. Link?

1 Like

You used “Utilization Based” in the Paragraph Summary, then “Actual” in the Component Summary, then “Debt Ceiling based” in the Motivation? Maybe consider picking one term and sticking with it for clarity, cause I’m already confused.

Why is this the number chosen for the Calculation Logic? I know that it will, at this stage, be somewhat arbitrary and can always be updated, but I would be interested to hear the thinking around this specific choice? Same thing goes for the formula used to calculate the ARP, as beautiful as those curves may be.

Also agree with Planet_X that the TDC is not immediately obvious to find in MIP12 SPs.

3 Likes

I think it’s an improvement over what we have but I think the concept of the DC is obsolete and unnecessary except in some edge cases. There is no clear explanation how anyone could profit and harm other DAI users with taking advantage of a low/high DC in decentralized coins (ETH, BAT). There were plenty of opportunities for manipulation in the past when the DC was much higher than the used collateral or when it was reached.

1 Like

I believe this should read as:

The Actual Risk Premium is the value that is added to the Base Rate to get the Stability Fee value.

1 Like

I had some thoughts about using an exponential curve for the risk premium. I believe I understand the intuition for wanting to use an exponential as it will rapidly prevent the debt ceilings from rising beyond what we are comfortable with. I agree with this tactic in general, but am concerned that an exponential may quickly reach rates that are very high, very quick in a situation like what has been happening now with COMP yield farming.

Currently we are rapidly raising the debt ceilings to meet this exploding demand, but the new demand is unique in that it is not generating any downward force on the peg. If we were to have a target debt ceiling on ETH-A of 100M at 2% target risk premium we would quickly move into the double digits even at the current levels of debt. This would almost certainly exacerbate the upward motion on the peg as ETH leverage seekers start repaying their loans.

Now we could also use the Base Rate to counteract this effect by voting in a more negative value to keep the Stability Fee ~0%, but due to the exponential nature of the ETH-A RP increase and the max -4% adjustment in the Base Rate, the ETH-A RP would quickly become dominant. I understand we could vote in new target parameters for ETH-A, but doesn’t that kind of defeat the purpose of a sliding scale in the first place?

All in all I think it’s a good idea, but I think it may be worthwhile to look at something like a quadratic function for slope which is far less intense than an exponential, but can still curb supply growth if we go beyond the target parameters. Alternatively we could reduce the multiplicative factor in the exponential as well. Reducing it to 1 or 1/2 or something.

2 Likes

Is this meant to be current outstanding debt per collateral type?

Again, the Risk Premium on a particular collateral type?

On a particular collateral package.

Definitions here are kind of weird next to each other. One describes a process, the other goes talks about a calculation.

This might be a mistake down the line if we add more than one ‘primary’ package for a single asset.

This presumably means the Governance Facilitators? But it’s somewhat confusing because there isn’t officially a ‘governance domain.’ There are domain actors, and there are the core roles (Facilitator and MIP Editor)

Does ‘Current Debt Ceiling’ here refer to the Current Actual Debt Ceiling, or the Current Target Debt Ceiling? From the examples this appears to mean Current Target Debt Ceiling? But I would have assumed otherwise without the examples.

Is this the same weekly poll as the debt ceiling adjustments? Or two separate bundles?

Is this Monday the previous week? Or 8 Hours before the weekly poll goes live? It’s not so bad for me because I’m UTC based, for Rich or you (not sure if MIP Editor counts as governance domain because there is no definition of the governance domain) it will be more of an issue.

2 Likes

I’d like to add that the Exponential Risk Premium Adjustments sounds chaotic. Very easy to overshoot.

Not only do you now have more DAI created from a vault (that’s why you’re increasing DC), you would then overshoot on the RP, and now you have a big DAI supply drop.

That’s one benefit from Maker Vaults over secondary lenders. They’re constrained by liquidity which can spike rates. Maker as a primary lender, I think we can offer a bit more interest rate stability. I think that’s important, good for optics too.

We’re not Compound or AAVE, we don’t need to put that much pressure on lenders by jacking up the RP.

7 Likes

Am I understanding correctly that the target debt ceilings for each collateral type are just fixed numbers and not at all related to total maker debt? It seems like this should be a percent of total debt, since the thing that makes an asset more risky is being overweighted relative to other assets.

Also, if we don’t use a percent of total debt then this process doesn’t actually reduce the number of votes needing to be cast, and so has approximately the same governance load. We are likely to have to adjust the target debt ceiling regularly in order to keep a reasonable risk premium. In fact most of the time when a debt ceiling adjusts upward due to high demand for a collateral type I would expect the debt to remain above that level long term.

I also agree that the exponential risk premium adjustment is too steep.

6 Likes

Is it clear that adjustment of risk premium on a collateral type based on debt ceiling utilisation is a good idea? It adds extra rate risk to borrowers (since now to estimate their financing costs they need to try to anticipate not only changes in risk premium and DAI monetary policy but also the utilisation of their collateral type!), and also might create really weird dynamics like CDP users trying to squeeze eachother out by playing a game of chicken for who refinances first… It also undermines the concept of “risk premium”, which is meant to be assessed as compensation to the system for the risk that it takes on with a given collateral type.

It’s tempting to introduce “mechanisms” everywhere to coax people with incentives but the reality is that most mechanisms in the real world are inscrutable and chaotic, meaning that often they aren’t worth the uncertainty they introduce (in the context of Maker it’s fair to say that uncertainty is almost always bad).

7 Likes

You may be right that this is over-engineering a solution for a problem that is not well defined yet. With regards to the risk though, this could be seen as compensating MKR holders for over-exposure to an asset which does increase risk to the protocol as a whole. I see two main components to risk:

  1. The individual collateral risk. Basically how much bad debt we expect to be incurred per year during normal operation. This should be relatively constant.
  2. The risk due to over-exposure to an asset. This will be dependant on the relative size of the Dai debt from the particular asset compared to overall Dai debt. This target risk / target debt ceiling setup addresses this portion of the risk in my mind.

Alternatively for #2 we can just stick with hard debt ceilings to enforce the second point, but I think I personally prefer having a softer barrier with scaled compensation.

Could this choice be opt-in on a per-CDP basis?

Are you suggesting the Risk Premium be set in proportion to the debt a vault has taken out? Likely possible with a smart contract change. I guess this would grandfather in old vaults and solve some of the problems @equivrel mentioned.

My view is this sort of change is unwarranted at this stage as it requires a smart contract modification, and it’s not clear whether Risk Premium volatility is a major concern.

1 Like

Not exactly. I was thinking more along the lines of offering multiple CDP types ETH-A, ETH-B, ETH-C etc with gradually increasing risk premiums.

I’m not sure if this is a great idea. Just putting it out there.

3 Likes

Ah I see what you’re saying. Yeah that seems like a valid alternative to me.

1 Like

I was taking a look at some of the examples and it looks like the exponential factor is related to the target DC and actual DC. I think the issue here is that the formula gets pretty extreme in terms of the exponential utilization factor if the actual DC is much larger than the actual DC. I see about a factor of 8 in example 2, and factor of 4 from low to target and target to high in example 1. Example 3 pretty much has very little change.

What I don’t see in those charts is the axis labels and marks for the target DC and actual DC since the charts themselves appear to extend beyond the actual allowed DC ranges. This IS close to the proposal I made regarding SF in relation to debt facility usage though so I like it conceptually. The problem here is that we will be doing this ‘management’ manually vs. code so it really isn’t going to act the way I wanted because it will always be delayed. Literally the markets will not be able to optimize the DC usage against rate.

Also as in my proposal adjusting the target DC automatically adjusts rate - over the entire curve. So just pay attention to that. I think the whole fact this is not just coded in to the rate calculations directly means as Jiecut said:

It will overshoot both ways and probably be very unstable if used not as a software update but a governance manual process.

I honestly think we are back to this whole discussion about general rate vs. risk premium. I really want to hear @cyrus on this. Should the risk premium be related to DC or should the stability fee be? I always felt the risk premium was just based on the quality of the assets. I suggested the idea of a facility SF based on utilization because it would allow the participants of the system to drive rates based on utilization at both ends of the DC utilizatio curve (SF going down if utilization was low or up if it was high relative to WHATEVER DC was). The whole point of using a facility usage based SF was via a smart contract based code implementation was that governance should only need to change either the DC or the SF target rate to manage system liquidity and do it LESS often - not MORE often and with greater complication.

I come back to a general question. What problem does this proposal seek to solve?

  1. compensation for risk in the system?
  2. Or ?

Without knowing the problem one is trying to solve I am having a hard time seeing how the application of this is going to help governance here. Also the results of the formula basically vary depending on actual DC and target DC differences as dramatically seen between the examples.

Back to same question. What problem is MIP17 being proposed to solve?

So I looked back:

Sure we probably want to discuss an ‘initial version’. The claim in the motivation above that “Actual Risk Premium curves improve the Maker Governance system…” This does NOT dynamically adjust DC and Risk Premiums - what it does is have governance manually adjust them and what I want to know is how we are going to measure whether doing the above, in a manual way through governance, will 'better match user patterns"

1 Like

The MIP17 Governance Inclusion Poll has failed to pass.

Yes 971.42 MKR (4.30%)

No 21,606.88 MKR (95.70%)