Voting mechanism

Six LCU community members just completed a proof of concept (PoC), of its first DAO building block: a basic one member one vote (1m1v) voting mechanism. This voting mechanism is one of the means to support communities, which have started a DAO on the LCU DAO-platform, in their decision making.

The six community members, who participated on LCU DAO PoC are: Jurre Machielsen, Raphael Cornelis, Sander Mandemaker, Marc Buma, Xinrong Ding, and Peter Nobels.

The ‘1m1v voting mechanism’ contains the basic components of a voting process:

• creating a DAO which includes an address book to register members
• starting a voting
• casting votes
• visualizing progress
• capturing results

Deliverables

• Demo (working application): https://lcu-dao.moosty.com/
• Code base back end (open source): Link Github: https://github.com/liskcenterutrecht/lcu-dao-transactions

Hereafter we elaborate on this voting system and our next steps towards a full-grown LCU DAO platform.

Use Case "1m1v voting mechanism" - functional description

Current situation

Voting is a valuable governance tool, it gives the members of a community the possibility to exert influence and also collects information about viewpoints. However, votings consume time and energy of the voters and a voting committee. This often results in poor voter attendance and even in invalid votes.

Why should it work differently?

Voting is easy to organize and to participate in, offers huge benefits in terms of increased member participation, and provides shared knowledge about viewpoints. Digital systems can offer users such easy to use voting tools. Combined with DLT, which provides an ‘if this then that’ protocol and immutable data, the needed security, transparency and trust is guaranteed. As this solution is lowering the threshold for participation whilst covering security and transparency requirements at the same time, voter attendance will likely increase. Even off the couch voting is possible. As a result, members will take more ownership for their community.

A basic 1m1v voting mechanism

A basic 1m1v voting mechanism means that it offers simple functionality and operates within some constraints. In our PoC the following rules apply:

• Each member in the address book is eligible to vote: The voting mechanism makes no distinction between different types of members and different kinds of stakes. Hence, each member in the address book can participate in every voting.
• Digitalized authentication and identity management are not included: Anyone has the possibility to create an account on the DAO-platform. Since obtaining membership is determined by voting, existing members usually wish to know the identity of the candidate member as only known persons participated in the PoC, this requirement was met "physically".
• Votes/voters have no voting weight: Every voter can cast just one vote and every vote cast has the same weight (= one).
• Only yes/no-voting is possible.
• In order to be eligible to vote, a member must be listed in the address book at the moment the voting starts: Members who are added to the address book, because they are granted a membership during running votings, cannot participate in those votings.;
• It’s not possible to withdraw a vote.
• Voting can’t be scheduled: Voting starts after it is launched by the submitter.
• Utility tokens are used for the transaction fees needed to cast votes on the blockchain: Each public/private key pair allows its owner to cast one vote. Note: tokens are needed for transactions on the underlying blockchain. These tokens are a fee for the nodes which run the protocol, execute the custom transactions ( = smart contracts), and store the data. These nodes keep the application secure.
• There’s no curation of submitters, subjects, or specifications: Each community member can choose a subject for voting, can specify a proposal and also start voting.
• The duration of voting is fixed and is the same duration for each voting.

• The Quorum and voting ratio are fixed and are the same for each voting: All the votes need a minimum of 51% of yes-votes to be approved (voting ratio), and all members have to vote for a voting to be valid, (so the quorum is fixed on 100%).

  
  

While the above-mentioned functionality and constraints may not fulfill the specific needs of all communities, they offer a clear starting point for our PoC and for our way forward.

How does the 1m1v voting mechanism work?

Instantiating a DAO

Before a voting process can start a DAO must be instantiated. This is performed by a founding member. To be able to instantiate a DAO, this founding member must create an account on the Lisk DAO chain. By starting the instantiation process an address book is created with the DAO as the first entity. The initiator can include other individuals, who have a proper account, with one single action as founding members to the address book.

Note: in the address book there’s no distinction between founding members and other members. Founding members are the individuals who are included in the address book as part of the instantiation process.

Votings

The PoC acknowledges two kinds of votes: votes for membership and votes for proposals. Both votings are supported by the same 1m1v voting mechanism.

Starting a voting election for membership

For a person to obtain community membership, current members have to vote on his/her application for membership. The first step for the candidate member is creating an account on the Lisk DAO chain. The next step is to start a voting process for membership. This must be done by a current DAO member.

Starting a voting election for a proposal

Any DAO member can make a proposal on which fellow community members can vote. Entering a proposal in the DAO will start a voting process.

1m1v Voting mechanism

An application for membership or making a proposal opens a voting window. During this voting window all eligible members can cast their votes. A voter is eligible to participate in a specific voting when he/she was in the address book on the moment the voting election started.

Each community member can decide to support an application for membership or a proposal with a yes-vote, or alternatively to turn it down with a no-vote. During the voting window the in-between results are visible for all members: how many members casted their vote (voter turnout), the ratio between yes- and no-votes (vote ratio), whether the amount of votes is met for a voting election to be valid (quorum), and how many members still can vote (reservoir).

The voting window closes after a fixed period. After the closure of the voting election no more votes can be casted. An application for membership or a proposal is accepted when the quorum is met, and when the voting ratio is more than 50% (in favor of yes-votes).

Voting process - step by step

So the voting process (happy flow), for a proposal, has the following logical steps:

1. Make a proposa: By a community member, supported by the software service "Making a proposal"
2. Read new proposal(s): By the software service "Organizing a voting for proposal(s)"
3. Open voting procedure for proposal-x: By the software service "Organizing a voting for proposal(s)"
4. Update proposal status "Voting open": By the software service "Organizing a voting for proposal(s)"
5. Alert new voting procedure: By the software service "Voting for proposal(s)"
6. Identify and signal eligible voters: By the software service "Voting for proposal(s)"
7. Show new proposals to the eligible voters: By the software service "Voting for proposal(s)"
8. Cast a vote: By eligible voters, supported by the software service "Voting for proposal(s)"
9. Publish casted votes: By the software service "Voting for proposal(s)"
10. Read votes: By the software service "Organizing a voting for proposal(s)" (part-2)
11. Update status "Voting closed": By the software service "Organizing a voting for proposal(s)" (part-2)
12. Read overall voting result: By the software service "Establish community support proposal"
13. Update status "Proposal accepted": By the software service "Establish community support proposal"

Votings - Lessons learned

We didn’t only build a 1m1v voting mechanism, we also performed some voting. Some of the insights gained are listed below:

• The user interface (UI) is important: A UI should address the following questions: What is the meaning of all information shown? What is it I’m voting for? Which votings are open, which are closed? What is the result?
• Voter turnout doesn’t happen by itself: Voter turnout, and thereby the involvement of members into the community can be improved by choosing a standard day for votings to start and to end, by campaigning, by choosing only relevant subjects and by limiting the amount of votings.
• Experiment with voting mechanisms: The first version of a voting mechanism probably won’t be the last one. Applying a voting mechanism provides the user with valuable experience, and in turn, will help to improve the voting mechanisms and processes. We even foresee the rise of the discipline of decision engineering which deals with the question: “which process and which mechanism is best suited for a specific decision-making issue?”

Under the hood - technical details

This provides an overview of the different frameworks used, the custom transactions created and our experience using the Lisk SDK.

Components of the PoC

• Back-end: Working custom transactions that can run on a blockchain.
• An extended HTTP API connecting the back & front-end.
• Front-end: A ReactJS front-end dashboard to create and manage DAO’s and votes, (interact with transactions).

Transactions

This Proof of Concept uses seven different custom transactions which are listed below:

• createAddressBook: To create an address book (DAO) with 2 to 10 founding members.
• BaseProposal: The baseProposal to start voting, (this is the transaction all proposal types should extend to).
• BaseVote: The baseVote transaction gives basic voting functionality and checks for all extended vote types.
• SimpleProposal: A simple proposal extended from BaseProposal with 1 additional field for the question for this proposal.
• AddMemberProposal: Extending the BaseProposal with 1 additional asset field for the publicKey of the new DAO member to be voted in.
• SimpleVote: Extends baseVote with no extra functionality, (this vote can be used for both proposal types available in this PoC).

• JoinAddressBook: When an add member proposal is passed this transaction lets the member join the DAO.

  

Create an account

Everyone can create an account on the LCU DAO platform using a faucet transaction. This faucet transaction can be found at https://github.com/Moosty/lisk-sprinkler, what this transaction does is the transaction can be sent by a new user and that account gets 100 tokens on its account to use for making transactions on the blockchain.

Create personal Lisk DAO

A unique DAO is made with specified founding members.

How does it work?

Every unique DAO is a separate account on the blockchain. When broadcasting the CreateAddressBook transaction, a new account will be created with a unique publicKey generated using the unique transaction data. In the address book account the following assets are stored:

• name: (unique name for a DAO).
• type: “ADDRESSBOOK” to be able to identify address book accounts.
• nonce: what nonce is the address book on, (the nonce is equal to n- proposals) starting with 0.
• addresses: an array of member objects. This array contains the publicKey and the nonce on which they entered the address book.
• description: a longer text description of the address book.

Only the name, description, and an array of addresses are needed in the transaction to create a new DAO.

When an address book is created, any member of that address book can create a voting proposal using one of 2 types. When submitting a proposal, a new account on the blockchain is created in which votes are being recorded. The following assets are stored in a proposal account as listed below:

• type: either “SIMPLE” or “ADD_MEMBER” at the moment.
• nonce: to which address book nonce does this proposal belong?
• start: the start time, the blockchain timestamp of from the moment the proposal transaction was accepted.
• votes: an array of vote objects containing the member and their vote value, (in this PoC 0 = no, 1 = yes).
• status: current voting status 1 is active, 0 is done; this happens on join or when the last allowed voter votes.
• addressBook: the public key of the address book this proposal belongs to.
• options: an object containing options that can be used in custom vote types.

The options asset field of a proposal is different for simple and add member proposals. Simple proposals have an option string called ‘proposal’ and add member proposals have one option field called ‘member’, which contains the publicKey of the proposal’s subject.

When a proposal/voting is created, all current DAO members with a nonce lower or equal to the nonce of the proposal can vote once on the proposal by submitting a SimpleVote transaction containing the proposal public key, the address book public key and the vote they want to make either 0 or 1 (0 = no, 1 = yes). Voting is open for 24 hours, in this time votes are accepted from members. After voting closes the simple proposal is done, in the frontend the calculations are done to either "pass", "reject" or "invalidate" the voting. Members can then see the results.

After an add member voting the JoinAddressBook transaction is allowed for the new member to join the address book. This transaction updates the address book account by adding the public key to the member list, with the nonce of the next new voting to allow him/her to vote on proposals created from that moment onwards. A JoinAddressBook transaction contains the address books public key and the proposals public key, with this information the blockchain can determine if the transaction should be accepted or rejected.

The BaseProposal transaction should be the extension for every custom proposal transaction. Besides validation/error checks the BaseProposal transaction sets up the voting account for you.

In a custom proposal transaction, you only need to extend this template transaction and require a constructor and applyProposalAsset() method. For the custom AddMemberProposal transaction, only these checks and proposal assets are required to be added:

Roadmap

Future-ready

With the envisioned DAO-platform in mind, the 1m1v voting mechanism is embedded in a future-ready front end application. This front end has a member view and a DAO view. The member view shows the DAOs in which a member participates, the DAOs an individual can join, and the activities of this individual in his/her DAOs. The DAO view shows all its proposals and all its members.

The blockchain part of the back end has been built with the Lisk SDK (Software Development Kit). This part of the application contains flexible custom transactions and the template transactions BaseProposal and BaseVote. Custom transactions are the Lisk equivalent of smart contracts. Templates are reusable patterns.

Next steps

With our proof of concept, we mastered the technology, learned how to design and use a voting mechanism, and how voting can strengthen a community. Our next step will be to turn our PoC into a viable, lovable DAO building block harnessed for real-life use. The following steps will be realizing the next building blocks such as other voting mechanisms and incentive/reward mechanisms.

Campaigning can also be included in voting processes as this will improve the exchange of viewpoints and the involvement in the community. After all, voting is just the endpoint of decision making and the beginning of a steering process.

If you feel inspired and want to build your own proof of concept blockchain application, check out the Lisk Grant program. More information about the program and the application procedure can be found on the Lisk webpage for the Lisk Grant program.

Disclaimer: This blog post was written by our community member, Peter Nobels (Lisk.chat username: Peter Nobels) as part of his participation in the Lisk Builders program.