Governance Proposal

What Is a Governance Proposal?

A governance proposal is a structured submission that asks a decentralized protocol's community to approve a specific change. Changes can range from adjusting interest rates on a lending protocol to deploying entirely new smart contracts or distributing treasury funds. The proposal formalizes the idea, defines the exact on-chain actions that would execute if approved, and opens a voting window for token holders to accept or reject it.

Governance proposals are the primary decision-making mechanism for DAOs and DeFi protocols that use token-weighted voting. Each governance token represents one vote, so a holder with 10,000 tokens has 10,000 times the voting power of someone with one token. This model gives protocols a decentralized way to evolve without relying on a single team or entity to make decisions, but it also introduces risks that centralized systems do not face.

Not all blockchains use this model. Bitcoin, for example, relies on rough consensus among developers, miners, and node operators rather than any token-weighted vote. Understanding governance proposals means understanding both their power and their limitations.

How It Works

Most major protocols follow a similar lifecycle, though the exact stages, thresholds, and timelines differ. The general flow moves from informal discussion to binding on-chain execution.

Stage 1: Forum Discussion

Proposals begin as written posts on a governance forum (Discourse, Commonwealth, or a protocol-specific platform). The author describes the problem, proposes a solution, and invites feedback. This stage is entirely off-chain and has no formal requirements: anyone can post, regardless of token holdings.

Forum discussion serves as a filter. Poorly conceived ideas get challenged before consuming on-chain resources. Authors refine their proposals based on community feedback, often going through multiple revisions. Some proposals die at this stage, which is a feature, not a bug.

Stage 2: Temperature Check (Snapshot)

Proposals that gain forum traction move to a non-binding vote, typically on Snapshot. Snapshot uses off-chain signatures weighted by token holdings at a specific block height, meaning votes are free (no gas costs) but not enforceable on-chain.

The temperature check answers a simple question: does this idea have enough support to justify the cost and effort of an on-chain vote? Protocols like Uniswap and Aave require proposals to pass this stage before advancing. Aave uses a three-day Snapshot window for its Temp Check and ARFC (Aave Request for Comments) stages.

Stage 3: Formal On-Chain Proposal

If the temperature check passes, the proposal moves on-chain. This is where real stakes begin: the proposal includes executable code (or an IPFS-hashed payload referencing the code) that will run automatically if the vote succeeds.

Submitting an on-chain proposal requires meeting a proposal threshold: a minimum number of tokens that the proposer must hold or have been delegated. This prevents spam and ensures only stakeholders with meaningful skin in the game can initiate binding votes.

These thresholds change over time. Uniswap launched with a 10M UNI proposal threshold, which the community later reduced to 2.5M and then to 1M as it became clear that the original bar was too high for most participants.

Stage 4: Voting Period

During the voting period, token holders cast votes: For, Against, or Abstain. Votes are weighted by the number of tokens held (or delegated) at a snapshot block, which is typically set at proposal creation. Using a snapshot prevents manipulation through last-minute token purchases.

For a proposal to pass, two conditions must be met:

• Quorum: a minimum number of votes must be cast. This prevents decisions from passing with trivially low participation.
• Majority: the For votes must exceed the Against votes (or meet a higher threshold, depending on the protocol).

Some protocols add a veto mechanism. The Cosmos SDK, for example, allows NoWithVeto votes: if more than one-third of all votes are NoWithVeto, the proposal fails regardless of the For count, and the proposer's deposit is burned.

Stage 5: Timelock and Execution

Proposals that pass do not execute immediately. A timelock contract enforces a delay, typically one to seven days, before the approved code runs. This window lets users who disagree with the outcome exit the protocol before the change takes effect: they can withdraw funds, close positions, or migrate to alternatives.

After the timelock expires, anyone can trigger execution. The smart contract checks that the proposal passed quorum and majority requirements, verifies the timelock has elapsed, and then calls the approved functions. No human intervention is needed beyond the initial trigger transaction.

Delegation

Most governance systems support delegation: a token holder assigns their voting power to another address without transferring their tokens. The delegate votes on proposals using the combined weight of all tokens delegated to them.

Delegation solves a practical problem: governance fatigue. Not every holder wants to research and vote on every proposal. By delegating to a trusted community member, researcher, or professional delegate, small holders can ensure their tokens still influence outcomes.

On protocols like Compound and Uniswap, delegation is actually a prerequisite for voting: holders must delegate to themselves or another address before their tokens carry any voting weight. Aave extends this further by splitting delegation into voting power and proposition power, meaning a holder can delegate the right to vote separately from the right to submit proposals.

Some protocols use vote-escrowed tokens instead of simple delegation. In this model (used by Curve and Balancer), holders lock tokens for a chosen period, and longer lock durations grant proportionally greater voting power.

On-Chain vs. Off-Chain Governance

The distinction between on-chain governance and off-chain governance matters for understanding where proposals carry binding force.

• On-chain governance: votes happen on the blockchain, and passed proposals execute automatically via smart contracts. This is how Compound, Uniswap, and Aave handle final votes. The result is trustless: no multisig or core team needs to implement the outcome.
• Off-chain governance: votes happen on platforms like Snapshot using signed messages, with no on-chain enforcement. Results are advisory, and execution depends on a trusted party (often a multisig or security council) to implement the decision. Off-chain votes are cheaper and more accessible, which is why they serve as the temperature-check stage in most governance pipelines.

Many DAOs use a hybrid approach: off-chain signaling to filter ideas, followed by on-chain voting for binding decisions. This balances accessibility with trustless execution.

Use Cases

Protocol Parameter Changes

The most common use of governance proposals is adjusting protocol parameters: collateral factors on lending platforms, fee tiers on decentralized exchanges, interest rate curves, or liquidation thresholds. These changes directly affect user funds and protocol risk, which is why they require community approval rather than unilateral action.

Smart Contract Upgrades

Protocols that use upgradeable proxy contracts can deploy new logic through governance proposals. The proposal payload typically points to a new implementation contract, and the timelock-guarded execution swaps the proxy's implementation address. This lets protocols fix bugs, add features, and optimize gas usage while maintaining decentralized control over what code runs.

Treasury Allocation

DAOs control treasuries worth billions of dollars collectively. Governance proposals govern how these funds are spent: grants to developers, liquidity incentives, security audits, marketing initiatives, or strategic investments. Treasury proposals often face the most scrutiny because they involve direct token transfers.

Emergency Actions

Some protocols include emergency governance paths with shorter timelocks and lower quorum requirements. These exist for critical scenarios like oracle failures, exploit responses, or market crashes where the standard multi-week governance process would be too slow. Aave's Guardian multisig, for example, can pause the protocol without waiting for a full governance vote.

Risks and Considerations

Flash-Loan Voting

If a protocol reads vote weight from live token balances rather than a historical snapshot, an attacker can borrow governance tokens via a flash loan, vote on an active proposal, and return the tokens within the same transaction. The Beanstalk exploit in 2022, which drained approximately $182 million, is the canonical example of this governance attack vector.

The standard mitigation is snapshot-based voting: vote weight is determined by token holdings at the block when the proposal was created, not when the vote is cast. Most major protocols adopted this approach by 2022, making pure flash-loan voting attacks significantly harder.

Low-Turnout Capture

Voter apathy is a persistent problem in token governance. When participation drops to 3-5% of total supply, a relatively small token position can control outcomes. The BonkDAO incident demonstrated this risk: a malicious proposal passed with only about 2.9% of participants actively voting, spread across just seven wallets, enabled by a quorum set at only 1% of supply.

Higher quorum requirements reduce this risk but create a different problem: legitimate proposals may fail to reach quorum, especially in protocols with widely distributed tokens. Finding the right quorum level is one of the hardest design decisions in governance.

Vote Buying and Influence Markets

Platforms like Votium and Hidden Hand create explicit markets for governance votes, where protocols pay token holders to vote a certain way on gauge-weight proposals. While these platforms operate openly, they raise questions about whether governance outcomes reflect genuine community preference or simply the highest bidder's interests.

Governance Minimization

Every governable parameter is a potential attack vector. Governance minimization is a design philosophy that reduces the number of things token holders can change, shrinking the attack surface. Uniswap v3, for example, deployed immutable core contracts: no governance vote can alter the AMM logic itself, only peripheral parameters like fee switches.

The trade-off is flexibility. Immutable contracts cannot be patched if bugs are found. Protocols must decide which parameters genuinely require human judgment (oracle selection, risk parameters, treasury spending) and which can be hardcoded or automated.

Bitcoin's Alternative: Rough Consensus

Bitcoin deliberately avoids token-weighted governance. Changes to the Bitcoin protocol follow a rough consensus model where developers propose BIPs, node operators choose whether to run updated software, and miners signal support. No single group can force a change: miners cannot override economic nodes, and developers cannot compel anyone to run their code.

This model is slower and messier than token voting, but its proponents argue that the friction is the point. It makes it very difficult for any party to alter Bitcoin's monetary policy, security model, or consensus rules. The trade-off is that upgrades like Taproot take years to activate, whereas a DeFi governance proposal can execute within weeks.

Why It Matters

Governance proposals determine how billions of dollars in DeFi protocols are managed. They are the mechanism through which communities adjust risk parameters, deploy upgrades, allocate treasury funds, and respond to market conditions. Understanding the governance process is essential for anyone participating in DeFi or evaluating protocol risk.

For protocols built on Bitcoin's infrastructure, governance takes different forms. Bitcoin Layer 2 solutions like Spark inherit Bitcoin's conservative approach to protocol changes while enabling new functionality for payments and stablecoins without requiring the kind of token-weighted governance votes that DeFi protocols depend on.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.