Is anything wrong with the DSR and Stability Rate calculations as planned for MCD?

Hmm, having some thoughts on classification generally. Perhaps we should setup a generic scale for evaluating the risk of described problems, such as these ones and -ve DSR vs centralized stable coins as collaterals!

Perhaps a 1-10 scale where:
1 = I am happy to live with this risk forever
10 = I believe we will have to Emergency Shutdown because of this at some point in the future

Can we use the number rating poll type for this?

Flat-rate increases across multiple loan types due to exogenous reasons has unequal impact on the market competitiveness of collateral-packages.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

0 voters

Under the proposed system and policy, there is no adequate tool for combating high demand for a specific collateral package without effecting the rest of the system.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

0 voters

Edit: Well, these polls do exactly what I wanted them to do, which is a nice surprise.
Edit the second: Closed these polls as I’ve created a separate topic for that purpose.

I 100% get your point. I do however disagree… and it is for this fundamental reason… when you were to bifurcate the Risk Premium into Risk and Risk Adjusted Demand… the ultimate risk premium gets paid to MKR holders… and that only makes sense if the actual risk went up… if the risk did not go up, then it is a monetary issue not a risk issue.

(I dont understand this part “Having the Stability Rate solely based on risk, and using the DSR to absorb supply only works until the DSR needs to go higher than the Stability Rate.”)…

As outlined the SF is a aggregate of the DSR + Oracle + Risk Team + RP… so if the DSR goes up, it will increase the SF by the same amount. but there into a scenario where the Oracle / Risk Team / RP would be negative… so the DSR can never go higher than the SF.

all the more reasons to get DAI out to the masses and get it locked into a DSR… and get points of sale accepting DAI as a method of payment with the default feature of depositing in the DSR right after receipt enabled… there are dozens of simple applications that will help offset an elevated DSR…

Hmm, actually I think it’s me that was misunderstanding things. So please ignore this part.

Having the Stability Rate solely based on risk, and using the DSR to absorb supply only works until the DSR needs to go higher than the Stability Rate. At this point we have to increase both together (adding the DSR component to the Stability Rate) to keep the system solvent.

I had some strange idea that Governance pocketing the RP meant we were earning more than we should be, but in actuality we’ll be ‘earning’ nothing, because the point of the RP is to offset the expected loss such that total net change is zero.

1 Like

it is not only to offset the expected loss… it is to insure against that loss… and we will probably insure to a 95% or higher confidence… meaning that we would insure knowing we would have “some” losses… (like 1-3% … ) … if and we have more losses,. then we should increase the RP… and if we have less… then there is an argument to reduce (but that is a risk team decision).

if it were to only offset the losses… then MKR would be burned at the same pace it would be minted…

We have the Governance Fee to burn additional MKR on top of this, but yes, the insurance argument makes sense to me.

RP is what burns MKR… the oracle + risk team do not burn MKR…

Previously a ‘Governance Fee’ has been discussed as a 0.5% value which goes to burning MKR to compensate governance for their efforts. Possibly this is no longer going to be a thing, not sure.

I’m aware Oracle and Risk team fees would be direct transfers of MKR/Dai from the system to these parties rather than burns (at least I assume this is the case… not sure how this works in practice)

Never heard about the Governance Fee… totally new to me…

“When CDP Holders complain at the rise, we explain that it is a variable rate loan,”

You do realize that not a single institutional investor will use a CDP is this is the policy?

In order for DAI to scale it requires IIs to use CDPs.

iirc some of the dai generated by the stab fee would be diverted to eg the risk team’s multisig

i understand your point… however, many transaction deals are LIBOR + X bps… where folks know LIBOR will float during the term of the transaction. How is this any different?

Hypothetically, we could allow the DSR to go above the SF for particular assets as long as the DSR does not go above the weighted average SF across all assets.

1 Like

Just to be a little more concrete, here are two possible mechanical policies to get a desired DSR d. I think @LongForWisdom had similar ideas.

Assume n collateral types t1,…,tn, with respective Risk Premiums r1,…,rn. The total fee rates are k1,…,kn, with ki = ri + di where di is an arbitrary number. At the current time, borrow volumes are respectively v1,…,vn. Let’s also assume d > max(ri) for simplicity.

Both of the following policies provide a DSR of d:

  1. Set di = d - ri for all collateral types. Here di does not depend on volume. This has unequal impact on fees for different collateral types.
  2. Set di = ri * (DSRevenue / riskRevenue - 1), where DSRevenue = d * sum(vi) and riskRevenue = sum(ri * vi). Here di depends on volume. Impact on total fee is proportionally the same for every collateral type (i.e. ri/di is constant for all i).

I don’t know if policy 2. is feasible within the constraints of the current Ethereum chain – all rates have to be recomputed (possibly lazily) at every borrow volume change.

Anyway I think the answer will lie between those 2 extremes and that governance will use its discretion to set rates, but it seems good to have very simple models like this in mind.

edit: I modified the post to assume that all of the fees (the ki's) go towards the DSR. Before, the Risk Premiums (the ri's) were assumed not to go towards the DSR, but that seems less realistic. Either assumption is simplifying.

Really important topic and great debate so far! I just want to chime in with some of my old thoughts in this field.

A core dynamic that will exist from the very beginning is the debt ceiling/stability fee curve - the concept that you can keep increasing debt ceilings, but when you do that you have to also increase the stability fee to deal with the increased risk due to higher concentration in a single collateral type. This ends up having the effect that you can, in a way, use the debt ceiling to deal with the issue, but without at the same time running into the issue of artificially locking users out of access to a using CDPs because the debt ceiling has been hit. In practice how this would play out in governance is that every governance cycle, the risk teams would iterate over all collateral types their risk construct covers, that are nearing their debt ceiling, and if/when increasing their debt ceilings, also increasing their stability fees (predetermined by a exponential relationship decided by the general risk frameworks).

In the long run it should be possible to deploy so-called “instant access modules” to modify specific stability fees. An instant access module is a customized governance submodule that is approved by governance to give direct granular access to making small real time modifications to specific risk parameters of specific collateral types within secure pre-set boundaries (also set by governance).

This would allow the community to react as soon as the data became available to try to counteract a sudden surge in a particular collateral type that’s causing liquidity issues. Instant access modules can be controlled by their own “mini-governance process”. Typically it would be either a centralized multisig/risk team, or a small quorum of MKR holders.

However, until this option is available, the type of manual solution that was already proposed here - the “refrigerant” parameter - can be implemented directly through the executive vote of each governance cycle, but will then be limited by the cadence of the governance cycles.


The DSR will be more volatile than LIBOR

No dispute on that… but the point was what pricing information is communicated in a deal… and if the reference point is based on LIBOR… the participants accept that variability in LIBOR… same will apply with time to the DSR.

Well for the most part they will hedge with DSR derivatives. If we introduce excessive volatility in the risk premium, no one will use it.

I think the DSR against the MCD-SF should be looked at from the risk profile(s) of collateralized assets and predominantly the PEG against liquidity.

One thing I think should be considered is an option in Maker to basically exchange MCDAI for SCDAI as another lever to drive the transition and affect both pegs.

In effect the above becomes a 4th lever to drive the SCD -> MCD transition and use MCDAI which can be minted as an additional market driver until the SCDAI outstanding descreases below the MCD outstanding and the markets supply/borrow rates line up on MCDAI vs. SCDAI.

One thing I don’t think people realize is that it will take a bit for secondary markets to develop on MCDAI and MCDAI-SCDAI exchange trading to develop (if it develops at all).

IMO to me these markets look mostly to be driven mostly by liquidity vs. rate I think some consideration of how liquidity will be managed in conjunction with the MCD-SF, SCD-SF and DSR would be important.

A solution to this problem is to modify the rates using a facility utilization curve and to allow the markets by use of the facility to manage these rates both on the

fee side.

and on the DSR side.

Attempting to micromanage markets with strictly manual governance changes will invariably not track market needs and be overly demanding on governance voting, it will tend to over and undershoot and do this with a latency related to the sensing of input and applying a change (in the case of governance latency is least a week) In effect adaptive curves will always do better at tracking the system if designed properly (well bounded activity limits) yielding a better match particularly if the latency is much lower than a manual system.

I see this all the time in applied control system practice either in steady state or pulsed systems using feed back as well as feed forward loops for device control.