Signal Request: Reduce the frequency of the DSR Spread governance poll

It’s been 2 weeks since the switch to the DSR Spread governance poll, and it seems consensus has formed on the 0% and 0.25% options. In the first week 0.25% gathered 72K MKR backing it (99.5% of votes) while in the second week there was a split between 0% and 0.25% with 0.25% narrowly winning.

In both cases nearly 100% of the vote went to the 0% and 0.25% options which leads me to believe MKR holders want to keep the DSR close to the MCD SF on an ongoing basis. In order to reduce the effort required for engaged voters, I propose we reduce the frequency of the DSR Spread governance poll. I’ve listed some options below:

  • Keep the DSR Spread poll frequency at 1 per week
  • One DSR Spread poll per 2 weeks
  • One DSR Spread poll per 3 weeks
  • One DSR Spread poll per 1 month
  • One DSR Spread poll per 2 months
  • One DSR Spread poll per 3 months
  • Abstain (I want to see results)
  • Abstain (I have no opinion)
  • Abstain (I don’t feel I am knowledgable on the subject)
  • Abstain (I disagree with the poll options)
  • Abstain (I have a different objection)

0 voters

This is a multiple choice poll, vote for everything you are willing to vote for in an on-chain vote. Poll will close on February 13th, 2020 at 11:00 AM EST to be reviewed during the weekly governance call.

4 Likes

It would be great if somebody from Maker development could comment on the idea of using a fixed % of SF fees to pay the DSR interest rate. See Why SF = DSR ? Request for discussion

2 Likes

There is one thing that could happen with a fixed % of the SF going to the DSR.

As @SamM commented in another discussion we had regarding this coupling of the DSR to the SF via the DSR-SPREAD he has a real concern about the DSR rate going above the SF rate as this would cause people to max out the debt limit.

One could easily see a situation where using a fixed % of the SF going to the DSR to lead to an effective DSR rate that is higher than the GSF. (I looked at these scenarios and think they are managable if the rates are set to a utilization curve both on the borrow and supply sides.)

I have some other issues regarding system control variables being grouped that can lead to similar unexpected operational hazards. Example is using the DSR-SPREAD. Lets say the DSR-SPREAD is 4% and the SF is 8%. Dropping the SF to anything below 4% would REQUIRE the DSR-SPREAD to change otherwise the DSR rate would come up negative in such a governance vote.

Which leads to a suggestion for governance no matter how these are polled for. List governance changes and then the actual operational changes they are going to exhibit in the governance poll.

Example SF 10%, DSR-SPREAD 2% means SF 10% and DSR 8%. In the case I give above where the SF is 8% and the DSR-SPREAD is 4% that if in the list of polling options for SF below 4% and DSR-SPREAD 4% that this would lead to a negative DSR rate and hence are invalid choices.

It is exactly these kinds of details that people have to keep in mind when coupling important system variables, as ignoring that the DSR will change when the SF changes, may lead to unintended and unexpected system or behavioral consequences. I am considering making a seperate post on this.

My point here is that even with SF at 8% and DSR at 4% there could be a very real difference between lowing the SF from 8-4% that is vastly different than lowering the DSR from 4%-0% at the same time. Contrast this same situation with the SF at 12%, DSR-Spread at 4% (SF=12, DSR=8) and lowering the SF to 8% (SF=8, DSR=4). This 4% SF drop acts very differently as one lowers the DSR to 0 the other by 50% to 4%.

3 Likes

One thing to note is that the spread converts to the DSR via the formula: max(GSF - DSR Spread, 0) so it will never be negative.

1 Like

@hexonaut I kind of hoped there would be a formula that would effectively limit the DSR to not be negative but still not sure how this would work with polls and executives.

Is this now a general feature in the governance code that any DSR-spread value coupled with GSF that would lead to a negative DSR value effectively zero’s it (i.e. it is valid from a voting perspective even if the system just zero’s the DSR rate as a result)??

1 Like

Yes it would zero the result as per the wording in the governance poll that passed to make this switch.

1 Like

So my opinion on this is that it doesn’t really matter a whole bunch at this stage. We still need to be voting weekly for the SF, voting a second time is very little extra friction.

That said, in principle I agree with reducing governance overhead, so I also voted to reduce the voting to sensible intervals.

The only options I didn’t vote for were 3 week intervals and 2 month intervals, as these intervals are non-standard choices that I think may confuse more than help, especially 3 weekly. I recognise that this is a fairly ridiculous reason to vote against them, but sue me, I like it when things are well structured and organised.

1 Like

It would be neat if I could vote on all the week’s polls with a single transaction.

In fact, I’d like to see polls presented as a control panel, like https://www.shutterstock.com/image-photo/central-control-room-nuclear-power-plant-1054177697

3 Likes

Huge fan of reducing cadence of the dsr spread. The whole point of the spread is that it should lower our cognitive overhead, and this is a great next step.

3 Likes

I agree with reducing the DSR poll interval but I’d like to see another vote instead - the threshold when the vote to increase the debt ceiling must be activated (utilization = 80% | 85% | 90%…).

I selected 1 week. While I agree with general idea of making this vote less frequent I think it is much to soon. We should wait until participation increases and result of vote stabilize.

1 Like

The poll has now closed with a 53% majority support for “One DSR Spread poll per 1 month”.

Due to “One DSR Spread poll per 2 weeks” coming in with 50% of the vote I had to make a choice between 2 options:

  1. Run a governance poll with the normal Yes/No question.
  2. Run a governance poll with 3 options of 2 weeks, 1 month and status quo.

I opted for option 1 as option 2 runs the risk of a minority status quo vote incorrectly taking the win. This would happen in the case where the majority wants a DSR Spread reduction, but the Yes vote gets split such that status quo wins out.

Ideally, I wanted to run this as a ranked choice poll to solve the problem of the vote split, but we do not have support for that (yet). I will be making a new thread soon to gather support for adding ranked choice to the governance portal in cases such as this where it is a clear win.

Here is a description of the vote for @rich.brown to add to the voting portal:


Title: Should we reduce the frequency of the DSR Spread governance poll to once per month?

Description:

If passed, the frequency of the “Dai Savings Rate Spread Adjustment” governance poll will be reduced to one poll per month. The poll will only be added on the first Monday of every month. The relative start and end times for the poll will remain unchanged.

Background and discussion: Signal Request: Reduce the frequency of the DSR Spread governance poll

Options: Yes/No

3 Likes

There was a 3% difference and you opted not to include 2 weeks? I don’t think that slim of a margin allows you to unilaterally make that decision in my opinion. Instead of allowing the on-chain poll to have the possibility of a split vote, you have taken it upon yourself to make that decision instead, which in my opinion is actually worse than if it was split.

2 Likes

The rules on this aren’t exactly clear as we haven’t had this situation before. My original thought process was similar to yours. Who am I to make this unilateral decision? I talked it over with @LongForWisdom and he gave me the view that since the poll is multiple choice it is not so much this option vs that option, but more the options that the majority are most okay with. Personally I don’t really like any of these decisions and would prefer ranked voting with 3 choices. I would say that if people don’t like my unilateral decision on this then by all means vote no. I don’t think this is a particularly contentious vote. If 1 / month is too infrequent we can always raise it again.

I would like to make ranked choice available in the future to solve this type of problem. This is definitely not going to be the last poll with no clear winner.

EDIT: Maybe a temporary alternative can be to run 2 polls? Status Quo vs DSR Spread Frequency Reduction and the second poll being 2 weeks vs 1 month.

Waiting to hear back from @rich.brown if we can do 2 polls. If we can then it should solve all the issues.

1 Like

So to speak to this some. Both of these options have over 50% support. Meaning both of them would be valid ways forward. Given that one is slightly ahead, it makes sense to me to favor that one (even if the margin is small)

I presented a couple of options for this:

  1. One poll on-chain with both consensus options and the status quo.
  2. One poll on-chain with the highest consensus option vs the status quo.
  3. Have a second forum poll which was single choice between 2 weeks vs. 1 month to determine which the community favors.

Sams’s suggestion to have two on-chain polls is a fourth option that I didn’t consider.

In my view Option 2 is still best here. The way to read the outcome of this poll is that over half of the community are happy to move to either a 2 week or 1 month cadence for the DSR poll. Since slightly more of the community are happy with a 1 month cadence, this is the option that is most likely to pass in an on-chain vote, and is therefore the option that should move on-chain.

Putting both on-chain would set a precedent that I am slightly unsure about. What is the rule we would be following:

  1. All options with greater than 50% go on-chain in some form?
  2. Options go on-chain if they are either win, or are ‘close to the winner’?

Would we still be advocating for both to go on-chain if one option had 70% and the other 50%? Probably not, imo, we would go for 70%. Which means rule 1 is a bit sketchy. Rule 2 also seems sketchy for what I hope are obvious reasons.

In this situation it may have been wiser to extend the poll for some time and attempt to bring a higher level of consensus to one of the >50% options. Obviously this has the downside of taking longer and asking for additional engagement though.

It is a tricky situation because you make a good point about if the difference was 50% vs 70%. This brings into question where the threshold is determined to be and who gets to decide that.

The one thing I continue to come back to is the fact that these votes are such a small subset of the actual voters that I worry about how that translates to on-chain actions. By this I mean I’m not sure the forum votes will always be representative of what MKR voters ultimately want/decide. By keeping the most options open we can give MKR voters the greatest breadth of options while at the same time culling the options that are the most unpopular.

I’m not sure what the golden rule on all this should be but I’m sure these conversations will continue evolving and as it stands right now it seems to be somewhat up to the poll creators discretion.

1 Like

I don’t really see an issue with running a >= 3 option governance poll if and when we get support for ranked choice voting. If not for this case then for one where two options exactly tie.

Also, regarding what is the threshold to put both options on chain. In my view the forum poll consensus is a very rough mechanism to see what people like. There is no Sybil protection, and I don’t think we will be protected by good will forever. I think trying to come up with some rigid criteria that specifies what should and shouldn’t go on chain is not particularly helpful. I think it’s up to the poll creator to find that balance. If they do a bad job then their proposal should be voted down in governance.

1 Like

Vote is up: https://vote.makerdao.com/polling-proposal/qmxvvzb6uei1jawvtxentsbreepfkuzsohaefpw6j4vpn5

1 Like

Interestingly, this is currently losing on-chain. Two large holders are currently voting against this change.

No idea if either of you are present on the forum, but it might be good to get some discussion going as to the arguments against this cadence change.

1 Like