MIP17 Working Group Call Summary (Next Steps)

MIP17 Working Group Community Call Summary & Action Items

Background Information

MIP17 was initially rejected from July’s Governance Cycle due to both the solution’s timing and the lack of consensus towards it being the clear path forward for Debt Ceiling and Risk Premium Adjustments. Given that we have been facing a lot of Debt Ceiling problems over the past few weeks, there has been a lot recent of discussion about how to improve/modify the proposal to meet Maker’s needs. The goal of this community call was to discuss our options and prepare a revised proposal for resubmission in August’s Governance Cycle.

Working Group Call Summary Notes

Where do we start with the modification?

Start with modifying MIP17 to cover simple Debt Ceiling Adjustments and create another MIP for Risk Premium Adjustments for later consideration / a future Governance Cycle.

General Comments about how to improve MIP17

The proposal lacked motivation for both how we do things currently and how this suggests how we change it. The new proposals will need to explain why we don’t immediately set the Debt Ceiling to the maximum for each collateral type. It is essential to consider the OSM delays/Oracle attacks and generally, where the Debt Ceiling can get abused.

Risk Premium Adjustment Considerations

  • Why do we need to make dynamic Risk Premium adjustments?

    • The new proposal will need a compelling case - motivation, and requirements.
  • Look at the history of Stability fees on a curve, with multiple collateral types with higher stability fees, and greater collateralization ratios.

  • It’s a significant disruption if we do it to the ETH-A types rather than setting it for new collateral types like ETH-B - this way, it’s better and less disruptive for existing users .

  • Risk Premium is supposed to represent the risk premium to the Protocol.

    • The new mechanism changes the current way parameters are done in the system today, which will need excellent communication.
  • The Base rate adjustments now refer to reference as the most significant source of risk, but it was gradually introduced to the community.

  • This proposal adds a new way that affects users - as it departs from the current assumptions - don’t expect the Risk Premium unless the risk parameters of the underlying collateral asset changes.

  • The Risk Premium has two components that we need to consider:

    • Collateral specific component - what we expect in terms of volatility and bad debt rate.
    • Exposure of the collateral type component - what is affected by the adjustment formula and overexposure that should be adjusted based on target debt ceilings.
  • Enabling Risk Premium adjustments for only new collateral types would make sense, especially for partners or businesses using the Protocol.

    • One example is Nexos and wBTC:
      • Users typically Arbitrage on rates they offer with their clients, and they use a vault and the fees to make a profit.
  • If you change the Actual Risk Premium for a collateral type, you would hit a point where a large portion of existing vault holders would be priced out, and they would close out their vaults - so this increases the chances of that.

    • Solution:
      • Continue to use Risk Premium as a stable way unless something changes with the collateral type. If Maker doesn’t want more exposure - creating a new collateral type reflecting the new risks with adding more of that collateral reflected in a higher Risk Premium
      • This way, it doesn’t affect the existing vault holders.
  • ETH-A example: Risk Premium could still be changed for the ETH-A through reg governance cycles but not automated.

    • This type of method would also be useful for long-term processes for Real-World assets.
      • Businesses need consistency and trust.
      • Having multiple collateral types allows governance to fine-tune the overall risk premium charged on aggregate borrowing with a collateral type.
  • The most substantial advantage for this is that by having multiple collateral types with increasing Risk Premiums - having them waterfall - no one will use the higher one if there is still Debt Ceiling in the lower one. By having them waterfall will mean when you get into a Vault position the only risk is the base rate and the remote possibility of the Risk Premium changing bc of the collateral risk changing - so just the fact that you give this more reliable guarantee to the Vault user vs. the dynamic adjustment that would affect anyone while also still giving them the ability to get compensated for having greater exposure to that collateral asset. You could always make a curve with the increasing Risk Premium at different sizes. You would have interest revenue to compensate.

    • Counter-argument:
      • This solution favors those who get in earlier than others (in ETH-A vs. ETH-B). This is a trade-off to consider, as well.
  • General Comment: The short-term goal of this proposal is to test the logic for making more automatic, and frequency standardized Debt Ceiling adjustments through a manual calculation of a mandated actor. If this logic and process goes well and seems to be a good fit, it will be converted to an Instant Access Module (IAM) and be utterly automatic without human interaction. Think of these proposals as a testbed for the Maker community to see if this adjustment logic works in the short-term while keeping in mind that the long-term goal is indeed to create an IAM from this.

  • General Comment: when it comes to Stability fees volatility in the near future, we will see products that offer rate vol hedging. The more we force that volatility into the base rate vs. the Risk Premium and keeping the Risk Premium relatively stable - it would benefit everyone. That way, all vault owners could use one standard instrument to hedge volatility in general - all vault owners looking at their collateral type and the changes that could also happen to the Risk Premium in the short term vs. everyone focusing on base rate volatility. The more we put everyone on a standard page that the base rate is the only volatile rate and use it to hedge, the better. IF we do it for Risk Premium, it could increase complexity, and vault users could miss out on liquid instruments, so it’s essential to keep the long-term UX effects of making the Risk Premium adjustments.

    • The group strongly agreed with this point. Moreover, creating hedging products for Stability fees becomes impossible for automatic Risk Premium adjustments. Hedging comp interest rates become effectively impossible.

Considerations for the Risk Premium Adjustment Proposal

  • Addressing the lack of motivation behind the Risk Premium adjustments - do we want to add additional rate risk to Vault users? The Risk Premium adjustments increase the rate risk for Vault users as a tool to better manage Debt Ceiling utilization or avoid introducing more collateral types. Still, you can’t argue it reduces rate risk. It makes the trade less attractive to Vault users by adding this component. It is also a concern that these dynamics could be a bit hard to figure out - requires more dependence on other users’ behavior and more feedback loops. This exists now with the base rate and price of Dai, but by having on a per collateral type level with a sensitive adjustment formula to the debt, ceiling utilization could make the dynamics of the position of the Vault user much more complicated. Thus, this complexity is a downside.
  • In general, Risk is always bad - it may be symmetric in both ways for the Vault user; it may mean your rate could go down because the Vault is underutilized.
    • An example is BAT
    • Better to have certainty about the future.
  • Unfair that the Stability fees on a vault would vary on what other people are doing. But we do already have this with the base rate and price of dai. Feedback dynamics are already there.
    • Even if we want to make dynamic adjustments to Risk Premiums, it may be over-engineering. We are pretty early, and it’s not necessary at this stage.

How we can split MIP17 into two proposals

  • The debt ceiling could be first with modification and that it could make sense.

  • Ties into the current Debt Ceiling strategy and using gradual adjustments

    • Prevents osm attacks etc
  • We don’t just highball the debt ceiling as high as possible - so having a target debt ceiling and if the Actual debt ceiling is 90% utilized, we increase it by X amount up to the target debt ceiling and repeat this on a per period as it says in the MIP now.
    * A little different with the absence of the Risk Premium

  • Strong Point:

    • The main feeling is that we don’t want short-term users driving off our long-term users.
    • In agreement with the debt ceiling automation first.
      • Only ppl using the excess liquidity should be paying for it - not the ppl who have been with Maker since MCD started.
    • If we had it for ETH-A, we would have Risk Premium due to increase utilization, which would drive away leverage users, which would be very bad.
    • On the other hand, increasing the debt ceiling’s based on demand pushes will be very useful. To be able to mitigate that is going to be helpful for growth.
    • The debt ceiling is to prevent the OSM attack/loss situation so that anything automation needs to be optimized.
    • Managing the overall collateral pool and how much we are comfy with assets in each particular asset should be manual - caps should be done manually by MKR holders through discretion for the time being. A way to scale up or down debt ceilings to the hard caps that’s safe for osm risk is the best MVP for this MIP.
  • Outside Suggestion: Do a dynamic base rate before doing a dynamic Risk Premium

    • The base rate should control for supply and demand alignments within the Protocol as a whole, but this is more for intra-collateral supply and demand balancing - so different situations.
    • Hard cap or soft cap - soft cap brings on more risk.
    • The base rate is separate from this discussion - this is more about risk and not about monetary policy.

Action Items

  1. Start with modifying MIP17 to cover simple Debt Ceiling Adjustments and create another MIP for Risk Premium Adjustments for later consideration / a future Governance Cycle.

    • This will result in re-thinking / defining the Target Debt Ceiling since we are splitting up the proposals and, therefore, not doing anything to the Risk premium.
    • Myself, Rune, and Planet_X will work on the modification of MIP17 for Debt Ceiling Adjustments and hopefully propose it before the Formal Submission deadline of August 3-5. If anyone else is interested in contributing to the modified proposal, please message me on RC (@charlesstlouis) or reply to this forum thread.

/fin

9 Likes

This sounds great. I agree that RP should mostly retain its initial value based on Risk Team assessment. Logically we should be adjusting the base rate to persuade peg stability. Risk Premiums can be seen as the overall likelihood of failure of an asset and unless that asset becomes riskier due to some event, it should rarely change. Looking forward to seeing this evolve!

5 Likes

I wasn’t able to make this call. These are some great notes. Seems like a great discussion.

Nice in depth discussion on the Risk Premium Adjustment. All the issues seem to be discussed in depth.

I agree that automated debt ceiling raises, up to a per-asset hard cap, makes the most sense as a first step to more automated governence.

Things like automatic base rate adjustments will require more work–e.g. DAI price oracles, and more complex smart contracts (due to the math involved in going between yearly and per-second rates). But I don’t foresee any fundamental obstacle there.

One can imagine even more advanced schemes–e.g. automatically adding ETH-C, ETH-D, etc with progressively higher risk premiums as the hard caps for each lower-risk version are hit. But it’s best to start out with the simplest, safest thing, which is debt ceiling adjustments. This will already help cut down on governance workload.

6 Likes