Exploring what Quadratic Voting could look like for Aragon Organizations

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)
1 1
2 4
3 9
4 16
5 25

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.

Implementation Details

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.


Our team did a similar project at ETHSanFrancisco which could count as the PoC for the ideas presented here specifically “membership”. We had a concept of a broader idea of “signalling”, then just voting.

1 Like

Great stuff in there!

I think the discussion/discourse aspect is really critical to any sort of goverance/voting processes (though I think it is less important for it to be tightly coupled to membership/permissions as the actual voting process). E.G. while not as tightly integrated in terms of UX discussions can happen on a forum like this one, or on github, or on reddit, without too much impact. Though there have been conversations about directly linking discussions to votes in the Aragon app. cc @Quazia!

I love the integration with bloom in your project and would love to see a way for an Aragon Organization to issue membership tokens automatically based on a unique bloom attestation!

Are you guys continuing to work on Kora or is a one off thing? I think there is a lot of infrastructure we have built for Aragon that you guys could leverage if you plan to continue down that on-chain Goverance rabbit hole!

We were planning to continue the project in form of an aragon app and applying for the nest grant for this proposal. However, all my other teammates already have full time jobs so we dropped the idea.

The more conversation based voting probably has more use in signaling whereas Quadratic voting is really appealing for votes that actually lead to a specific action. Is there any reason that you couldn’t have vote credits accrue based on a separate tokens balance?

The best path forward in my opinion for a quadratic voting implementation would be the scalar approach using token based membership. Forking the base voting app would be a good start. Really the only complexity is that it needs to burn the voting tokens. All the other parts should be pretty easy. For the UI I think really all you’d need to add is the slider, it’s mainly a contract based solution.

Even if you only accept votes from “Members” it’s really easy to have collusion if the votes are transferable but I’m not sure how much of a risk that would be. Would you prevent voting from non-members or make it so the tokens could only be transferred to members? If it’s a specific use token it’s not super important that it adheres to a token standard I don’t think, especially if it’s meant to be used in a closed system of membership with a specific application.

Why is it important that a user can’t retract their vote?

1 Like

No reason, and from an implementation perspective that would be very nice but was mostly trying to keep things simple by sticking closer to how it is typically described (distribution to individuals)

Totally, I think the risk assessment is hard to gauge in a general sense but I think it’s probably not so important to worry about at this stage. There is a coordination cost to collusion and its generally easier to just accept the restriction (even more so if within the community its culturally frowned upon to cheat). In the absolute worst case where everyone colludes perfectly the system ends up being essentially linear vote buying (which is not necessarily a bad outcome considering that the votes are bought with an allowance).

I don’t think I would put that much significance on this, its more that I don’t see a compelling reason to allow people to retract their vote (and having the ability introduces some weird strategic (false) signaling if voting is not an actual commitment).

It would be an interesting path of research to see if there’s some sort of organizational “game” you could setup with low stakes to stress test different voting approaches against a community whose culture is specifically to cheat. Grab a bunch of people from the Aragon community and place them in a simulated organization on a long weekend with something like assigned goals and alignments (cheater/non cheater). I mean that sounds like fun to me…

I think false signaling is the most compelling reason not to allow people to retract their votes.

Haha definitely! Though its hard for me to reason about whether such an environment would be indicative of reality, or if certain aspects of the model would change how the game is played (for example if each member is assigned a role they can make credible commitments about their role that would be impossible if their role was an intangible predisposition).

My proposal for quadratic voting in Aragon:

  1. Port Aragon to Fuse (with the side effect of much reducing gas costs).

  2. For anti-Sybil check if user’s private key is associated with a GoodDollar UBI account. To persuade somebody to give away his private key, one probably needs to pay him more than his basic income. So to get many fake accounts costs rather much, moreover, if we receive somebody’s private key, he can be in control of our funds.