Comparing Token Voting and Quadratic Voting in DAOs

LABS

Comparing Token Voting and Quadratic Voting in DAOs

Core Governance Concepts

Foundational mechanisms and models that define how decentralized organizations make collective decisions.

Token Voting

One-token-one-vote is a governance model where voting power is directly proportional to the quantity of governance tokens held.

Power is concentrated among large token holders (whales).
Enables straightforward vote tallying and execution.
Can lead to plutocracy, where capital dictates outcomes over member consensus.

Quadratic Voting

Quadratic voting (QV) allocates voting power based on the square root of tokens committed, costing votes quadratically.

Users can express preference intensity by spending more voice credits.
Designed to mitigate whale dominance and better reflect the strength of preference.
Requires a credit system or bonding curve, adding implementation complexity.

Vote Delegation

Delegative democracy allows token holders to delegate their voting power to representatives or experts.

Reduces voter apathy by lowering participation overhead for casual members.
Can lead to the emergence of professional delegates or governance guilds.
Introduces principal-agent problems, requiring reputation systems and accountability.

Proposal Lifecycle

The governance process defines the stages a proposal moves through from ideation to execution.

Typically includes: Temperature Check, Consensus Check, and Governance Vote.
Requires predefined thresholds for quorum and passing margins.
Smart contract timelocks are often used to allow for review before code execution.

Sybil Resistance

Sybil resistance refers to mechanisms that prevent a single entity from controlling multiple voting identities.

Token voting relies on token cost as a Sybil barrier.
Quadratic voting incorporates cost scaling to reduce Sybil attack profitability.
Alternative methods include proof-of-personhood or social graph attestations.

Forking as Governance

The exit-to-fork mechanism is the ultimate governance action, allowing dissenters to create a new chain with different rules.

Serves as a credible threat against governance capture or malicious proposals.
Requires token holders to migrate assets and liquidity, creating a high coordination cost.
Exemplifies the "code is law" principle in decentralized systems.

Voting Mechanism Deep Dive

Understanding the Core Models

Token Voting and Quadratic Voting (QV) are two primary systems for collective decision-making in DAOs. Token Voting is a one-token-one-vote system where voting power is directly proportional to the number of governance tokens held. This is common in protocols like Uniswap and Compound. In contrast, Quadratic Voting is a one-person-one-vote system where participants receive a budget of "voice credits" to allocate across proposals. The key innovation is that the cost of additional votes on a single proposal increases quadratically, making it expensive to concentrate power.

Key Differences

Power Distribution: Token Voting can lead to plutocracy, where large holders dominate. QV aims to better reflect the intensity of preferences of a broader group.
Sybil Resistance: Token Voting relies on token ownership. QV often requires identity verification (like BrightID or Proof of Humanity) to prevent creating multiple identities.
Use Cases: Token Voting is standard for protocol parameter updates. QV is often piloted for public goods funding, as seen in Gitcoin Grants rounds.

Example Scenario

In a Uniswap DAO proposal to adjust a fee parameter, a whale with 10,000 UNI tokens has 10,000 votes. In a QV system for a community grant, a member might spend 9 credits to cast 3 votes (3² = 9) on a project they strongly support, preserving credits for other proposals.

Model Comparison: Trade-offs and Implications

Direct comparison of key operational and governance characteristics between Token Voting and Quadratic Voting models.

Feature	Token Voting (1p1v)	Quadratic Voting (QV)	Implications
Voter Influence Scaling	Linear: 1 token = 1 vote	Quadratic: cost = votes²	QV reduces whale dominance; 1p1v concentrates power.
Sybil Attack Resistance	High: Costly to acquire tokens	Low: Requires identity verification (e.g., Proof of Personhood)	QV necessitates robust, often centralized, sybil prevention.
Voter Participation Cost	Gas fees for on-chain voting only	Gas fees + potential cost for additional vote credits	QV can increase financial barriers for expressing strong preferences.
Decision-Making Speed	Fast: Simple tally, instant results	Slower: Requires credit calculation and potential dispute periods	QV's complexity can delay execution of governance actions.
Implementation Complexity	Low: Native to most DAO frameworks (e.g., Snapshot, Tally)	High: Requires custom logic for sqrt costing and credit management	QV increases audit surface and potential for smart contract bugs.
Voter Expressiveness	Binary: For/Against/Abstain per proposal	Graded: Can allocate intensity of preference across options	QV enables more nuanced outcomes but can lead to vote 'gaming'.
Capital Efficiency for Voters	Inefficient: Capital locked in voting tokens	Efficient: Uses credits; capital remains liquid	QV improves capital utility but may dilute token's governance utility.
Result Legitimacy Perception	Often contested ("tyranny of the majority")	Theoretically higher (reflects breadth & intensity)	Perceived legitimacy of QV depends on trust in identity system.

Implementing Voting Systems

Process overview

Define Governance Parameters and Token Setup

Establish the foundational rules and token configuration for the voting system.

Detailed Instructions

Begin by defining the core governance parameters that will govern all proposals. This includes setting the minimum quorum (e.g., 10% of total supply), voting delay (e.g., 2 days), voting period (e.g., 7 days), and proposal threshold (e.g., 0.5% of supply). For token-based voting, ensure your ERC-20 or ERC-721 token contract is deployed and its address is whitelisted in the governor contract. For quadratic voting, you must also deploy a separate contract to calculate vote weights.

Sub-step 1: Deploy your governance token contract (e.g., using OpenZeppelin's ERC20Votes).
Sub-step 2: Write and deploy the Governor contract, passing the token address and parameters to its constructor.
Sub-step 3: Verify the Governor contract has the correct token address and parameter values set.

solidity
// Example constructor for an OpenZeppelin Governor contract
constructor(IVotes _token, TimelockController _timelock, uint256 _votingDelay, uint256 _votingPeriod, uint256 _proposalThreshold)
    Governor("MyDAOGovernor")
    GovernorVotes(_token)
    GovernorVotesQuorumFraction(4) // 4% quorum
    GovernorTimelockControl(_timelock)
{
    votingDelay = _votingDelay;
    votingPeriod = _votingPeriod;
    proposalThreshold = _proposalThreshold;
}

Tip: Use a TimelockController for executing successful proposals to introduce a mandatory delay, preventing malicious or rushed execution.

Implement the Core Voting Logic

Code the specific vote counting and weight calculation mechanisms.

Detailed Instructions

This step involves writing the internal logic that tallies votes. For standard token voting, this is often handled by inherited contracts like GovernorVotes. For quadratic voting, you must implement a custom voting module. The key function is _countVote, which determines how a voter's balance translates into voting power. Quadratic voting requires calculating the square root of the token amount used, which must be done securely off-chain or using an oracle to avoid high gas costs from on-chain sqrt.

Sub-step 1: If using token voting, inherit from GovernorVotes which uses token.getPastVotes for snapshot-based voting.
Sub-step 2: For quadratic voting, create a contract that overrides _countVote to calculate weight = sqrt(amount).
Sub-step 3: Integrate a verifiable randomness function or oracle (like Chainlink VRF) if implementing randomized elements for anti-sybil measures.

solidity
// Simplified override for quadratic vote counting (requires secure sqrt)
function _countVote(
    uint256 proposalId,
    address account,
    uint8 support,
    uint256 weight,
    bytes memory params
) internal virtual override {
    // params could contain a pre-calculated, verified sqrt from an oracle
    uint256 quadraticWeight = sqrt(weight); // Implement secure sqrt
    _proposalVotes[proposalId].votes[account][support] += quadraticWeight;
}

Tip: Due to gas constraints, consider having voters submit a pre-calculated quadratic weight along with a cryptographic proof (e.g., a Merkle proof) instead of computing sqrt on-chain.

Create and Submit a Proposal

Walk through the process of forming and launching a governance proposal.

Detailed Instructions

Proposals bundle executable calls with metadata. Using the Governor's propose function, you submit an array of target addresses, values, and calldata for the actions to execute if the proposal passes. You must also provide a description hash (keccak256 of the description). Ensure the proposer's token balance meets the proposal threshold. The contract will snapshot voting power at the block determined by votingDelay.

Sub-step 1: Encode the function calls for your proposal (e.g., calling transfer on a treasury contract).
Sub-step 2: Calculate the description hash: keccak256(bytes(description)).
Sub-step 3: Call propose(targets, values, calldatas, descriptionHash) from an address holding enough tokens.
Sub-step 4: Monitor the transaction to get the returned proposalId for tracking.

solidity
// Example of forming proposal data
address[] memory targets = new address[](1);
targets[0] = treasuryAddress;
uint256[] memory values = new uint256[](1);
values[0] = 0;
bytes[] memory calldatas = new bytes[](1);
calldatas[0] = abi.encodeWithSignature("transfer(address,uint256)", recipient, 1e18);
string memory description = "Send 1.0 ETH from treasury to contributor for Q1 rewards.";
bytes32 descriptionHash = keccak256(bytes(description));

uint256 proposalId = governor.propose(targets, values, calldatas, descriptionHash);

Tip: Use a front-end library like Tally or Boardroom to abstract this process for end-users, handling calldata encoding and hash generation.

Cast Votes and Execute the Proposal

Guide voters through the voting process and the final execution step.

Detailed Instructions

During the voting period, token holders call castVote or castVoteWithReason. The contract checks their voting power at the proposal's snapshot block. For quadratic voting, they may need to specify an amount parameter. After the voting period ends, anyone can call queue to move a successful proposal to the Timelock queue. After the timelock delay expires, the execute function can be called to run the proposal's encoded calls. Always verify state changes and gas costs before execution.

Sub-step 1: Voters call castVote(proposalId, support) where support is 0=Against, 1=For, 2=Abstain.
Sub-step 2: Once the vote passes quorum and majority, call queue(proposalId) to schedule execution.
Sub-step 3: Wait for the timelock delay (e.g., 48 hours).
Sub-step 4: Call execute(proposalId) to perform the proposed actions on-chain.

solidity
// Example voting and execution flow
// 1. Vote
governor.castVote(proposalId, 1); // Vote 'For'
// 2. After vote succeeds, queue it (if using a timelock)
governor.queue(proposalId);
// 3. After delay, execute
(bool success, ) = governor.execute(proposalId);
require(success, "Execution failed");

Tip: Use the reason parameter in castVoteWithReason to create a transparent record of voter rationale, which is emitted as an event and can be indexed by off-chain analytics.

Protocol Case Studies

Analysis of real-world implementations showcasing the trade-offs between token-based and quadratic voting governance models.

Compound Governance

Delegated token voting powers this leading lending protocol. Votes are weighted by COMP token holdings, enabling efficient execution but concentrating influence among large holders. The system uses a timelock for execution and a formal proposal process. This model prioritizes decisiveness and security, demonstrating the strengths of a pure capital-weighted approach for technical upgrades.

Gitcoin Grants

Pioneered quadratic funding for public goods, a related application of quadratic voting principles. Contributions are matched based on the square root of the number of contributors, not the total amount. This effectively measures community preference, diluting whale power. It showcases how quadratic mechanics can better aggregate broad sentiment and fund under-monetized projects.

Optimism Collective

Implements a bicameral system separating token voting for technical decisions from citizen-based voting for grants. The Citizen's House uses a one-person-one-vote model via non-transferable NFTs. This hybrid structure attempts to balance capital efficiency with broad-based legitimacy, offering a case study in mitigating pure plutocracy by segregating governance domains.

MolochDAO v2

Utilizes a ragequit mechanism within a share-based, token-voting framework. Members can exit with their proportional treasury share if they disagree with a funding decision. This creates a powerful check on majority power and aligns incentives. The model highlights how exit rights can be a crucial safety valve in token-based governance, enhancing resilience.

Snapshot with QV

The off-chain voting platform supports plug-in strategies, including quadratic voting. Projects can configure voting power as the square root of token balance or using other credentials. This allows for experimentation without on-chain cost, demonstrating the flexibility of QV for signaling and gauging community sentiment before committing on-chain resources.

SECTION-FAQ

Comparing Token Voting and Quadratic Voting in DAOs

Comparing Token Voting and Quadratic Voting in DAOs

Core Governance Concepts

Token Voting

Quadratic Voting

Vote Delegation

Proposal Lifecycle

Sybil Resistance

Forking as Governance

Voting Mechanism Deep Dive

Understanding the Core Models

Key Differences

Example Scenario

Model Comparison: Trade-offs and Implications

Implementing Voting Systems

Define Governance Parameters and Token Setup

Detailed Instructions

Implement the Core Voting Logic

Detailed Instructions

Create and Submit a Proposal

Detailed Instructions

Cast Votes and Execute the Proposal

Detailed Instructions

Protocol Case Studies

Compound Governance

Gitcoin Grants

Optimism Collective

MolochDAO v2

Snapshot with QV

Governance Model FAQ

Further Reading and Resources

Snapshot Documentation

Compound Protocol Governance

Quadratic Payments: A Primer

Gitcoin Quadratic Funding Docs

Let's bring your Web3 vision to life.