Continuous Polling

@Adam_Skrodzki has suggested some interesting changes to how we use polls to create executive votes which are worth discussing in more detail.

Current Implementation

With thanks to @psybull: when the MakerDAO governance polling system signals for some change, it does not automatically change the the system. Instead, the outcome from the poll is crafted into a proposal with a spell , which is a contract deployed to the blockchain that, when cast , will do the magic necessary to update the system (if it is chosen as the hat using the Executive functionality).


Currently, each change begins life as a new poll. Adam’s suggestion is instead to have continuous polls for each parameter which do not expire. Instead of taking the result of each new poll, creating a spell based on it, and then submitting it to the Chief so that it may become the hat, we instead specify some predefined timePeriod for each poll. If the poll reflects a result that is different to the current hat at the end of any such period, then a new spell is created and submitted to the Executive portal.

If the newly-created Executive Vote is not accepted and the current hat is not replaced, then the next Executive Vote can be constructed based on next snapshot of polls results.

There is also the potential to include an actual quorum requirement in continuous polls done in this manner, which would, at least, lower the potential for controversy in any given vote. It is also more in line with the technical implementation of the protocol, which is “continuous” anyway, as described in psybull’s post linked above.

Potential Benefits

This may well be better from a UX perspective, as well as slightly decreasing the governance overhead. Instead of having to monitor the voting portal each week, catch up on calls and keep up-to-date with the forum, I can keep in my head the key factors (as represented by the polls running on and shift my position as new and relevant information becomes available.

It also means that it would be easier to create lasting and useful educational resources for each key parameter. It may mean the wider community could gain the ability to create polls (as people could potentially stake some DAI to create a poll for some parameter they feel is important. Evaluating the inclusion of some parameter is far more doable than vetting random polling submissions, and could be standardised to at least some extent.)

If that is not enough to convince you, it would also be easier to keep track of governance changes for each parameter, and do so in the same place as where the votes themselves take place - adding to the ease and educational value of the voting portal and killing many birds with one (continuous stream of) stone(s).

Oh, and it would likely be easier to automate a bit (not that that is a huge priority to anyone who doesn’t have their own economic interests in pointing to the current flaws in Maker’s system atm :wink:)

One last point: it would mean that it is much easier to distinguish technical/emergency changes from monetary policy (as the former could be instituted as once-off polls) which would be more noticeable to people if they were more used to just seeing continuously available options.

Potential Downsides

This would likely require a lot of dev work done on the polling section of I am not familiar with the backend details, so it’s difficult to estimate how many hours exactly. At the very least, it will mean giving the backend the ability to read what the current hat is and acting upon it, which is nontrivial. It would definitely require testing, and I would estimate it in the weeks of good dev work for the entire flow to be built and tested properly.

However, given Nikolai’s post, overhauling the polling section in general should likely be bumped up that ‘priority list’, wherever it is.

Open Questions

  1. What are the current key parameters?
  • SAI SF
  • SAI DC
  • DAI SF
  • DSR Spread
  • DAI DC
  • Not exactly sure where things like the GSM belong in this kind of setup?
  1. What is the best timePeriod for snapshots to be taken and turned into potential Executive Votes?

  2. Probably a bunch of other things this noob doesn’t even know he doesn’t know. Like, for instance, the fact that there is a site at and a good article by Nikolai which goes deeper into why the UI in total should be overhauled…


Nice catch @andytudhope and @Joshua_Pritikin

I’ve made this kind of proposal but maybe other don’t like it.

This is exactly what do we need i think, but exactly…

Great Article, worth investigation.

Lol @Joshua_Pritikin i love it Music Machine.

@andytudhope thanks for bringing that up and describing benefits of the idea so clearly. Actually some of them I did not even took under account before (like parameter history extraction).

I think that timePeriod should be set to current frequency of new executives (7 days), but also that it should be subject to vote for change.

One note, that currently there is no direct DSR vote, there is DSR Spread instead,

Also. Personally I think we should have similar Yes/No polls about features like GSM but would love to hear counter arguments.

This is a useful summary, thanks for doing this @andytudhope

I can see that there are some benefits to this method of polling, that said, I think that it’s important that we take into account any downsides that might arise from moving to this system, and the costs associated with doing so. I’ve not thought a huge amount about this yet, but for those that have: Are there any obvious downsides? Anything less obvious? What work needs to be done to make this happen?

I find that I give greater weight to proposals like this if they give considerations to negative as well as positive effects, and attempt to estimate the costs (whether in time, funds, attention, whatever) of implementation.

1 Like

OK, edited for DSR spread (thanks, still straightening out all mah terminology round here) and for downsides. Which are mostly a good deal of dev work, some of which would be non-trivial. Maybe I’m too biased here though, so more than willing to hear other opinions about why this would be bad to do.

Of course, the other benefit is that as discussions about BAT SF vs ETH SF etc etc grow, this way of doing things scales better, in terms of attention specifically. If we’re struggling for voter involvement now, and there are only 2 collateral types, then when we really have multiple, it’s gonna be a really big problem to have polls running as they currently do. Takes me back to my point about continuous polls and how they allow us to collate docs, educational resources, and governance history all in one place, from which you can also take appropriate action.


Actually nothing needs to be changed in terms of smart contracts or portal This is purely about how the system is being used. And even there is slightly smaller overhead since as it is today ever week there must be someone who creates new polls.

Maybe little thing to be aware of is that for example in polls like SF you need to include all values upfront not change them everytime, but from automated history extraction that is actually advantage.

One of interesting downsides (new properties? ) is that if You do not change your vote It stays forever on certain value (what if someone have lost access to his MKR’s?).

It can be mitigated by setting limit of time from which votes are being counted (how many blocks in a past) but that is something we should experiment with only if problem of stagnant votes has been proven to be real and important.

1 Like

@Derek could You please read the above and confirm If I’m right saying that there are no changes in a voting portal required to make it happend ?
That it is only matter of how system is used and it can be used that way in current setup ? Thanks in advance. Also mentioning @rich.brown, since he explicitly asked during Governance Call for pointing him this thread out

Hi @Adam_Skrodzki we could certainly use the current implementation to create a continuous poll. It would require some work, which at an initial glance doesn’t seem too extreme. For example, I would consider dev work to; remove the poll end-date, flag at what point a snapshot would be taken (to support 3rd party sites like, define a quorum threshold, and introduce rules for what level of parameter deviation would be acceptable from current protocol values.

The technical side is fairly quantifiable, it’s the social aspect that I’ll let Rich comment on, which I think is a little more complex, for example might we be introducing the problem of building up MKR weights across a distribution of values similar to what we experience in executive votes? I guess we could solve that by introducing vote expiry mechanism (as we’ve discussed for executive voting).