Monday, October the first the voting dapp got real-world feedback on its multiple choice quadratic voting feature.
How did we get there?
Noticing a slack message from Oskar after the previous dev meeting regarding the problem of going over time because there were too many hot topics, the voting dapp swarm decided on Tuesday the 25th that this would be a great use case for quadratic voting to prioritize the hot topics which would be discussed during the meeting.
The swarm decided that we should create a new token, Status Developer Meeting Token (SCDM) which will be sent to meeting attendees in equal amounts. This was decided because 1. Technically it was simple to do, 2. We wanted each member of the group to have equal voting power and 3. Wanted to make sure each member had the token in their status wallet.
On Friday the 28th after been certain that the Dapp would be ready, a slack message was sent to the #Core-Dev-Meeting explaining the vote and asking for wallet address to be added. Out of a possible 44, 10 wallet addresses were given (massive thanks to all). Two wallet address were added by myself and including my wallet address, 13 were collected in total.
On Sunday the 30th and Monday the 1st SCDM tokens were sent to the wallet addresses. This was done one by one and really highlight 1. We need a better way of distributing tokens and 2. My wallet address was the controller for minting tokens, this meant that I had 100% control of who gets what and how much. There needs to be a better way to pull back the unilateral control. When minting the tokens we ran into an issue of a transaction been stuck which was resolved by resending the transaction with a higher Gwei value.
On Monday 1st Oct the poll was created, the items captured from a GH doc were put into the poll as multiple options. Of the 13 people with tokens, 9 people voted. The analytics and results may be found here: https://drive.google.com/open?id=1kNBDB0EwstptOwUpnZW3Hn0lq85_z2hOd17yHl2ZiWg.
What we discovered:
- Not one person used all of their voting tokens. In some cases it was because it was not clear that a user had votes remaining and in other cases it was because there was an assumption that votes were been “spent” and they wanted to save votes for the next meeting.
- In some cases it took a while for the Dapp to reflect that the user had the correct tokens.
- The “voters” field was not updating.
- One users transaction got stuck due to their Gwei value been slightly below the safe low.
- To get maximum engagement the process of voting needs to start earlier
- Doing things on chain really does provide a high degree on transparency (if you know how to use etherscan and the contracts involved). This transparency as well as the ability to vote for all particpants give the decision legitimacy.
- The transparancy of the vote also means that its avaliable for “smart contract bribery” in the sense that someone can write and fund a smart contract which will pay out voters who vote in a certain way.
Based on this experiment we are investigating:
- Better distribution mechanics. Ricardo recommended looking at Merkel trees or a method whereby only permitted users may mint a specified amount of tokens for their wallet address, maybe even a combination of both. Dream scenario would be to extract wallet address from a private group chat, the manually entering wallet addresses into a spreadsheet is not smooth.
- Accumulative voting tokens. It seems the natural mental model is that tokens are spent when voting happens, so why fight it? Tokens could be burned when used to vote and then users will receive new voting tokens prior to a dev meeting so that tokens might be stored up for specific votes or even traded.
- The more complex these experiments get we realize that some form of simulation would be great to test the mechanics and incentives behind the governance process.
- We realized that when more of our decision making is done on-chain, the GAS costs are going to become significant. To this end we are looking at a side chain solution (Loom networks or zero knowledge proofs) so that contributors will not need to pay GAS to participate.
- We also realised that a really great indicator that the voting dapp is been used for governance is when we see token holders actively campaigning for other token holders to vote on a proposal they think is the correct choice. Hopefully we will see the vote stimulate this kind of debate in the community.
- Investigating private/dark voting whereby the result and process is transparent but the votes of individual accounts are not known so that they may not be bribed by a smart contract.
- Reaching out to thought leaders in the field of goverence to get thier input on our pratical goverence experiments.
Next Steps:
There is a second round of UX testing taking place on new designs which aims to address issues of:
- How to connect a wallet
- How the voting works, I.e staking, spending, voting
We are aiming to use the voting dapp for more decisions that swarms in status need to make. It’s great way to come to a decision which is fair, legitimate and transparent. Please contact me if you are interested in using the Dapp.
Thanks so much to the swarm members (Richard, Barry, Ricardo, Edge, Patrick) for grabbing the Monday Dev Meeting opportunity and making it happen. As well as a huge thanks to Maciej and Obi for your work on the copy and design.