Vote Casting

Vote casting can be executed on-chain or off-chain, each with distinct trade-offs.

• On-chain voting: Votes are recorded as transactions on the blockchain (e.g., Compound, Uniswap). This provides cryptographic verifiability and finality but incurs gas fees.
• Off-chain voting (Snapshot): Votes are signed messages aggregated off-chain, using a cryptographic snapshot of token holdings. This is gasless and faster, but requires a separate execution step to enact proposals.

To reduce voter apathy and consolidate expertise, many protocols use delegation or locking mechanisms.

• Delegated Voting: Token holders can delegate their voting power to representatives (e.g., Compound's Governor Bravo, Optimism's Citizen House).
• Vote-Escrow (ve) Model: Popularized by Curve Finance, this model grants amplified voting power proportional to the amount and duration tokens are locked. This aligns long-term incentives but can lead to power concentration.

Advanced mechanisms aim to better reflect preference intensity and prevent whale dominance.

• Quadratic Voting (QV): The cost of casting additional votes for a single proposal increases quadratically. This limits the influence of large holders and funds many small preferences (e.g., Gitcoin Grants).
• Conviction Voting: Voting power accrues over time a voter's tokens are committed to a proposal, signaling stronger conviction. Used by 1Hive's Gardens for continuous funding decisions.

To improve participation, protocols implement methods to remove the voter's gas fee burden.

• Gasless Relayers: Services like OpenZeppelin Defender or Gelato sponsor transaction gas for voters, submitting votes via meta-transactions.
• Voting Strategies on Snapshot: Off-chain voting platforms allow integrations with ERC-20, ERC-721, and delegation strategies to determine voting power without any on-chain cost for the voter.

Ensuring one-person-one-vote in a pseudonymous system is a critical challenge addressed by various methods.

• Proof-of-Personhood: Projects like BrightID or Worldcoin attempt to verify unique human identity to prevent Sybil attacks.
• Token-Curated Registries (TCRs): Voters must stake tokens to participate, which can be slashed for malicious behavior.
• Minimum Thresholds: Many DAOs require a minimum token balance or delegation to submit or vote on proposals, creating a cost-of-attack barrier.

Major DeFi and L1 protocols showcase diverse vote casting implementations.

• Uniswap: Uses off-chain Snapshot voting for sentiment signaling, with on-chain execution for treasury and fee changes.
• MakerDAO: Employs Executive Votes and Governance Polls, with MKR token holders delegating to Recognized Delegates.
• Cosmos Hub: Utilizes bonded ATOM for on-chain governance, where voting power is directly proportional to staked tokens, with abstain, no, no-with-veto, and yes options.

A Sybil attack occurs when a single entity creates many pseudonymous identities to gain disproportionate voting power. Mitigations include:

• Token-weighted voting: Voting power is proportional to the quantity of a governance token held, making Sybil attacks economically costly.
• Proof-of-personhood systems: Using biometrics or government IDs to ensure one-human-one-vote, though this compromises pseudonymity.
• Delegation: Allows token holders to delegate voting power to trusted experts, consolidating influence but creating centralization risks.

The transparent and predictable nature of on-chain voting enables vote buying, where voters are bribed to vote a certain way. This undermines the protocol's long-term health for short-term gain. Countermeasures include:

• Commit-reveal schemes: Voters submit a hash of their vote first, then reveal it later, making bribes contingent on an unknown outcome.
• Minimum vote locking: Requiring voters to lock their tokens for a period after voting, aligning their incentives with the proposal's long-term effects.
• Private voting using cryptographic techniques like zk-SNARKs to hide individual votes while enabling a verifiable tally.

Because votes are public on-chain, malicious actors can front-run or manipulate vote outcomes based on early results. Key risks include:

• Snapshot manipulation: Exploiting the specific block height used to determine voter eligibility or token balances.
• Last-minute voting: A well-funded actor can swing a close vote at the last block, denying opponents time to respond.
• Proposal spam: Flooding the governance system with proposals to create fatigue and low turnout, making it easier to pass malicious proposals.

The voting smart contract itself is a critical attack surface. Exploits can lead to stolen funds or manipulated outcomes. Common vulnerabilities include:

• Reentrancy attacks: Where malicious code interrupts the voting transaction to change state.
• Logic errors: Flaws in the vote tallying or quorum calculation.
• Upgradeability risks: If the governance contract is upgradeable, a malicious proposal could hijack the upgrade mechanism to take control of the entire protocol. Formal verification and extensive auditing are essential.

Voter apathy creates a security risk by lowering the quorum—the minimum participation required for a vote to be valid. A low quorum allows a small, potentially malicious group to pass proposals that do not reflect the broader community's will. This is exacerbated by gas fees, which disincentivize voting on smaller holdings. Solutions include:

• Gasless voting via meta-transactions or Layer 2 solutions.
• Optimistic voting models that assume participation unless a voter explicitly objects.
• Incentive programs to reward participation.

Token-weighted voting can lead to whale dominance, where a few large holders ("whales") control governance outcomes, recreating centralized power structures. This presents integrity risks if their interests diverge from the network's health. Mitigation strategies include:

• Quadratic voting: Where the cost of a vote increases quadratically with the number of votes cast, limiting large holders' influence.
• Conviction voting: Voting power increases the longer tokens are locked in support of a proposal, favoring long-term alignment.
• Multisig or council models: A delegated body makes decisions, trading off decentralization for efficiency and reduced whale influence.

Voting power quantifies the influence a participant has in a governance vote. It is not always a 1:1 ratio with token holdings.

• Sources: Can be derived from:
  • Simple token balance (1 token = 1 vote).
  • Token delegation (receiving votes from others).
  • Vote-escrowed tokens (veTokens), where power scales with lock-up duration.
• Dynamic: Power can be snapshotted at a specific block to prevent manipulation.

This distinction defines where the vote is recorded and executed.

• On-Chain Voting: Votes are submitted as transactions directly to the blockchain. The proposal execution is often automated via smart contracts. High gas costs, but cryptographically verifiable and enforceable.
• Off-Chain Voting (Snapshot): Votes are signed messages recorded off-chain (e.g., using Snapshot.org). Gas-free and fast, used for sentiment signaling. Requires a separate, trusted process to execute the result.

A quorum is the minimum threshold of total voting power that must participate in a vote for the result to be considered valid.

• Purpose: Prevents a small, unrepresentative group from passing proposals.
• Mechanics: If total votes cast do not meet the quorum, the proposal fails regardless of the yes/no ratio.
• Challenge: Setting quorum is critical; too high can lead to voter apathy, too low risks governance attacks.

Vote delegation allows a token holder (the delegator) to assign their voting power to another address (the delegate) without transferring token ownership.

• Purpose: Enables governance specialization. Less active users can delegate to knowledgeable or active community members.
• Mechanics: Can be specific to a proposal or broad for all future votes.
• Platform Example: Many delegates on Compound or Uniswap publish their voting intentions and rationale.

A proposal is a formal, executable suggestion submitted for a community vote. It is the subject of the vote casting process.

• Components: Includes a title, detailed description, and on-chain actions (e.g., smart contract parameter changes, treasury spends).
• Lifecycle: Typically follows steps: Temperature Check → Consensus Check → Governance Proposal.
• Execution: Successful proposals have their embedded code executed automatically or by a multisig.