Slider voting system

Governance
1

The split vote mechanism of polkadot can be used for a great thing.** Sliders.

It is very important for whatever treasury fund system, to allow numerical voting by using sliders, but polkadot unfortunately has not this mechanism incorporated.

But we can emulate the sliders voting mechanism, by joining two or more split vote proposals together.

For example this slider

can be emulated by using two split votes.

Sliders are important because the polkadot citizents must have a clear view that the more they pay for a government expenditure the less remains for the rest government expenditures. And this cannot be seen when you ask them separate yes/no questions for each expenditure. You have to ask them for all the expenditures together and point to the overall treasury fund account, with the help of sliders similar to the below. Thats why a slider voting system is very important.


The above slider vote (that is about to judge how the whole treasury fund account will be divided among 4 candidate proposals) can be emulated by using 3 split votes.
The middle of the first split vote (the light blue dot in the above slider) will be the left edge of the second split vote, and the middle of the second split vote (the red dot) will be the left edge of the third split vote.

Of course all this complexity should be hidden, and we should present to the voter a simple understandable slider, that will be translated (upon the movement of the slide points) to the appropriate split votes .

Let me also give an example of a slider vote. Suppose someone wants to cast this slider vote [ 0 - 0,4 - 0,9 - 1 ] in order to decide what percentage of the whole treasury 3 proposals deserve (according the above vote, the first proposal deserves 40%, the second 50% and the third 10%). This slider vote can be translated into two split votes.

The same logic can be applied to slider votes that are about to decide for more than 3 proposals. For example this slider vote [0 - 0,4 - 0,7 - 0,8 - 1 ] decides about 4 proposals to share the treasury. This slider vote can be translated into three split votes and so on.

Of course after receiving all the slider votes from the voters, and in order to extract the voting outcome, we should follow a “vote the numbers” procedure. A complex method when we have to deal with sliders, I will explain it later.

Someone may argue that whoever controls a minimum turnout will always receive nonzero amount of money. But this occurs only in case there is not a threshold for a minimum voting participation. If there is a minimum participation threshold, at the proposals where the voters refuse to vote (yes or no, it doesnt matter) they will not receive any money. So defining a minimum participation thershold is crutial for the slider vote system.

Additionaly, the slider voting system as I am planning to implement it in the current polkadot governance system will be INDICATIVE. Those who participate in the slider voting are commited to confirm the outcome of the slider vote at a final (yes/no) vote that is about to judge the overall slider budget. They are commited to respect the outcome of the slider vote , but they are not forced. They cannot be forced after all, as long as the slider voting is not part of the polkadot protocol.

2 Likes
2

You can have an idea of what “a vote the numbers” procedure is by reading this post.

1 Like
3

Let me also clarify that when I say “split vote mechanism” I mean this:

“A split vote with balances given for both ways as well as abstentions, and with no conviction, useful for parachains when voting, other off-chain aggregate accounts and individuals who wish to abstain.”

Let me say, also usefull for voting numbers or for slider voting …

1 Like
4

I think it would be an interesting addition to opengov if treasury proposals could be voted on with a scalar instead of a trinary vote (Aye, Nay, Abstain).
An interesting case would be this referendum which is retroactive, but value-based instead of effort-based in its argumentation.

This would allow voters to express more meaningful budgetary opinions. If a proposal appears too expensive, but generally welcome, votes could express the acceptable budget.

For such a vote to be binding, it would need to be enacted according to the winning amount. If the sliders are not a binding vote, then why not just facilitate this

But there are open questions:

  1. how do we prevent slow-drain attacks on the treasury? (someone who holds enough tokens for the support-threshold of a track could always get away with a non-zero payout
  2. what if the proposing team does not accept to do the work for less money? Would it have to decline the payout?
1 Like
5

In the slider voting system, the people are not forced to put all the available proposals into their personal slider vote. They can put as many as they want, they can even put just one proposal in their slider vote, or even none ( the none is also an option).

So in order to solve the problem that brenzi pointed to, we have to vote for a minimum voting participation. A proposal should have a minumum appearance in the slider votes of the people, in order to become eligible.

What minimum participation? For example in Dash, I arbitrarily defined the minimum participation to 10%. Of course this 10% number of minimum participation may also not be defined arbitrarily by an admin or by a developer, but it could also be voted, provided of course that at least 10% of the people participate to that numerical vote that is about to decide about this 10% minimum participation (this is the rationality of the bold rule).

The proposing team is forced to define a minimum and a maximum payment. The minimum could be greater/equal to zero, and the maximum could be less/equal to the whole budget. Of course it is not smart for a proposing team to set the minimum to zero and the maximum to the whole budget, because this extreme request will prevent people from participating into the vote. And as I explained above, in case we have not reached the minimum participation, no decision can be made.

1 Like