Enhance the Governance Voting Engine

Currently the LUNC community faces many challenges. From how to manage the community pool, who should control the community pool, what utility projects should or should not be funded, if LUNC should be repegged and if so to what token/coin and so forth. These challenges will not be lessening anytime soon and if the community does desire to vote on every topic then the current voting engine is insufficient for rapid decision making.

This proposal is to gauge community feedback and is not a final specification proposal. More details would need to be added.

The current voting engine only allows for binary yes/no, true/false, pass/fail type votes. People/validators can abstain or vote no with veto, but for all intents and purposes it is a simple binary engine. However, a binary voting structure is very limited. As an example, if the community were to vote on allowing the concept of community funds to be controlled by a multisig wallet and to have 9 people in charge of the wallet, we would either need a vote for a yes/no on both the concept and the 9 individuals in one vote which is problematic because a voter may agree with the concept and not all 9 of the members. To avoid this we could have two votes, one for the concept and one for the 9 members, but that still means a voter has to vote all or nothing on the 9 but has now added 2 votes and added more time to the process or to be truly democratic we would need to have 10+ votes, one for the concept and then one vote for each of the potential 9 members and we keep adding votes until we get a quorum on 9 acceptable members. In this example voting on individual members is what is required to really have a consensus in the community and to allow community members to truly govern LUNC, however, it rapidly becomes unmanageable and can significantly increase the time it takes to pass any governance.

The above is only one example of where a simple binary voting engine is too limited when complex concepts are being voted upon. The binary engine adds significant time to the process and in the rapidly changing and volatile world of cryptocurrency, quick decision making is advantageous.

I propose a change to the voting engine. The change would allow different voting types to be supported. The proposed list of types is as follows:

  • Binary (yes/no or pass/fail)
  • Multiple Choice Single Select (select 1 of n choices)
  • Multiple Choice Multiple Select (select any X or Y choices)
  • Ranked Voting (rank all potential choices from 1 to X, top Y win)

Binary would work as it does today. Multiple choice single select would only allow a single choice. The number of potential options should be limited to 4 or 5 for clarity. The multiple choice multiple select would allow the voter to pick multiple and the totals for all selections across all voters would be totaled to decide which item are implemented. If it was pick 2 or 5, then the top 2 vote getters would be the winners. Ranked Voting would be similar. The multiple choices could also have a built in “no with veto” option as well. Other options could be supported given community feedback.

1 Like

There is one thing that I don’t like, it is the power of validators that should be individual for all members of the community. Although there would be the problem of the identity of the users and those who use many accounts to inflate the votes. It is a problem that all networks have and it only leads to centralization. Any blockchain that claims to be decentralized is not because the vote depends mostly on the validators and not on all the individuals in the community. A blockchain that achieves this would become one of the most secure, fair and decentralized

1 Like

“Terra community”.