Quadratic Governance: What’s Working and What’s Not?

– A rough exploration into real-world constraints of quadratic voting and possible solutions

For TL;DR, jump to Conclusion.

Quadratic governance has been proven useful in DAO governance, open source funding, and beyond. Meanwhile, it also shows great potential to be used in non-crypto governance systems such as corporate governance and even political elections.

The primitive form of quadratic governance is Quadratic Voting (QV). The idea behind QV is to allow participants in a governance system to express their degree of preferences while limiting extreme preferences (especially from whales). To achieve this goal, Glen Weyl et al. proposed that a voting credit (originally called “voice credit”) is assigned to voters who participate in governance, and the voting process consumes voice credits. The cost of voice credits per vote increases if one keeps voting for one proposal, therefore it limits the level of influence whales can impose on the voting results. Quadratic voting has been experimented with in crypto and non-crypto worlds. Recently, the ETHDenver community voting round used quadratic voting for matching fund distribution. In the real world, the Colorado Democratic Caucus used quadratic voting to decide legislative priorities.

Quadratic funding (QF) combines voting with the donation and creates an algorithm to calculate matching fund distribution via individual donations. Quadratic funding has been adopted by DoraHacks, Gitcoin, and some other crypto-native funding protocols. More than 30 quadratic funding grant rounds have been hosted on DoraHacks.io. Quadratic funding allows community members from any ecosystem to engage with early-stage proposals and BUIDLers. However, it suffers from several problems at the same time, including increased distribution inequality, identity forging, sybil attacks, and collusion.

Ultimately, it’s all about the scale of governance systems. Think of governance systems as distribution machines. If a system only distributes $100, probably there won’t be a lot of fake accounts. When it distributes $100,000, there will probably be bots and sybil attacks. When it distributes $10,000,000, it’s very likely that sophisticated collusion, sybil attacks, and other problems will emerge.

In this article, let’s explore the constraints of quadratic governance systems based on real-world practices, and discuss potential solutions to these problems. Eventually, the more problems we solve, the further we can scale up quadratic governance.

Challenges of Quadratic Governance Systems

In practice, a quadratic governance system can be constructed with a three-phase model - sign up, vote, and match.

Although it looks straightforward and simple, if you actually build such a system and use it in real governance, you will face problems from almost every step. Now let’s look at the system and outline some of the obstacles already found by us and others.

1. Sign up: if the system whitelists voters? If so, how do voters get whitelisted? If not, how to prevent abuses from malicious users?

2. Vote: voters vote for a certain set of targets (BUIDLs, projects, proposals, public goods, or anything that needs to be selected / funded).

3. Match / Distribute: if there is a funding pool to distribute, it will be matched to the targets based on the voting results. Post-voting analysis and adjustments might apply.

In addition to the questions above, there are many more problems to think about. When the system scales, whether participants will work with each other to collude? And how do we prevent collusion?

There also might be some more subtle and use case specific problems, just to name a few:

1. How to continuously verify a target’s legitimacy to get funding in a QF round?
2. How to verify voter identities while preserving voter privacy?
3. How to find out sybil votes and deal with these votes if sybil attacks already happen?
4. How to deal with inequality if there are huge funding gaps between targets?
5. What are the complexities of solutions to these problems?

In this article, we focus on three categories of problems that are most relevant to scaling quadratic governance: Identity Verification / Sybil Attack, Collusion, and Inequality of Distribution*.*

Sybil Resistance and Voter Identity

Sybil resistance has been one of the most discussed topics in quadratic voting and quadratic funding so far. Compared to 1p1v or 1stake1vote systems, account splitting can generate more votes in quadratic voting, and larger support_area in quadratic funding, therefore more matching funds.

In theory, sybil attacks can be totally prevented if the system is gated and the voter population is small, because you can whitelist everyone and know everyone before they start to vote. A real-world example is voting in congress. Every representative is known and there is only a small group of them, normally not more than a few hundred people. It is not costly at all to whitelist everyone when everyone knows each other. Therefore, when the Colorado Democratic Caucus used quadratic voting, there should have been no concerns of sybil attacks or identity forgery.

However, it is different when a larger group of people use quadratic voting, or in the case of quadratic funding, where community contributors can come from anywhere. Notably, Web2 authentication methods like GitHub / email registration are NOT a way to prevent sybil attacks at all, because they can be easily created,and even account history can be forged. With a large voter population, quadratic governance systems are particularly vulnerable to sybil attacks, because forging identities and accounts to vote does make a big difference!

To address the sybil attacks, post-round sybil analysis systems have been developed. These systems mostly analyze voting data, and identify potential sybil accounts and sybil behaviors, then remove them.
Although post-round analysis is useful, There are a few problems with post-round analysis.

1. The analysis can only happen after voting ends and takes time. Community needs to wait during a grace period, and resentment could rise.
2. The open source dilemma. An open-source sybil detection system will be subject to further attacks, and often the development of new sybil attacks is easier than the development of anti-sybil tools. On the other hand, a close-source sybil detection system will not be fully trusted.
3. Attackers can always find ways to game the system, while the sybil analysis system cannot be improved and changed quickly, but the attacker can.
4. Changing / adjusting results could result in disputes and distrust.

Therefore, dealing with sybil attacks before and during voting is important. The question is - how can we verify voter identity?

Now look at a few existing / upcoming approaches: KYC, Whitelisting, Social account verification, NFT / Soul-bound tokens (SBTs), and zk-identity.

At the same time, because every identity verification method has its own tradeoffs, we further use the following metrics to evaluate tradeoffs: sybil-resistance, permissionless-ness, privacy, and complexity.

• Sybil resistance is a major goal here, at least for blockchain governance.
• Permissionless-ness is important because many communities want to stay open to a broad audience, and whitelisting / KYC people can limit their potential to grow. Currently, the cost of whitelisting or KYC methods is very high.
• Privacy is fundamental to facilitating people to express their real opinions.
• Complexity is how difficult (in terms of engineering and operation costs) it is to construct and use these methods in practice.

We look at these tradeoffs on different dimensions - openness vs. sybil-resistance, privacy vs. complexity.

Furthermore, there are different types of communities. Every community should select the best tradeoff for itself when selecting voter verification methods. A gated club can just use whitelisting, a grant DAO community might use several methods together to maximize its reliability and credibility, if its engineering capacity allows.

We can also look at different communities based on voter population vs. openness.

For small and gated communities, almost every verification method is valid. But for simplicity, whitelisting, staking, and Web2 authentications are probably the easiest.

For large and gated communities, NFT / SBT (with private attestation if privacy is a big concern) and staking are probably good choices, or combined with others.

For large and open communities, approaches like zk-identity are the long-term solution. For example, the 2020 US Presidential Election had a lot of disputes on both sides over mail-in ballots and the voting machines. For such a gated (only citizens can vote) but large community (there are ~300 million Americans citizens who can vote), it is probably worth developing zk identity infrastructures in the long-term.

Note that multiple systems can be combined. Adding staking to a whitelisting system can add accountability; combining SBT with zk attestation can add privacy, etc. However, adding new methods or combining different methods will increase cost of product, engineering, operation, and management. Therefore, a community needs to evaluate tradeoffs before making decisions.

Collusion Resistance

Although sybil attacks are happening all the time in quadratic governance systems, collusion is the real elephant in the room. Collusion is a more fundamental problem because collusion turns a governance system into a cooperative game, which is inevitable and much more complicated most of the time.

Ultimately, governance systems are distribution machines - people voice their opinion with votes and the system distributes a finite amount of resources to different groups. There are different levels of collusion based on the scale of a governance system. There are probably much less incentives to collude in a system that distributes $1,000 than another one that distributes $1,000,000.

There is cost associated with different forms of collusion, including financial cost, reputation cost, and so on. In DoraHacks grants, the BUIDL community guideline explicitly prohibits vote bribery. Community members who violate the rule can be banned from receiving matching funds from a grant. However, if the incentives of collusion are big enough, there always are ways to bribe.

However, unlike sybil attacks, we don’t have obvious ways to eliminate collusion. Collusion can be much more obscure than sybil attacks, and it is difficult to stop collusion by “law enforcement”.
In the real world, collusion is everywhere and most forms of collusion are even not observable - insider trading, bribery and lobbying. Preventing or regulating collusion can sometimes take decades (e.g., security laws).

In the blockchain world, it is often not feasible to enforce community rules to stop collusion (because there’s hardly any “law enforcement” on-chain!). Therefore, cryptographic anti-collusion solutions are more favorable. Minimal Anti-Collusion Infrastructure (MACI) is a system that achieves this goal by making it difficult cryptographically for voters to prove their actual voting results. A basic MACI voting round has four steps.

• First, voters need to register themselves to participate in voting.

• Then voting starts. All votes will be encrypted using the operator’s private key, and cast their votes to a smart contract. Voters can vote multiple times.

• When the voting period ends, the operator collects all messages and tally the votes in reverse order, then publish final results without revealing any individual’s votes.

• Lastly, the operator publishes the results with a zero-knowledge proof (ZKP) proving the results are correct.

Currently, MACI is mostly used in blockchain voting and community governance for funding distribution. DoraHacks Light-weight MACI (based on MACI 1.0) has been used by several quadratic voting rounds on DoraHacks.io, including the ETHDenver 22 community voting rounds, and Opensea Hackathon judge voting. In addition, Clr.fund is an Ethereum public good funding platform that uses MACI and quadratic funding.

MACI improves collusion resistance by increasing the cost of collusion. Without such a system, voters and bribers share information, and the cost to bribe will be low. With MACI, the cost of bribing will be significantly increased. In a system with efficient information, anti-collusion features will raise the cost of bribing to a point where the briber cannot afford it. Unless the briber can create information asymmetry and lower voter expectations, the briber cannot profit from bribing.

However, MACI is not a “once-and-for-all” solution for all collusion problems. The only unconditional property is the correctness of the result, which is guaranteed by zero-knowledge proofs. Other than that, MACI has its own security and privacy assumptions, mostly related to the operator:

1. The operator does not collude with voters by leaking information to certain groups of voters directly or indirectly.
2. There is no “crazy” mechanism between voters to break MACI collusion resistance (e.g., voters are physically monitored 24/7 or forced to vote on computers that are not controlled by themselves).

For assumption 1 - the original MACI requires that the operator is good, meaning that the operator preserves privacy of voter information as well as voting details, and the operator is not intentionally colluding with the voters by leaking information.
For assumption 2 - incentives are not big enough that voters invent high-cost ways to break MACI collusion resistance.

Are these assumptions important? In a small-scale governance system, they might not be important, because we can always trust the operator. But it might not hold true if the governance system scales. The operator can be bribed if there’s enough incentive.

One way to add privacy between voters and the operator is to allow voters to change keys and vote using different keys without providing the operator with any information about their new keys.

The idea is to add key deactivation into the system and use client-side ZKP to prevent the operator from knowing who owns which key, thus preventing the operator from knowing who voted for what. There are several ways to achieve this goal. The tradeoff is - with more privacy, engineering complexity will increase.

Reference link for different MACI anonymization:

• Light-weight MACI
• Original MACI
• Light-weight Anonymized MACI
• MACI Anonymization (with MPC)
• MACI Anonymization (with rerandomization encryption)

Quadratic funding is particularly vulnerable to collusion, because if some party can simply bribe more voters into voting for themselves, their gain will grow quadratically.

Currently, MACI is more than enough to enhance collusion resistance in most blockchain governance systems. Suppose anonymization is further added to existing products with the same level of user experience. In that case, blockchain-powered collusion resistant voting systems can potentially solve real governance problems, from the general election to future space governance.

Inequality and Tax

A large part of governance is distributing resources. Most of the time, inequality is rather a feature, not a bug, because it always exists as long as finite resources are being distributed. The only difference is whether it’s big or small, but we can never eliminate it 100% (utopia doesn’t exist anyway!). If a governance system suffers from big wealth / distribution gaps, people will lose confidence and trust in the system over time, eventually leading to collapse of the system. Notably, this is true both in the real-world (social uprising, revolutions, and civil wars) and in blockchain protocol governance.

The idea of quadratic voting is to limit extreme preferences, especially from whales. It works most of the time in practice. However, quadratic funding often increases inequality. If a project has a larger support_area (either because it received a large amount of donations or because it received donations from many different contributors). This is one of the reasons why most quadratic funding grants are subject to heavy post-round adjustments.

One idea to limit inequality in the quadratic governance system is to tax the top gainers. The projects that have been matched more funding can subsidize those projects that are under matched, similar to what many countries do to reduce wealth gap, except with two differences: (1) all “tax” funding will be used to redistribute within the same system, (2) tax can be programmed into the protocol.

Also, there is an assumption when using tax. We need to assume all projects / proposals are legit and pre-qualified. This is to make sure that all candidates that receive subsidies are legit ones in the eyes of the community. If a system does not have application screening, the system will not work.

The first design of quadratic funding progressive tax was described here. It taxes top projects every time vote() is called, and distributes the tax to all projects based on a fixed algorithm. This version of progressive tax was experimented in several grants on DoraHacks in 2021. The problem of this system is that the distribution of tax still follows proportions of fundings of all projects. Therefore, if the funding gap is normal, the latest funded projects can benefit from the system. If the funding gap is huge, the less funded projects can receive little from tax funding. In reality, quadratic funding often results in big wealth gaps, and this algorithm was abandoned after a few experiments.

Recently, a new quadratic funding tax algorithm was proposed based on reducing the gap between the most matched project and the least matched project while preserving the structure of quadratic voting results. To simplify the problem, the algorithm defines the degree of inequality as the spread between the party receiving the largest amount of funding and the party receiving the smallest amount of funding. In this algorithm, a maximum ratio of the most and least funded is set as a parameter, and the algorithm dynamically adjusts funding results during the voting process whenever the gap exceeds the max ratio. The new tax system will probably be experimented in the upcoming grants.

Conclusion (TL;DR)

• Governance is about the distribution of finite resources and value.

• Governance itself does not create value. However, efficient and fair governance can increase incentives, which increase productivity.

• Real-world governance shares similar problems with blockchain governance.

• Quadratic governance inherits most of the problems from other governance systems, adding some of its own challenges due to its “quadratic” nature.

• Quadratic governance faces three major challenges: identity verification and sybil attacks, collusion, and inequality.

• Anti-sybil and identity verification solutions have tradeoffs, mostly in terms of permissionless-ness, sybil resistance, privacy, and system complexity.

• Collusion can partially be solved by cryptography empowered protocols like MACI, under certain assumptions. More privacy means more complexity.

• Inequality can be harmful and destructive. Similar to solutions in the real world. Tax could potentially help improve distribution quality.

Lastly, governance is an endless game. When a governance system scales, the problem scales, therefore requiring the solutions to scale too. There is a large design space for builders and mechanism designers to work on new solutions and improve existing solutions.