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.
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?
compensation for risk in the system?
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"
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.
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.
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.
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.
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.
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%.