I come here to post a reflexion I originally posted as a response in the Maker subreddit, because I think it has its place here. The discussion was about the Governance Security Module vote being removed from the voting page, and the fact that Executive votes are hidden after a week to avoid vote dispersion, to ensure governance security.
The system of “governing proposals” is designed for sequential voting (one after the other, the votes from proposal A switching to proposal B up to the point where B has more MKR votes than A).
This leads me to the two following points:
1- If I’m not mistaken this means that during a vote for a new proposal, the governance security is lowered since the votes are split between the governing proposal and the one being voted in. This might be part of the attack vector that the GSM was supposed to prevent, I don’t remember.
The consequence is that voting might augment overall governance risk temporarily, which creates an incentive to stay on the governing proposal and for big holders to stake a lot on it. This leads to the voting system potentially being stuck on a proposal.
Since I originally posted this a new vote has been proposed and it is far from overtaking the governing proposal that has been heavily voted after the potential exploit was disclosed. This leads me to believe that my intuition was right. I don’t see an obvious solution to this issue without a deep change in the voting system, maybe the team has already discussed this, I’m curious to know what you think about it.
2- This means that 2 votes can’t happen in parallel, as it would compromise security because of vote dispersion and could be confusing to voters that would have to choose which proposal is the most important to vote for. (or not understanding why they can’t vote for both, I didn’t understand the fact that votes are “transferred” from one proposal to the other until recently)
For this, I think that splitting the voting mechanism between
1. constants setting (DSR, stability fees, debt ceilings)
2. other governance votes (like the Governance security module vote)
would improve the issue of concurrency voting.
It would be possible for an MKR holder to vote in both voting branches, and the transfer of MKR allocated to proposals would only be inside the same branch. This would not (theoretically) lower security, except if it lowered engagement even more.
While it makes sense to have sequential votes and a unique governing proposal for the system constants, It is less clear why other proposals would fit in the same “proposal pipe”.
Also the UI could gather both proposal branches in the same page with some kind of color code and differentiate in the text at the top of the page like
Currently voting for Activate DSR, Dai Stability Fee, and Sai Stability Fee Adjustments (constants voting)
Currently voting for Governance Security Module Delay (operations voting)
It seems to me that this would avoid lowering the votes and security while improving governability.
I hope this helps somehow or sparks some discussions, I might be totally wrong in my analysis of the system, in that case please let me know.