Governance

Governance is the set of mechanisms by which a protocol's decisions are made once it is live and has a community. In Web3, governance typically means token-holder voting on specific proposals, though the scope and enforcement of those votes varies enormously across protocols.

Why Governance Matters

Every protocol has governance whether it wants to or not. Even "immutable" contracts have upgrade paths via proxy, or governance-less contracts with admin multisigs controlled by a founding team. The question is not whether to have governance, but how it works.

Governance determines:

• Who can change protocol parameters (fees, staking rewards, risk parameters)
• Who controls the treasury (what proposals can spend it, how much, on what)
• Who upgrades the contracts (which multisig or proposal can trigger an upgrade)
• Who handles emergencies (who can pause, who can veto, who can override)

Get governance wrong and one of two things happens. Either it becomes security theater that doesn't actually do anything (and users figure it out), or it gets captured by whoever buys enough tokens (and extracts value at the community's expense).

Common Governance Patterns

Full on-chain with timelock: proposals are submitted on-chain, token holders vote, successful proposals queue in a timelock before execution. Compound and Uniswap use this. Strongest form of on-chain governance but slow.

Snapshot + multisig execution: community votes off-chain on Snapshot.org, a multisig executes the winning proposal. Faster than full on-chain, cheaper, but requires trust in the multisig signers.

Multisig with community signaling: the multisig makes decisions informed by community discussion. Weakest form of "decentralized governance" — essentially a centralized team with soft community input.

Delegation: most token holders do not vote. They delegate their votes to trusted community members. Compound and ENS use delegation heavily.

Quadratic voting: votes are weighted by square root of tokens held, reducing the power of whales. Rarely used in protocol governance but common in quadratic funding for public goods.

Common Failure Modes

Governance capture. A single whale or coalition of whales accumulates enough voting power to dictate decisions. The community figures this out, loses trust, engagement collapses.

Voter apathy. Nobody votes. Proposals either fail to reach quorum or pass with minimal participation. Whoever shows up decides everything.

Governance attacks. An attacker borrows tokens (via flash loan or MakerDAO-style line of credit), votes to drain the treasury, then returns the tokens. Several protocols have lost significant funds this way.

Multisig override. Governance "decides" something, but the multisig can override. Users discover this and governance becomes theater.

No timelock. Governance can execute decisions instantly. No time for the community to react if something malicious passes. Especially dangerous with treasury control.

What Good Governance Looks Like

• Meaningful scope: governance actually decides things that matter (fee parameters, treasury spend, upgrades).
• Timelocks on binding decisions: 48 hours minimum for parameter changes, 7 days for upgrades. Gives the community time to react.
• Quorum that is achievable but not trivial: 4-8% of circulating supply is a common range.
• Easy delegation: most token holders will not vote. Make it easy for them to delegate to trusted community members.
• Emergency pause mechanisms: a guardian multisig that can pause specific actions (not override governance) in case of live exploit.
• Separation of concerns: different governance paths for parameter updates vs upgrades vs treasury spend. Each may have different quorum and timelock requirements.

The eMBA for Web3 Founders Governance Design module in Zealynx Academy goes deeper into each of these patterns, with case studies of governance designs that have survived real attacks and governance designs that collapsed under them.