Edit: @prose11 definitely stole my thunder here
Certainly. I’m afraid this explanation will end up involving some minutiae of the Governance process so if you have any follow-up questions feel free to ask.
First, let me start by pointing out that since that post was made there has been a redistribution of votes and the following 2 options are now above the 50% threshold for inclusion in the on-chain poll:
- Increase Surplus Buffer by 0.67 MM per week
- Increase Surplus Buffer by 1 MM per week
A crucial aspect of the Signal Request process is that not all of the options offered to community members for voting in the forum will make it into the on-chain vote. Conventionally, we have used a cut-off of 50% of non-abstain votes to decide if an option is included in an on-chain vote or not. Remember that people can vote for more than one option so it is possible for more than one option to attract the votes of more than 50% of participants. In this instance, we have the ability to submit on-chain polls using instant-runoff voting rather than our usual plurality voting (FPTP) method.
Of course, we need to know what will happen if no options cross the 50% threshold. In that instance, we would consider the Signal Request to be in favour of the status quo.
Once it was realised today that none of the options in this poll in favour of slow increases to the Surplus Buffer (lerp) had above 50% of non-abstain votes we realised there might be a problem with this particular Signal Request. This is because it is the position of GovAlpha that the status quo for Surplus Buffer increases is to increase directly to the new Surplus Buffer. Lerping the Surplus Buffer is an active decision that Maker Governance must make rather than a default assumption.
So in essence, this Signal is asking several questions:
- Should we increase the Surplus Buffer?
- What size do we want the Surplus Buffer to be?
The default position here is “no, we should not increase the Surplus Buffer”, so if no options passed 50% the Signal would not proceed to on-chain, currently 2 options in favour of increasing the Surplus Buffer have above 50% of non-abstain votes so would proceed to an on-chain vote.
- Should we lerp the Surplus Buffer increase?
- What rate should we lerp the Surplus Buffer at?
The implication of this question is that it is not automatic that the Surplus Buffer increase is lerped.
Clearly, in this particular Signal Request, there are more people in favour of lerping the Surplus Buffer than not lerping it. However, there was not a consensus on what this rate should be. We realised that this may result in an outcome that had actually received the fewest votes (no burn/lerp) being the option that proceeded to an on-chain vote as this was considered the status quo option. If the poll was to end and an on-chain poll proceed without a lerp option then Governance participants may rightly be confused or frustrated. Consequently, we decided to post both on the Forum and on Discord to highlight this discrepancy to voters.
As things currently stand in this Signal Request an on-chain poll will likely be an instant-runoff vote with 6 options:
- Increase Surplus Buffer to 90 million, with a gradual increase of 0.67 million per week
- Increase Surplus Buffer to 130 million, with a gradual increase of 0.67 million per week
- Increase Surplus Buffer to 90 million, with a gradual increase of 1 million per week
- Increase Surplus Buffer to 130 million, with a gradual increase of 1 million per week
- No change to Surplus Buffer
For what it’s worth, from a personal perspective I am not sure that the potential for the lowest scoring option to proceed on-chain is a desirable outcome for a Signal Request and I will be bringing this up at the weekly GovAlpha CU meeting next Monday as something we might need to provide clarity on moving forwards.