Skip to content

Instantly share code, notes, and snippets.

@psybull
Created July 26, 2019 20:18
Show Gist options
  • Save psybull/b32f4aa397540da41f04f42620a8fd3a to your computer and use it in GitHub Desktop.
Save psybull/b32f4aa397540da41f04f42620a8fd3a to your computer and use it in GitHub Desktop.
eli5 mkr rough draft
Continuous Voting and the peculiarities of the 7/26 Executive Stability Fee Vote
(Note, the Maker system uses 'fanciful' names for its internal system objects and functions, which tends to put off readers, initially, but the author believes they are absolutely fundamental to quickly grasping the system's complex concepts)
IMPORTANT INITIAL NOTE: This issue does not ultimately put the platform at any real risk, but will require more MKR to be put into changing the rate than one might have guessed, initially.
*explanation of the voting system overall*
When the MakerDAO governance polling system signals for a Stability Fee change, it does not automatically change the official rate in the system. Instead, the rate outcome from the poll is crafted into a `spell`, which is a contract deployed to the blockchain that, when `cast`, will do the magic necessary to update the system to the new rate.
The Executive Voting system is managed by the `chief` contract, which is where this new spell is added to the `approved` list of `spell`s. MKR holders who have locked their MKR into the governance system can choose to commit their votes toward any approved `spell` in this list. The `chief` also has one `spell` designated as it's `hat`. The `hat` is changed when someone calls the `lift` function on an approved `spell` that has more MKR voted towards it than the current `hat`. If a `cast` event is called on a `spell` that is currently the `hat` on the `chief`, the new rate change will go into effect (provided that the spell has not been cast, previously).
A note about the 'continuous' nature of voting: The spells themselves never 'expire', and any MKR holder can support any one (but only one) of the approved spells at any given time (including a previously cast spell). Adding or creating spells, voting a new hat, and casting new spells all do not effect the MKR dedicated to the other spells. MKR holders themselves must either withdraw their support completely, or change to support a new spell, else they will be continually voting for the same rate in perpetuity. This is the crux of where the issue arose today.
*explanation of the issue MakerDAO faces today*
Historically, the system has worked such that the `spell` with the most MKR committed to it is also the current Stability Fee (or, the new, upcoming, voted fee), over the past few months MKR holders have been voting in smaller amounts on a weekly basis than back when there was more of a perception of a 'rate emergency'. This has led to a number of former `spell`s in our system which have 'dead' MKR still supporting to them, one such spell still running with 78k MKR (whereas, the most recent executive vote on 7/19 passed with ~32k MKR)
While older `spell`s cannot be `cast` a second time, they CAN be `lift`ed to become the `hat`. Since anyone can call the `lift` function, what has happened today is someone with knowledge of this situation used the `lift` command on the older `spell`, which has promoted it to `hat` status. In order for us to cast the `spell` that matches our 18.5% poll, we must get it's MKR support to be above the `hat` not, whichever spell was most recently `cast`.
Either some of the 'dead' MKR must be withdrawn/changed from the old `spells`, or we have to rally enough new MKR in support of the new vote, such that we surpass this value, in order to be able to successfully `cast` the spell for the new rate.
*why is this a problem today, and not before, when these spells have had 'dead' MKR in prior weeks, too?*
Basically, because someone else noticed this, as well, and executed the `cast` at the appropriate time to interfere with our executive vote. This could have been done simply to highlight the issue more clearly, or perhaps maliciously, but in my opinion, this is a thing we needed to understand sooner rather than later as being part of the design of the system.
I will refrain from offering further opinions as to if or what we should do as a group to change this, but I do believe a debate about it would be healthy.
ELI5:
-Every rate change is stored as a votable `spell` in the system
-Voters support one `spell` in the system
-`spell` do not expire, though they can only be `cast` once
-to change the rate:
1) Add MKR to any `spellX` until it has more MKR than the current `hat`
2) `lift` on `spellX`, it becomes the new `hat` (replaces old one)
3) `cast` on `spellX`, (if `hat`, then the Stability Fee will change)
-if you dont actively change or withdraw your vote, you will continue to support that rate forever
-older votes were more popular than newer votes, and had more MKR still sitting on them
Today:
-someone `lift`ed an older `spell` with 78k MKR still on it (`oldSpell` becomes new `hat`)
-to pass the new 18.5%, we now have to top 78k (or get older MKR to move off of it)
- after that we can `lift` and `cast` the new rate into effect
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment