Governance is the decision-making system of a protocol. The architecture of voting determines who manages the treasury, changes parameters, and steers the project’s development. Poorly designed governance becomes voting theater, where decisions are made before the formal process even begins.
Why Governance Matters
A protocol is a set of parameters that someone must change:
- Economic parameters: fees, interest rates, emission size, reward distribution
- Technical parameters: smart contract upgrades, new markets, collateral factors
- Treasury decisions: expenditures, grants, investments, incentive programs
- Strategic decisions: integrations, partnerships, mission changes
In a centralized company, management makes these decisions. In a decentralized protocol — token holders do, through governance.
Model 1: Token-Weighted Voting (1 Token = 1 Vote)
The simplest and most common model. Vote weight is proportional to token holdings.
Mechanics
- A holder locks tokens for voting (or uses Snapshot for off-chain voting)
- Each token grants one vote
- A proposal passes if it reaches quorum and a majority of votes
Quorum Formulas
- V — number of tokens that voted
- G — total tokens with voting rights
- V_for — votes in favor
- V_against — votes against
- Typical threshold: 50% (simple majority) or 66.7% (supermajority)
Example quorum calculation for a DAO with 100M tokens:
- Participation quorum: 4% (4M tokens must vote)
- Approval quorum: >50% (simple majority)
- Proposal creation threshold: 0.1% (100K tokens) or delegated votes
Problems
Plutocracy. Large holders (whales) control voting outcomes. If 3 wallets hold 40% of tokens, they can block or push through any decision.
Apathy. Typical DAO voting turnout is 3–5% of eligible tokens. With a 4% quorum, a small group can gain control.
Vote-renting (flash-loan attacks). An attacker borrows tokens via flash loan, votes, and returns the loan in the same transaction — the attack cost equals loan interest, not the token price. This is distinct from bribery: here the attacker controls the vote directly for a single block. MakerDAO was exposed to a flash-loan governance attack in 2020; Beanstalk lost $182M to one in 2022.
Bribery (gauge wars). A separate phenomenon: markets like Votium, Hidden Hand, and Convex pay ve-token holders to direct emissions toward specific pools. Unlike vote-renting, bribery is an economically legitimate long-term payment to vote directors — the attacker doesn’t take control of the tokens, they pay the legitimate holders to vote a certain way.
When It Fits
Token-weighted voting works for simple, low-risk decisions: adding a new market, changing minor parameters. For treasury decisions and contract upgrades, additional safeguards are needed (timelock, multisig veto, quorum guards).
Model 2: Quadratic Voting (QV)
Quadratic voting reduces whale influence by making each additional vote more expensive.
Mechanics
In QV, votes are purchased with “voice credits.” The cost grows quadratically:
- 1 vote = 1 credit
- 2 votes = 4 credits
- 3 votes = 9 credits
- 10 votes = 100 credits
- Inverse formula: a holder with 100 credits gets 10 votes
- A holder with 10,000 credits gets 100 votes (not 100x more)
Comparison with Token-Weighted
For illustration, we assume 1 token = 1 voice credit (pedagogical simplification — in a real QV system, credits are typically allocated separately from token holdings).
| Token count | Votes (1T=1V) | Votes (QV) | Difference |
|---|---|---|---|
| 100 | 100 | 10 | 10x less |
| 1,000 | 1,000 | ~31.6 | 31.6x less |
| 10,000 | 10,000 | 100 | 100x less |
| 1,000,000 | 1,000,000 | 1,000 | 1,000x less |
QV radically narrows the gap: in token-weighted voting, a whale with 1M tokens has 10,000x more influence than a holder with 100. In QV — only 100x.
The Sybil Attack Problem
QV’s main vulnerability is sybil attacks: an attacker distributes tokens across many wallets and gains more votes in aggregate than from a single address.
- N — number of sybil wallets
- S — total tokens held by the attacker
- One wallet with S tokens gets √S votes in QV
- N sybil wallets with S/N tokens each get N · √(S/N) = √N · √S = √(N·S) votes in aggregate
- For N > 1, √(N·S) > √S, so splitting into sybils gains the attacker more voting power
- Without sybil protection, QV collapses back toward linear (token-weighted) voting as N grows
Solutions:
- Proof of personhood (Gitcoin Passport, Worldcoin) — tying to real identity
- Social graph — analyzing connections between addresses
- Participation threshold — minimum transaction history or staking to vote
Examples
Gitcoin Grants. Uses quadratic funding — an extension of QV for grant distribution. Many small donations carry more weight than one large one.
When It Fits
QV is effective for resource allocation (grants, budgets) and prioritization (which of 10 projects to fund). For binary decisions (yes/no), QV’s advantages are less pronounced. Requires a sybil protection mechanism.
Model 3: Conviction Voting
Conviction voting introduces a time factor: the longer votes are directed at a proposal, the stronger their “conviction.”
Mechanics
- A holder directs tokens toward a proposal
- Conviction accumulates exponentially using a half-life formula
- When conviction reaches a threshold dependent on the requested amount, the proposal executes
- Switching votes to another proposal resets accumulated conviction
- C(t) — conviction at time t
- C_prev — conviction at the previous time step
- α — decay parameter (0.9 for slow accumulation)
- tokens — number of tokens directed
- ρ — minimum confidence parameter
- S — total token supply
- Amount — requested amount
- Fund — total fund size
- β — sensitivity to request size
Advantages
- Flash attack protection — instant vote buying is useless, conviction accumulates slowly
- Continuous voting — no hard deadlines, proposals live until reaching threshold or vote withdrawal
- Proportional threshold — large treasury requests require more conviction than small ones
Examples
1Hive / Gardens. Uses conviction voting for DAO treasury distribution. Small requests execute quickly; large ones require lengthy and broad consensus.
When It Fits
Conviction voting is ideal for continuous treasury allocation and situations where manipulation protection matters. Not suitable for urgent decisions (security updates) — conviction accumulation takes days or weeks.
Model 4: Vote-Escrow (ve-Model)
The ve-model ties vote weight to lock duration. Longer lock = more votes and rewards. For a detailed economic analysis, see the veTokenomics article.
Mechanics
- veToken — voting token balance
- Token — locked tokens
- t_lock — lock duration
- t_max — maximum lock duration
- ve-tokens decay linearly until unlock
ve-token holders receive three benefits:
- Governance vote — proportional to ve-token holdings
- Fee share — revenue share from protocol income
- Boost — enhanced LP rewards
Gauge Voting
The key ve-model mechanic is gauge voting: ve-token holders vote on how emissions are distributed across liquidity pools.
ve-Model Cycle
Vote Wars
Gauge voting creates a bribe ecosystem: protocols pay ve-token holders to direct emissions toward their pools. Convex Finance aggregates veCRV and lets CVX holders vote on emission direction, creating “meta-governance” — governing the governors.
Examples
Curve Finance (veCRV). The ve-model standard. Lock up to 4 years. Historically a majority of circulating CRV has been locked in veCRV (typically 40–50%+ depending on the incentive cycle — check Curve UI / DefiLlama for the current snapshot), radically reducing circulating supply.
Velodrome / Aerodrome. ve-model for DEXs on Optimism and Base. veVELO holders vote on emission distribution and receive 100% of fees from the pools they voted for (not distributed across all pools).
When It Fits
The ve-model is for protocols with established TVL and revenue. It’s complex to implement and requires a critical mass of participants. For early-stage projects, the ve-model may be overkill.
Model Comparison
Four voting models
| Parameter | Token-Weighted | Quadratic | Conviction | ve-Model |
|---|---|---|---|---|
| Complexity | Low | Medium | High | High |
| Whale resistance | No | Yes | Partial | Partial (time) |
| Flash attack protection | Timelock | Timelock | Built-in | Built-in (lock) |
| Sybil protection needed | No | Critical | No | No |
| Decision type | Binary | Resource allocation | Continuous funding | Emission control |
| Decision speed | 3–7 days | 3–7 days | Days–weeks | 1 epoch (7 days) |
| Participation incentive | Low | Medium | Medium | High (revenue) |
| Examples | Compound, Uniswap | Gitcoin | 1Hive | Curve, Velodrome |
Architecture: On-Chain vs Off-Chain
On-Chain Governance
Voting occurs on the blockchain. Results are executed automatically by smart contract.
| Component | Description |
|---|---|
| Governor | Smart contract for creating and executing proposals (OpenZeppelin Governor, Compound Governor Bravo, Uniswap Governor Bravo) |
| Timelock | Delay between approval and execution (typically 24–48 hours) |
| Token | Voting token (ERC-20Votes) with delegation |
Advantages: full transparency, automatic execution, censorship-resistant results. Disadvantages: high gas costs, low turnout, rigid process.
Off-Chain Governance (Snapshot)
Voting via signatures without transactions. Results are executed manually (multisig) or via a bridge.
Advantages: free for voters, flexible voting strategies, higher turnout. Disadvantages: execution depends on multisig trust, no execution guarantee.
Hybrid Model
Most mature DAOs use a hybrid:
- Snapshot for signal voting (temperature check)
- On-chain Governor for final approval and execution
- Multisig (5/9 or 4/7) as an emergency mechanism and for operational decisions
Typical governance pipeline: from idea to execution
Governance Security
Common Attacks
| Attack | Description | Defense |
|---|---|---|
| Flash loan | Borrow tokens → vote → return in one block | Snapshot balance N blocks before voting |
| Bribery | Buying votes via bribe protocols | Conviction voting, long lock periods |
| Treasury capture | Proposal to withdraw funds to self | Timelock + veto + per-transaction limits |
| Governance stalemate | Blocking voting with a controlling stake | Optimistic governance (veto instead of approval) |
| Poison pill | Disguised malicious proposal | Mandatory code audit + timelock for review |
Security Checklist
Governance Security Checklist
Designing Governance: A Framework
Step 1: Classify Parameters
Divide all governance-managed parameters into categories by risk level:
| Category | Examples | Governance mechanism |
|---|---|---|
| Critical | Contract upgrades, treasury changes >10% | On-chain vote + timelock + veto |
| Significant | Fees, collateral factors, new markets | On-chain or Snapshot + multisig execution |
| Routine | Small grants, reward parameters | Delegated committees |
| Technical | Oracles, gas limits | Automation (algorithms) |
Step 2: Choose the Voting Model
The choice depends on the types of decisions the DAO makes:
Choosing a voting model by decision type
Step 3: Set Parameters
Practical recommendations:
- Participation quorum: 4–10% — lower is rarely achievable, higher paralyzes governance
- Approval quorum: 50% for routine, 66.7% for critical decisions
- Timelock: 24 hours for routine, 48–72 hours for critical
- Voting period: 3–5 days (enough for awareness, not too long)
Need to design governance?
We'll select the voting model, calculate quorum parameters, and architect the DAO structure for your protocol.
Get in touch