On-Chain Voting

For protocols with upgradeable smart contracts, on-chain voting is the gatekeeper for deploying new code. This is a critical security and governance function. Token holders vote to approve or reject new contract implementations, often following extensive forum discussion and audit. A famous historical example is the Compound Governance Proposal 62, which upgraded the protocol's COMP token distribution mechanism.

Advanced models like liquid democracy allow delegates to be changed at any time, creating dynamic representation. Vote-escrow models (e.g., Curve's veCRV) tie voting power to the duration tokens are locked, aligning long-term holders with protocol health. These mechanisms aim to solve problems like voter apathy and short-term speculation in governance.

A major challenge is Sybil attacks, where one entity creates many wallets to sway votes. Solutions include:

• Proof-of-personhood systems (e.g., BrightID).
• Token-weighted voting, where power is proportional to stake.
• Reputation-based systems that use non-transferable "proof-of-contribution" scores. These ensure governance power reflects genuine, committed participation.

The most common model where voting power is proportional to the number of governance tokens held. This aligns influence with economic stake but can lead to centralization.

• One-token-one-vote: Simple but favors large holders (whales).
• Quadratic voting: Power increases with the square root of tokens held, designed to reduce whale dominance.
• Delegation: Token holders can delegate their voting power to representatives or experts.

The formal process for submitting, debating, and implementing changes via on-chain votes.

• Proposal Submission: A user deposits tokens to create a proposal (e.g., a smart contract upgrade).
• Voting Period: A fixed window (e.g., 3-7 days) for token holders to cast votes.
• Quorum & Threshold: Minimum participation and approval rates required for a proposal to pass.
• Automated Execution: Successful proposals can trigger smart contracts to execute the change (e.g., adjusting a protocol parameter) without manual intervention.

Decentralized Autonomous Organizations (DAOs) use on-chain voting as their primary decision-making engine for treasury management and protocol direction.

• Treasury Control: Votes determine how to allocate funds from the community treasury.
• Parameter Updates: Adjusting fees, rewards, or risk parameters in DeFi protocols.
• Membership & Permissions: Granting or revoking roles within the organization.
• Examples: Compound Governance and Uniswap Governance are canonical examples where token holders vote on all protocol upgrades.

On-chain voting introduces specific technical and game-theoretic challenges.

• Voter Apathy: Low participation can undermine legitimacy and make quorums hard to reach.
• Gas Costs: Paying transaction fees to vote can disincentivize small holders.
• Vote Buying & Manipulation: The transparent and binding nature of on-chain votes can make them targets for economic attacks.
• Speed vs. Security: The deliberation period inherent in voting slows decision-making compared to centralized control.

A hybrid approach where votes are cast off-chain via signed messages (e.g., using Snapshot) but are used to signal community sentiment before an on-chain execution vote.

• Gasless: Users vote by signing a message, incurring no transaction fee.
• Flexible Voting Strategies: Can incorporate token balances at a specific block, delegated voting power, or other criteria.
• Non-Binding: Typically used for temperature checks and gauging consensus before a formal, binding on-chain proposal is submitted.

The transparency of on-chain voting enables explicit vote buying, where a party offers direct payment for specific voting behavior. This undermines the one-token-one-vote principle by allowing capital to concentrate voting power. Common mechanisms include:

• Bribe markets (e.g., platforms like Hidden Hand)
• Token delegation with kickbacks
• Airdrops contingent on past voting history Mitigations include implementing vote escrow models, private voting (e.g., using zk-SNARKs), and resistance to coercion through delayed vote revelation.

If a single entity acquires a majority of voting tokens, they can unilaterally pass any proposal, including draining the treasury. This risk is heightened by:

• Low voter turnout, reducing the effective majority threshold.
• Liquid staking derivatives that may centralize voting power with a few node operators.
• Whale dominance from early investors or foundations. Defenses include a multisig timelock on treasury outflows, progressive decentralization plans, and quorum requirements that scale with proposal significance.

Low participation is a critical security failure, as it makes governance susceptible to capture by a small, motivated group. Causes include:

• High gas costs for voting on-chain.
• Overwhelming proposal volume and complexity.
• Lack of voter incentives ("skin in the game"). This leads to a low quorum problem, where a minority can pass proposals. Solutions involve gasless voting via signature aggregation, delegation to knowledgeable representatives, and participation rewards.

The public and deterministic nature of blockchain allows adversaries to exploit the time between a proposal's submission and execution.

• Snapshot Manipulation: Attacking the mechanism that determines voting power at a specific block.
• Front-Running Execution: Seeing a passed proposal's calldata and executing the profitable transaction first.
• Time-Bandit Attacks: Reorganizing the chain to alter the outcome of a just-concluded vote. Protections include using a secure snapshot tool (e.g., Snapshot.org with signed messages), execution timelocks, and robust consensus finality.

The voting contract itself is a critical attack surface. Exploits can lead to stolen funds or hijacked governance.

• Reentrancy in vote tallying or reward distribution.
• Logic errors in quorum or majority calculation.
• Upgradeability mechanisms that allow a malicious upgrade.
• Governance token contract flaws (e.g., infinite mint). Mitigation requires extensive audits, bug bounties, timelocks on contract upgrades, and gradual rollout of new governance features.

On-chain voting typically uses tokens to represent identity, which can be Sybil-attacked by splitting capital across many addresses to simulate broad consensus. While costly with Proof-of-Stake tokens, it's possible. Related issues include:

• Airdrop farming to create many low-stake voting identities.
• Lack of proof-of-personhood, allowing one entity to control many wallets. Countermeasures can include proof-of-personhood integration (e.g., World ID), vote escrow that penalizes splitting, and reputation-based systems that decay with suspicious activity.