Signal request/ Poll: Define standard stability fee changes based on recent price of DAI

Let’s improve the transparency of stability fee changes for all market participants to increase confidence in using the Dai platform. Currently, people vote each week on the SF changes, and it can appear ad hoc and unpredictable to many market participants. We should try defining a standard schedule based on the price of DAI over e.g. last 72 hours. We would still vote each week to enable an opt-out of the standard SF change if there were unusual circumstances or if it appeared it was being gamed. A standard schedule like below is in keeping with scientific governance and allows all market participants to plan effectively for their investing decisions and will ultimately increase Dai adoption.

Based on past SF changes it could look something like this (would be good to vote on a few alternatives) :

Dai Price: SF Change
<0.96: +4%
0.96 - <0.98: +2%
0.98- <0.995: +1%
0.995 - 1.005: No Change
1.005- 1.01: -1%
1.01 - 1.03: -2%
1.03-1.04: -3%

1.04: -4%

4 Likes

I guess you mean something like SF_new = round(SF_old / DAI^10, 2)

That could be a simpler way to express - but the main issue is implementing a standard, well-publicized schedule so that market participants know what to expect and we don’t have ad hoc polls and votes each week. The details of the schedule are somewhat less important than having one at all- we could always vote to change it if it needed updating.

1 Like

Couple things…

A) When MCD launches, we really should only be adjusting the DSR…
B.) The DSR is a potent tool for monetary policy. Once above about 200bps, we shouldn’t need to ratchet up the DSR that much to see a response…

(of course initially throw the above out the window… but after we get the DSR until control (meaning we identified the demand elasticity), we will be able to pull that rate down… and then the changes should only have to be incremental. (but they shouldnt ever need to be 300bps swings…)

remember as the system gets larger and larger… and one given collateral package produces less and less DAI relative to the total DAI outstanding…and since the DSR impacts ALL collateral packages, its use must be done with the system as a whole in mind…

You cant raise the DSR above the SF though . Basically, there will be a fixed premium, say 3-4%, where the DSR is below the SF. Any changes in the DSR will require changes in the SF to maintain the premium for MKR holders for the risks they are taking to backstop the system.

DSR is a function of the Stability Fee… so when it increases… the SF (for that given collateral package) increases 1:1 …

point being is that it impacts all collateral… risky and less risky… so it must be done with the system in mind…

First of all, thanks for posting here, welcome to the forum. :slight_smile:

A couple of thoughts on this point.

  • It seems to me that the market should already be aware of the fact that the Stability Rate is variable, and based on the price of Dai. There is already the expectation (or rather there should be) that if Dai is dipping then the fee will increase, and if it rises, the fee will decrease. Having a defined way in which the fee will change doesn’t really add much. The fee is still variable.
  • While the fee is still variable, your argument is that if it is variable in a defined way, then it will appear to be less unpredictable. I can buy this to a certain extent, but the problem is that if unpredictable changes are what is required to keep the Dai peg, we will make those changes, regardless of whether it breaks this pattern. I worry that we’d be setting ourselves up for more backlash when we inevitably have to go against this.

And some other thoughts:

  • A further issue is how we define the Dai price. Do we look at the 24h VWAP (volume weighted average price), a weekly VWAP? The state of the orderbooks? We’d need to decide what the canonical price is for a given period.

  • Short term fluctuations also complicates matters, it isn’t always correct to react to Dai being off the peg if it is caused by a sudden eth move. We could be 2% off the peg for a week, and this might be fine. How much time do we wait before we react?

  • Part of the difficulty in creating a system of defined responses is that we don’t really understand what responses are warrented yet. We have some small idea based on experience, but it is incredibly hard to isolate variables that are causing Dai price changes. We could define a system that ends up just not being strong enough, or being far too strong and then feel commitment to what could be a flawed set of responses.

  • Making future commitments on rate changes also relies on MKR token holders honouring a previous poll. I am very unsure whether this would happen in practice, especially as any on-chain poll around this (or any other) issue is unlikely to see 100% turnout.

1 Like

I think a serious problem with the current system of modifying the SF is that it is ad hoc, making it difficult to learn from, and MKR holders lose interest in the weekly polls and governance votes- creating the potential for even more poorly-defined changes in the SF. I agree that the time interval for defining the Dai price is important- I think a VWAP over prior 72 hours would be sufficient. We would obviously need to signal that the schedule is not fixed in stone and that in extraordinary circumstances it would be modified. Also- maybe every month or every 3 months, the schedule could be voted on again. In this system, the weekly vote of MKR holders would be to deviate from the default change and otherwise the default change would be adopted (this may not be compatible with the current contracts). I agree that we are still learning- but I think that implementing a defined schedule would help with the learning process rather than hinder it. Also - I think we would get a better turn out of MKR holders if the vote was to implement a schedule rather than a weekly SF change.

2 Likes

My understanding is that your proposal stems from 2 issues with the current system:

  1. it’s hard to understand why mkr holders vote as they do
  2. the system seems not responsive enough when peg drops

============

  1. I don’t think can be solved since mkr holders are/can be anonymous. We can only provide better tools and assume they will vote in their best interest. Unfortunately that might not always mean in their best long term interest? They could game the system for their short term gains? I did not really thought about it much, but in any case this is for another topic.

  2. My take on this is that improving liquidity and increasing confidence of arbitragers (in the system) will significantly reduce time of peg being below e.g. 0,98.

2 Likes

Actually- I would say it trying to deal with the following 2 problems:

  1. Stability fee changes are viewed as arbitrary and unpredictable by many system participants.
  2. MKR holders have lost interest in the weekly polls and SF votes because they happen frequently and lack a systematic approach

Is there any evidence for you stated problems?

I am not certain if data supports your thesis of mkr holders losing interest for voting. I would start with collecting data - before proposing any hypothesis.

Look at .the vote turnouts. they are trending down and represent < 1% of MKR voting

I understand what are you saying, but i think it’s useful quantify things that can be easily quantified.
How much did the voting participation drop?

Also, there might be some other factors we need to take into account, like summer time or critical update to the voting contract, large whales etc…

What is the drop in the number of mkr vs number of mkr addresses?

This is a problem for sure. I’m not sure that it follows that your suggestion would change this trend though.

I don’t think we’ve dug into these problems, while I’ve seen speculation, it doesn’t look like anyone has presented any data as to why MKR holders aren’t voting. This is still an open question, we can’t fix the problem if we don’t know the causes.

1 Like

I support this proposal. The two primary reasons for me to support this proposal is 1) imo the such a standard would be kind of a forward guidance and hence the effects of SF/DSR changes should be visible faster as they can be anticipated by the market faster. 2) Agreeing on a standard is first step if we wish to somewhat automate changes at some point.

I have a couple of issues with the above based on data.

  1. I’d like to see a DAI/USD price with statistical variation of that price over the time (i.e. something like a 3 sigma error - ala 80% of the time it was in this range) since one has to look at this statically.

  2. I think the changes need to reflect a change based on the current SF. since a 1% change on a 20% SF is going to be vastly different than a 1% change based on a SF of .5%

I would alter the above to be as follows

<.95 vote
.95-.97 with +/-.01 to 3-4 sigma level: NewSF=OldSF x 1.5
.97-.99 with +/-.01 to 3-4 sigma level: NewSF = OldSF x 1.25
.99-1.01 with +/-.01 to 3-4 sigma level (80-90% of the time): SF same
1.01-1.03 with +/-.01 to 3-4 sigma level: NewSF=OldSF x .75
1.03-1.05 with +.-.01 to 3-4 sigma level: NewSF=OldSF x .5
vote

Not entirely what to do if the volatility is higher Probably trigger a SF vote.? I have to think on this and look back to the data - since to my mind if the volatility is higher it probably means there are liquidity issues.

Also I have no issue with narrowing to +/-.005 but think until the SCD->MCD migration wider limits will probably be a good idea.

Honestly have to consider how close we are to the debt ceilings and factor in collateral value changes into such a beast.

BTW: In case people think these are ‘out of control changes’ consider that the valid operating bands can be set and if they are exceeded trigger a SF vote.

1 Like