Token Governance

What it is

Token governance is the overall process — not just the token itself — by which a decentralized protocol makes collective decisions: proposing changes, voting on them, and executing the results. It's the "constitution and legislature" layer sitting on top of a governance token, defining who can propose what, how votes are counted, and what happens once a vote passes.

How it works

1. The protocol deploys a governance module (commonly a fork of Compound's GovernorBravo or OpenZeppelin's Governor) alongside the token contract.
2. Any address holding tokens above a proposal threshold can submit a proposal: typically calldata describing exact contract calls to execute (e.g., "call setInterestRate(0.05e18) on the lending pool").
3. A voting delay passes before voting opens, so the community can review the proposal text and calldata rather than be surprised by it.
4. During the voting period, token holders (or their delegates) cast for/against/abstain votes weighted by their token balance at a fixed snapshot block.
5. If the vote clears quorum and a majority (or supermajority) threshold, it moves to a timelock queue — a mandatory waiting period before execution.
6. After the timelock expires, anyone can trigger execution, and the timelock contract calls the target functions directly, changing protocol parameters, moving treasury funds, or upgrading contracts.
7. Many protocols add guardrails: a security council or multisig empowered to veto or expedite in emergencies, and separate processes for smaller "temperature check" polls off-chain (e.g., Snapshot) before committing to a binding onchain vote.

Why designers use it

• Splits protocol changes into a transparent, auditable proposal-vote-execute pipeline instead of relying on a single admin.
• Timelocks give users an exit window before contested or malicious changes take effect.
• Off-chain signaling (temperature checks) lets a community gauge sentiment cheaply before committing gas and legitimacy to a binding vote.
• Scales decision-making as a protocol grows past the point where its founding team can or should decide everything unilaterally.

Failure modes

• Low turnout means a handful of large or coordinated holders decide outcomes that affect everyone — many DAO votes pass with single-digit percentage participation.
• Proposal complexity: voters are asked to approve raw calldata they can't easily verify does what the description says, opening room for malicious or buggy proposals to slip through.
• Timelock bypass: if the timelock delay is too short, or an emergency multisig has broad override powers, the "safety window" is illusory.
• Governance capture: delegate markets (paying for delegated votes) or vote-buying schemes can shift outcomes away from genuine community preference.
• Forked/legacy code: many protocols copy governance contracts from other projects without auditing them for their specific parameter changes, inheriting bugs or mismatched thresholds.

What to check before using it

• What is quorum set to, and is it realistic given typical turnout, or so low that a small group can pass anything?
• Is there a public, human-readable diff or simulation of what a proposal's calldata actually does before the vote?
• How long is the timelock, and can any privileged address shorten or skip it?
• Who holds emergency powers (pause, veto, upgrade), and are those powers themselves subject to governance oversight?
• Is voting power delegate-friendly, so passive holders aren't forced to either vote directly or abstain entirely?