Quadratic Voting is an approach to voting that enables participants to meaninfully communicate the intensity of their preferences. The basic idea is that each participants recieves vote credits which can then be “spent” to vote on proposals. As the participant spends more vote credits on a specific issue the cost per vote increases.
|Votes||Cost (in Vote Credits)|
The result is that over a range of different proposals, a participant has the option to express more influence on single proposal at the expense of expressing lower overall influence across all proposals.
This mechanism has some really compelling properties but also introduces some specific implementation challenges, the following post is intended to explore some of the implementation possibilities with regard to Aragon Organizations.
In order to make this work we need to implement a voting app which is aware of participant membership in order to apply the pricing curve and we need a mechanism to represent voting credits.
Because each participant faces a personal price curve, it is important that participants can’t simply create multiple “accounts” in order to participate in the process. Since membership is such an important primitive for organizations, I expect we will see lots of improvements in how this is tackled from both a technical and ux perspective… but right now the best way to manage membership in an Aragon Organization is to use the Token Manager application to assign Non-transferrable membership tokens to each member. In the simplest form this could be setup initially for a small group, and then have that group approve each new member. Alternatively an small application could be created that validates an identity attestation and mints additional membership tokens to make this process more scalable and efficient (though perhaps also less secure as it depends on an external attestation).
Unlike the current voting process, Quadratic Voting is more like a transfer. When a user sends X vote credits it will be counted as y votes based on a simple pricing function. Therefore voting credits can be relatively easily represented by a token which can only be transferred to the voting contract. (note: in some variations it may be reasonable to allow general transferability and trading of vote credits however this would mean that that the voting app would need to only accept votes from “Members” to avoid sybil attacks)
The pricing function would be applied based on each address that is sending vote credits.
The interface for this could be similar to the current voting app (possibly a simple fork) but when submitting a vote the user would specify how many votes they are “purchasing” (Probably with a slider). They would also not be able to retract their vote.
Vote Credit Distribution
New vote credits would be issued on a rolling basis equally to all members. This issuances can be a constant rate or can be variable based on the absolute amount of vote credits that were used in the previous period. In the simplest case this would mean that each period (say a month) new vote credits are issued into a pool, and then each member can send a transaction to retrieve their share of new vote credits for that period.
While not strictly necessary for implementation, a better solution would have the vote credit tokens use a scalar data structure so that each participants balance coould be adjusted in a single transaction. This structure would also allow the token to maintain a fixed supply of outstanding voting credits at any given time, but updating the balances of all wallet as new vote credits are issued. This would enable users to think of thier balance as a proportional share of total influence rather than trying to associate a consistent value per unit.
The intention of this approach is to explore what the simplest practical implementation of QV would look like for an Aragon Organization. I don’t currently have any immediate plans to pursue this further, but if there is interest from the community and a dev willing to work on this happy to provide support/guidance.