MIP17: Weekly Actual Debt Ceiling and Actual Risk Premium Adjustments

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%)

Correct. Note that MIP17 may be reintroduced to the community for another vote once the Authors work with the community to resolve the issues that resulted in its initial rejection.

1 Like

What if instead of linking debt ceiling raises to risk premiums, we just introduced a module that automatically raised debt ceilings toward a target as a percent of total dai? We would still vote to set risk premiums, but these shouldn’t change as frequently as the debt ceiling.

I think this risk premium curve thing was too complicated and there’s too many unanswered question about how steep it should be. But we should ask ourselves: what are the real risks of raising the debt ceiling? In the case of eth, there should be basically no limit, except we want to have the debt ceiling not be higher than 10-20% above utilization.

In the case of usdc and wbtc, and other collateral types we add, we may want some cap. No more than 20% total dai supply comes from usdc, etc. And probably also it should not exceed some percent of the market cap of the collateral (say 50%, which we’ve run into several times with wbtc).

This kind of proposal seems better as a first step because it tries to solve 1 problem, and doesn’t get tangled up with questions around the risk premium on top of that.

8 Likes

I agree with this line of thinking. I really hope revisions can get made ASAP because with DeFi booming and debt ceilings being hit every couple days we really need a faster way to increase DAI supply.

2 Likes

I agree. I think many people would be in favour of automatic debt ceiling increases. Bundling it with Risk Premiums is a much larger question.

2 Likes

I see that many DEFI platforms have implemented automatic adjustment of DC and PR. I don’t know why MIP17 failed, is it a parameter adjustment problem, or what else?

we don’t currently have a way of knowing why mkr holders voted against it besides what people discuss on this forum. And many mkr holders are not active forum members, so we can mostly just speculate.

1 Like

Whats the status of this MIP? Are revisions taking place? RFC? Will it be reintroduced? We need this type of implementation yesterday.

I’m going to host a MIP17 working group call next Tuesday to discuss how we can improve/modify the proposal to meet Maker’s needs. For example, we could consider modifying MIP17 to simply begin with only doing DC adjustments and not RPs using the Weekly Governance Cycle. I will be sharing that information in a forum post and in the #mips channel.

6 Likes

I see that other mainstream DEFI platforms have realized automatic adjustment of DC and RP. We should accelerate the progress of MIP17, which can prevent people from interfering with regulating RP and DC for their own interests.

One drawback of this MIP is it becomes possible for short term spikes in utilization to negatively impact long term vault users. Ideally only those using liquidity above the target debt ceiling would pay extra to compensate Maker for the added risk.

This could potentially be accomplished through variable origination fees for debt taken out above a collateral type’s target debt ceiling. Each unit of DAI debt incurred in excess of the target debt ceiling would release a progressively smaller amount of DAI erc20 to the borrower until reaching a hard limit (~actual debt ceiling) where no more DAI can be borrowed.

eg.
origination fee rate (TDC utilization) = 0.1 * (TDC utilization - 100%)
origination fee rate (100%) = 0%
origination fee rate (110%) = 1%

TDC = 100 million DAI
current debt level = 100 million DAI
new borrow = 1 million DAI
DAI erc20 received = 999,500 DAI (0.05% fee)

TDC = 100 million DAI
current debt level = 109 million DAI
new borrow = 1 million DAI
DAI erc20 received = 990,500 DAI (0.95% fee)

6 Likes

@monet-supply Very interesting idea of using direct fees to scale DC room and allow for spikes in capacity.

Some things to note. A 1% origination fee is quite high, especially if it’s just a short term spike. Can result in quite a high APR. Can be bad optics if it’s not conveyed clearly.

10% isn’t a lot of DC room for smaller caps. And one of the goals is for more scaling on the smaller caps.

On the other hand this will add more OSM risk for ETH-A. Which might not be that big of a problem since you still get the origination fees and you have the actual debt ceiling limit.

MIP17 working group call is happening tomorrow (Tuesday) at 12 pm EDT / 4:00 p.m UTC to discuss our options going forward. For all that are interested, check out the details in this forum post.

Our smart contract cannot automatically adjust the DC and risk premium. For me, its performance lags behind other DEFI platforms (AAVE). In the current situation of frequent manual adjustment of DC and risk premium, the priority deployment of MIP17 becomes more important.

2 Likes

I really don’t think you should be comparing ourselves to AAVE. We don’t need to adjust our risk premium like that. WIth AAVE, they recently had a DAI liquidity crisis and cranked up interest rates to 25-50%.

That sounds working as intended to me…

1 Like