How to Implement Quadratic Voting for Fair Governance

In a traditional token-weighted voting system, a single entity with 100 tokens has 100 times the voting power of a member with 1 token. Quadratic Voting rebalances this by making voting power proportional to the square root of the token commitment. For example, a member with 100 tokens would have √100 = 10 votes, while a member with 1 token would have √1 = 1 vote. This reduces the influence of large token holders (whales) and amplifies the voice of the broader community, which is critical for insurance DAOs where risk assessment and claim approval require diverse, expert input.

Implementing QV requires a smart contract that calculates vote weight on-chain. The core logic involves taking the square root of the number of tokens a user commits to a vote. Due to the computational cost and complexity of calculating square roots in Solidity, most implementations use a pre-compiled contract or a library like OpenZeppelin's Math library (which offers a sqrt function since v4.7.0). A basic vote commitment function might look like:

solidityCopy
function commitVote(uint256 proposalId, uint256 tokenAmount) external {
    uint256 voteWeight = sqrt(tokenAmount);
    // Store voteWeight linked to user and proposalId
}

For insurance DAOs, QV is particularly effective for high-stakes decisions like parameter adjustments (e.g., changing premium rates or coverage terms) and claim adjudication. When assessing a complex insurance claim, the DAO needs to weigh technical risk assessments. A quadratic system ensures that ten experts with 1 token each have a collective vote weight of 10, matching the influence of a single whale with 100 tokens, leading to more balanced and technically sound outcomes. This mitigates the risk of a wealthy but less knowledgeable member swaying a critical decision.

A key challenge is Sybil resistance—preventing users from splitting their tokens across many addresses to game the square root calculation. To counter this, implementations often use a commit-reveal scheme or integrate with Proof of Personhood systems like Worldcoin or BrightID. Additionally, many protocols use a vote credit system where members are allocated non-transferable governance credits (based on a snapshot of their token holdings) specifically for voting, which simplifies the square root calculation and prevents last-minute token borrowing to manipulate votes.

When designing the system, DAOs must decide on vote aggregation. The simplest method is summing the square roots of for and against commitments. More advanced systems, like Quadratic Funding used by Gitcoin, can be adapted for insurance to allocate a communal risk pool or grants fund based on the square of the sum of square roots, effectively matching community support. For ongoing governance, frameworks like OpenZeppelin Governor can be extended with a custom voting module that implements the QV logic, providing a secure and upgradeable foundation.

To implement QV successfully, an insurance DAO should start with a pilot program for less critical proposals, use a verified audit library for the sqrt function to prevent math errors, and clearly communicate the mechanism to members. Resources include the original QV paper by Glen Weyl and Vitalik Buterin, and real-world code from projects like Radicle and Gitcoin. By adopting Quadratic Voting, insurance DAOs can create more resilient, fair, and expert-driven governance, essential for managing collective risk.

Quadratic voting (QV) is a governance mechanism where the cost of a vote increases quadratically with the number of votes cast on a single proposal. This design aims to more accurately reflect the intensity of voter preference and prevent whale dominance. To implement it on-chain, you'll need a solid understanding of smart contract development, token standards, and mathematical operations in Solidity. The core formula is cost = (votes_cast)^2, which must be calculated and enforced by your contract's logic to prevent manipulation.

Your primary development toolkit should include Hardhat or Foundry for local development, testing, and deployment. For Ethereum and EVM-compatible chains, you will write contracts in Solidity. Essential libraries include OpenZeppelin Contracts for secure, audited implementations of standards like ERC-20 (for governance tokens) and ERC-1155 (which can be useful for representing voting credits). You'll also need a JavaScript/TypeScript environment (Node.js) for writing tests and deployment scripts, and a wallet like MetaMask for interaction.

The key contract architecture involves at least two main components: a Voting Credit Token and a Quadratic Voting Contract. The token, often a non-transferable ERC-20, represents voting power credits allocated to users. The main contract manages proposals, tracks credit spending using the quadratic cost formula, and tallies results. You must implement checks to ensure a user cannot spend more than sqrt(their_credit_balance) votes on a single option, which is mathematically equivalent to enforcing the quadratic cost.

Security is paramount. Your implementation must guard against common vulnerabilities like integer overflow/underflow (use Solidity 0.8.x or OpenZeppelin's SafeMath libraries), reentrancy attacks, and governance attacks such as flash loan manipulation to acquire temporary voting power. Thoroughly test all edge cases, including the distribution and redemption of credits, the quadratic cost calculation across large numbers, and the finalization of vote results.

For a practical reference, study existing implementations from reputable sources. The RadicalxChange Foundation provides foundational research and examples. On-chain, you can review the source code for projects like Gitcoin Grants, which uses QV for funding allocation. Analyzing these systems will provide insights into gas optimization for costly sqrt calculations and the user experience flow for delegating and casting votes.

Finally, consider the user interface. While not a strict prerequisite for the smart contract developer, planning for front-end integration is crucial. Your contracts should emit clear events for vote casts and proposal state changes. The front-end will need to query these events and user balances, and perform the same quadratic calculations off-chain to display accurate cost previews, ensuring users understand the impact of their voting decisions before submitting transactions.

Quadratic voting (QV) is a collective decision-making procedure where participants allocate voice credits to express their preferences on multiple proposals. Unlike one-person-one-vote, QV uses a cost function where the cost to cast n votes for a single option is n². This mathematical model creates a diminishing marginal utility for additional votes, making it exponentially more expensive to concentrate voting power. The core formula is: cost = (number_of_votes)². To cast 2 votes costs 4 credits, 3 votes costs 9 credits, and so on. This structure forces voters to budget their limited credits across issues they care about most.

Implementing QV requires a smart contract to manage credits, tally votes, and enforce the quadratic cost. A basic Solidity structure involves a proposal mapping and a function that deducts credits based on the square of the vote weight. Key considerations include preventing Sybil attacks through robust identity verification (like proof-of-personhood or soulbound tokens) and securing the vote tally against manipulation. The contract must calculate the sum of the square roots of all votes cast for each option to determine the final outcome, as the winning proposal is the one with the highest sum of square roots.

Here is a simplified code snippet for a quadratic voting contract function:

solidityCopy
function castVote(uint proposalId, uint voteWeight) public {
    uint cost = voteWeight * voteWeight;
    require(userCredits[msg.sender] >= cost, "Insufficient credits");
    userCredits[msg.sender] -= cost;
    votes[proposalId] += sqrt(voteWeight); // Tally square root
}

This function ensures the cost is quadratic while the influence added to the proposal tally is linear (sqrt(voteWeight)). A real implementation needs a secure sqrt function and mechanisms for credit distribution (e.g., equal allocation per epoch).

Quadratic voting is used in Gitcoin Grants for funding public goods, where contributors use a matching pool. Each donor receives a budget of voice credits to distribute across projects, with their influence following the QV formula. This prevents a single large donor from dominating the results and surfaces projects with broad, moderate support. Other applications include DAO governance for budget allocation and policy prioritization. The model's main advantage is its efficiency in capturing preference strength, but it requires careful design to avoid collusion and ensure the credit system is not gamed.

When designing a QV system, critical parameters must be defined: the total credit supply per voter, the voting period, and the proposal submission process. Auditing the contract for rounding errors in the square root calculation and front-running vulnerabilities is essential. Furthermore, the revelation period—where votes are hidden until the end to prevent strategic copying—enhances fairness. While computationally more expensive than linear voting, QV provides a more nuanced and democratic outcome for resource allocation in decentralized communities, making it a powerful tool for on-chain governance.

Quadratic voting (QV) is a mechanism designed to produce more democratic outcomes in token-based governance by diminishing the influence of large token holders (whales). Instead of a simple one-token-one-vote system, a voter's influence is proportional to the square root of the number of tokens they commit to a proposal. This means that to double your voting power, you must commit four times the tokens. The formula for calculating voting power is sqrt(tokens_committed). This mathematical property makes it economically inefficient for a single entity to dominate a vote, promoting broader participation and more nuanced expression of preference intensity.

Implementing QV requires careful smart contract design to handle the math and state management securely. The core contract must track each voter's commitment per proposal, calculate the square root, and sum the results. Since calculating a square root on-chain is computationally expensive with native Solidity, it's standard to use an approximation library like OpenZeppelin's Math library (which provides sqrt). A basic storage structure involves a nested mapping: mapping(uint256 proposalId => mapping(address voter => uint256 commitment)) public commitments. To vote, a user calls a function that locks their tokens and updates this mapping, with the contract calculating and storing the derived sqrtVotingPower.

Here is a simplified example of a QuadraticVoting contract snippet:

solidityCopy
import "@openzeppelin/contracts/utils/math/Math.sol";
contract QuadraticVoting {
    using Math for uint256;
    struct Proposal {
        uint256 totalVotingPower;
        bool executed;
    }
    mapping(uint256 => Proposal) public proposals;
    mapping(uint256 => mapping(address => uint256)) public commitments;
    IERC20 public governanceToken;
    function vote(uint256 proposalId, uint256 amount) external {
        governanceToken.transferFrom(msg.sender, address(this), amount);
        uint256 previousCommitment = commitments[proposalId][msg.sender];
        uint256 newCommitment = previousCommitment + amount;
        commitments[proposalId][msg.sender] = newCommitment;
        uint256 oldPower = previousCommitment.sqrt();
        uint256 newPower = newCommitment.sqrt();
        proposals[proposalId].totalVotingPower += newPower - oldPower;
    }
}

This function transfers tokens, calculates the change in square root voting power, and updates the proposal's total.

Key security and design considerations are paramount. The contract must prevent double-voting and ensure tokens are locked only for the vote's duration. A common pattern is to use a timelock or a specific voting period. The square root calculation must be guarded against overflow and precision loss—using a library like OpenZeppelin's handles this. Furthermore, to mitigate Sybil attacks (where users split holdings into many addresses to game the sqrt function), many implementations integrate a proof-of-personhood or sybil-resistance layer like BrightID or Gitcoin Passport. The cost of voting, in terms of gas fees for the sqrt calculation and storage updates, should also be evaluated, as it can be higher than a simple token vote.

Quadratic voting is effectively used in decentralized grant funding platforms like Gitcoin Grants, where it helps allocate matching funds based on community sentiment rather than pure capital. When integrating QV, you must decide on the vote aggregation method (e.g., sum of square roots) and the token release mechanism after the vote concludes. For production use, consider auditing the contract and using a battle-tested library for math operations. This mechanism, while more complex, offers a compelling trade-off for communities seeking governance that balances capital influence with broader member participation.

Quadratic voting (QV) is a governance mechanism where the cost of a vote increases quadratically with the number of votes cast. A user casting n votes for a proposal pays a cost proportional to n². This design makes it economically prohibitive for a single large token holder (a "whale") to dominate outcomes, as their voting power scales linearly with tokens but their cost scales quadratically. The core formula is: cost = (votes_cast)². In our smart contract, we will implement this using a credit-based system where users spend governance credits, not directly their tokens, to vote.

We start by defining the contract state. We need to track each voter's remaining credits, their votes per proposal, and the total votes for each proposal. We'll use a credits mapping for balances and a nested mapping votes[proposalId][voter] to store individual votes. The proposal's total tally is the sum of the square roots of each voter's contribution: totalVotes = Σ √(votes[proposalId][voter]). This square root calculation is critical—it's how quadratic cost translates into linear voting power. We must perform this math off-chain or using a precomputed lookup table, as Solidity's sqrt function is expensive and only works with integers.

The voting function is the heart of the contract. When a user calls vote(uint proposalId, uint voteAmount), the contract first calculates the cost: cost = voteAmount * voteAmount. It then checks if the user has sufficient credits, deducts the cost, and updates the vote records. Crucially, we must also update the proposal's total. Since we store raw vote amounts, we calculate the change in voting power: newVotingPower = sqrt(newTotalVotesForVoter) and oldVotingPower = sqrt(oldTotalVotesForVoter). The proposal's totalVotes is then adjusted by (newVotingPower - oldVotingPower). This avoids having to loop over all voters to recalculate the total.

Security considerations are paramount. The contract must prevent double-voting and ensure credits cannot be inflated. We use the Checks-Effects-Interactions pattern and reentrancy guards. A major challenge is the quadratic cost calculation itself. A malicious actor could exploit the voteAmount * voteAmount multiplication to cause an integer overflow. We must use SafeMath libraries or Solidity 0.8.x's built-in overflow checks. Furthermore, to keep gas costs predictable, we should impose a maximum voteAmount per transaction. Events should be emitted for all state changes to allow off-chain indexers to track voting power correctly.

Finally, here is a simplified code snippet illustrating the core vote logic. Note that this example uses Solidity 0.8.x and omits access controls and some state variables for brevity.

solidityCopy
function vote(uint proposalId, uint voteAmount) external {
    uint cost = voteAmount * voteAmount; // Quadratic cost
    require(credits[msg.sender] >= cost, "Insufficient credits");
    require(voteAmount <= MAX_VOTE_AMOUNT, "Vote amount too high");

    uint oldVotes = votes[proposalId][msg.sender];
    uint newVotes = oldVotes + voteAmount;

    // Update state: Checks-Effects-Interactions
    credits[msg.sender] -= cost;
    votes[proposalId][msg.sender] = newVotes;

    // Update proposal total (sqrt calculations done off-chain for efficiency)
    // In practice, you would update an off-chain tally or use an oracle.
    emit Voted(msg.sender, proposalId, voteAmount, cost);
}

This contract would be integrated with a credit distribution mechanism (e.g., based on token snapshot or NFT ownership) and an off-chain aggregator that calculates the final sqrt-based results for each proposal.

To deploy this in production, you must complete the system: 1) A credit minting function (e.g., one credit per token held in a snapshot), 2) An off-chain indexer (using The Graph or an event listener) to calculate the true voting power sqrt(votes) for each proposal, and 3) A timelock or execution module to enact proposals that pass. Real-world implementations like Gitcoin Grants use quadratic funding, a related concept, to match community donations. By implementing QV, your DAO can make more balanced decisions that reflect the breadth of community support rather than the depth of a single wallet.

Quadratic voting (QV) is a governance mechanism designed to more accurately reflect the intensity of voter preference and mitigate the influence of large token holders (whales). Unlike simple token-weighted voting, where one token equals one vote, QV uses a square root function. A voter with n tokens receives sqrt(n) voting power. This means a user with 10,000 tokens gets 100 voting power, while a user with 100 tokens gets 10 voting power, significantly flattening the power curve. Snapshot supports this model natively through its flexible voting strategies, allowing DAOs to implement fairer decision-making processes.

To implement quadratic voting in Snapshot, you must configure a custom voting strategy. The core logic is defined in a strategy file, typically written in JavaScript/TypeScript, that calculates each voter's power. The essential formula is Math.sqrt(balance). You can fetch a voter's token balance from an ERC-20 contract using a provider like Multicall. Here is a simplified strategy skeleton:

javascriptCopy
export const author = 'your-handle';
export const version = '0.1.0';

export async function strategy(space, network, provider, addresses, options) {
  const balances = await getBalances(); // Fetch token balances
  return Object.fromEntries(
    addresses.map((address) => [
      address,
      Math.sqrt(balances[address] || 0)
    ])
  );
}

This function returns an object mapping each voter's address to their square-rooted voting power.

For a production-ready implementation, you must handle edge cases and connect to real data. Use the @snapshot-labs/snapshot.js library and a Multicall contract to efficiently fetch balances for multiple addresses in a single RPC call. Your strategy's options parameter should specify the token contract address and the network. It's also crucial to consider token decimals in your calculation. A robust strategy normalizes the balance before applying the square root. After developing your strategy, you must publish it to a public repository like GitHub and register it on Snapshot's strategy page, providing the author, version, and source code URL for verification.

When creating a proposal in your Snapshot space, select "Quadratic Voting" from the voting type dropdown. You will then link to your custom strategy. Snapshot will use it to calculate voting power at the block number specified when the proposal is created (the snapshot block). It's important to test your strategy thoroughly using Snapshot's Playground or a testnet deployment before using it for mainnet proposals. Consider additional refinements like: - Adding a minimum balance threshold to prevent sybil attacks with dust amounts. - Implementing cost scaling where voters can allocate votes across multiple choices, with the total cost being the sum of the squares of votes per choice. - Using voice credits instead of direct token balances for more abstract governance.

Quadratic voting introduces unique game theory and UX considerations. Voters must understand that their influence scales sub-linearly with their holdings. Frontends should clearly display the calculated sqrt power, not the raw token balance. While QV reduces whale dominance, it can be more susceptible to sybil attacks (splitting tokens among many addresses). Mitigations include incorporating proof-of-personhood systems like BrightID or using a cost function that makes sybil strategies economically irrational. Successful implementations include Gitcoin Grants, which uses QV to fund public goods, and several smaller DAOs experimenting with more nuanced governance. By implementing QV, you move from pure capital-based governance to a system that better aggregates the preferences of a broader community.

Quadratic voting (QV) is a governance mechanism where participants allocate a budget of voice credits, with the cost of additional votes for a single proposal increasing quadratically. This design aims to more accurately reflect the intensity of voter preference compared to one-person-one-vote systems. In a smart contract implementation, core functions include vote(proposalId, votes) and getCost(votes), where the cost is votes². A primary security consideration is ensuring the cost calculation is protected from integer overflow, especially in Solidity versions prior to 0.8.0, which requires the use of libraries like OpenZeppelin's SafeMath.

Testing must simulate realistic attack vectors. Key unit tests should verify: the quadratic cost formula (1 vote = 1 credit, 2 votes = 4 credits, 3 votes = 9 credits), that a user cannot exceed their voice credit budget, and that votes cannot be cast on non-existent or closed proposals. Use a framework like Hardhat or Foundry to write these tests. For example, a Foundry test would assert that vm.expectRevert() is called when a user tries to spend more credits than they have. Fuzz testing with random vote amounts can help uncover edge cases in the mathematical logic.

A critical vulnerability in QV is the Sybil attack, where an attacker creates multiple identities to split their capital and influence votes more cheaply. Mitigation requires a robust identity or proof-of-personhood system, such as BrightID or Worldcoin, to issue a single voting budget per unique human. The contract must integrate a verifier for these credentials. Without this, the quadratic cost model's fairness is nullified. Additionally, consider implementing a commit-reveal scheme to prevent tactical voting based on early results, adding a layer of complexity that must be thoroughly tested.

Formal verification and audit are essential before mainnet deployment. Tools like Certora or Scribble can be used to formally specify and prove properties like "the sum of all costs never exceeds the total supply of voice credits." Engage a professional audit firm to review the code, focusing on the voting logic, credit accounting, and integration with any external identity oracles. Document all assumptions, such as the trust model of the identity provider. Finally, deploy the contract to a testnet and run a live governance simulation with a diverse group of users to uncover UX issues and finalize parameter tuning like credit allocation.

You now have a foundational understanding of quadratic voting (QV) and a basic implementation using a smart contract on Ethereum. The key takeaways are: QV mitigates the "tyranny of the majority" by making the cost of additional votes increase quadratically, it requires a secure identity verification mechanism like Proof of Personhood to prevent Sybil attacks, and the results are calculated by summing the square roots of each voter's allocated credits. This system is actively used in protocols like Gitcoin Grants for public goods funding and by various DAO governance frameworks to achieve more nuanced community sentiment.

To move from a proof-of-concept to a production system, several critical enhancements are needed. First, integrate a robust Sybil resistance layer. While a simple mapping was used here, real systems rely on solutions like BrightID, Worldcoin's Proof of Personhood, or Gitcoin Passport. Second, implement a secure front-end for the voting interface and result visualization. Third, add administrative functions to manage voting rounds—opening, closing, and finalizing them—and potentially a timelock for executing passed proposals. Always conduct thorough audits on the vote tallying and credit calculation logic.

For further learning, explore existing implementations and research. Study the Gitcoin Grants smart contracts on GitHub to see a battle-tested QV system. Read the original paper, "Liberal Radicalism" by Vitalik Butler, Zoë Hitzig, and E. Glen Weyl, which formalizes the mechanism. Experiment with frameworks like Snapshot which supports QV strategies for off-chain signaling. Consider advanced variations like Quadratic Funding for matching pools or Conviction Voting for continuous preference signaling. The goal is to adapt the core quadratic cost principle to create fairer, more resilient governance for your specific community or application.