# MKR 'Transition Attack': Not Applicable

This is a belated response to the Micah Zoltu’s post about an potential attack on MKR via voting.

Up until yesterday I was only vaguely aware of his post from skimming headlines on reddit. I assumed that it was simply a general concern about MKR voters being able to instantly make changes. That concern is valid and that issue still exists.

But in a recent discussion about the governance module, someone pointed out to me that the “but wait, it gets worse” meat-and-potatoes of Micah’s post related to the idea that votes “transition” from the old proposal to the new one.

It seems that nobody thought to point out that this attack is simply not applicable because MKR voting uses ds-chief which was specifically designed as an approval voting system. The top proposal can have 90% approval while the next-highest proposal can have 80% approval.

The transition process should involve most of the stake-vote that is on the previous highest proposal also approving the next proposal, before removing their vote from the old one. The issue is that the voter GUI hides this fact, and now it seems like nobody is aware of how voting actually works, or is obscuring it on purpose.

From the README of the repo (emphasis mine):

Approval voting is when each voter selects which candidates they approve of, with the top n “most approved” candidates being elected. Each voter can cast up to n + k votes, where k is some non-zero positive integer. This allows voters to move their approval from one candidate to another without needing to first withdraw support from the candidate being replaced. Without this, moving approval to a new candidate could result in a less-approved candidate moving momentarily into the set of elected candidates.

In the MKR voting contract, n is 1 and k is 4, meaning max 5 candidate addresses per slate.

Here is a GUI that shows candidate addresses by approval, and more importantly, it shows “slates”. Slates are groups of addresses that you can vote for. Slates should usually include more than one address, because “do nothing” (stay with current proposal) should almost certainly be more popular than “I don’t care what happens”.

You’ll notice that at some point, slates started to usually only feature a single address, which is bad usage enforced by a GUI that “makes things simpler” in the wrong way. The core contract developers objected to this new UX for exactly this reason.

I don’t know why the Maker team decided to propose a time-delay (which doesn’t solve the problem) instead of making the GUI reflect the actual behavior of the contracts. It is one of the main features highlighted in README of the contract! Maybe they got stuck in the mental model presented by their GUI and do not understand the underlying contracts. Or maybe they understand exactly what ‘implementation details’ they are hiding from users, and are choosing to make it look like you only have simple binary choices for proposals they put forward.