Governance Proposal

Every proposal is assigned a unique on-chain identifier and includes essential metadata such as:

• Title: A concise, descriptive name.
• Description: A detailed explanation of the proposed change, often using a standardized format.
• Author: The address of the proposer.
• Creation Timestamp: The block number or time the proposal was submitted. This data is permanently recorded on the blockchain, ensuring transparency and auditability.

The core technical component is the executable payload. This defines the specific on-chain actions to be performed if the proposal passes, including:

• Target Contract(s): The smart contract addresses to be called.
• Calldata: The encoded function signature and parameters for the call (e.g., setFeePercentage(uint256)).
• Value: Any native token (e.g., ETH) to be sent with the call. This transforms a vote into a permissioned, automated execution of protocol logic.

Proposals operate within a defined temporal framework controlled by governance parameters:

• Voting Delay: The time between proposal submission and the start of voting.
• Voting Period: The fixed duration (e.g., 3-7 days) during which votes can be cast.
• Execution Delay/Eta: A mandatory waiting period after a successful vote before the proposal can be executed, providing a final safety window.
• Quorum: The minimum percentage of voting power that must participate for the result to be valid.

Defines how token holders express their preference. Common systems include:

• Weighted Voting: Votes are proportional to the voter's token balance (e.g., 1 token = 1 vote).
• Quadratic Voting: Voting power increases with the square root of tokens committed, reducing whale dominance.
• Vote Options: Typically For, Against, and Abstain. Some systems include more granular options or ranked choice. Votes are usually cast on-chain, though snapshot voting (off-chain signaling) is also used for gas-free discussions.

A proposal progresses through a series of immutable states:

1. Pending: Submitted but not yet active for voting.
2. Active: The voting period is open.
3. Succeeded/Failed: Determined at the end of voting based on quorum and majority thresholds.
4. Queued: A successful proposal waits for the execution delay.
5. Executed: The calldata is successfully executed on-chain.
6. Canceled/Expired: Terminated by the proposer or after a timeout. This state machine ensures orderly and predictable process flow.

Critical safeguards are embedded to protect the protocol:

• Timelock: A mandatory delay between a successful vote and execution. This allows users to react to or exit from potentially harmful changes.
• Proposal Threshold: The minimum token balance required to submit a proposal, preventing spam.
• Guardian/Pause Mechanism: Some protocols have a multisig or emergency role that can pause or cancel malicious proposals before execution, acting as a final backstop.

A non-binding proposal used to gauge community sentiment on a topic before submitting a binding on-chain proposal. It serves as a temperature check.

Typical uses:

• Signaling support for a broad strategic direction.
• Gathering feedback on a potential parameter change or partnership.
• Officially stating the community's stance on an external event.

While not executable, these proposals are vital for building consensus and reducing governance friction.

A governance proposal follows a structured path from ideation to execution.

• Drafting & Discussion: Initial ideas are debated in community forums (e.g., governance forums, Discord) to gauge sentiment.
• Temperature Check: A preliminary, often off-chain, vote to measure broad support before committing on-chain resources.
• Formal Submission: The proposal, including executable code or detailed specifications, is submitted on-chain, locking a proposal bond.
• Voting Period: Token holders cast votes, typically weighted by their stake, during a fixed window (e.g., 3-7 days).
• Execution: If the vote passes the required quorum and approval threshold, the proposal's changes are automatically executed via a timelock contract after a delay.

Proposals can mandate various levels of change to a protocol's operation.

• Parameter Changes: Adjusting system variables (e.g., interest rates, fee percentages, collateral factors).
• Treasury Management: Allocating funds from the community treasury for grants, development, or other initiatives.
• Protocol Upgrades: Authorizing smart contract upgrades or migrations, often the most critical type of proposal.
• Informational Proposals: Signaling votes to guide future development without immediate on-chain execution.

How votes are cast and counted is fundamental to governance integrity.

• Token-Weighted Voting: One token equals one vote. This is the most common model, aligning voting power with economic stake.
• Quadratic Voting: Voting power increases with the square root of tokens committed, designed to reduce whale dominance.
• Delegation: Token holders can delegate their voting power to representatives or delegates who vote on their behalf.
• Snapshot Voting: A gas-free, off-chain signing mechanism used for signaling; final execution still requires an on-chain proposal.

Critical mechanisms protect protocols from malicious or erroneous proposals.

• Proposal Bond: A deposit required to submit a proposal, which is slashed if the proposal fails to meet a minimum participation (quorum).
• Timelock: A mandatory delay between a proposal's approval and its execution. This provides a final review period where users can exit the system if they disagree with the change.
• Multisig Execution: In some systems, a multisig wallet controlled by elected delegates or a foundation holds the final execution power, acting as an additional check.

Uniswap's governance process illustrates a mature DAO structure.

• Governance Token: UNI holders govern the protocol.
• Process: Proposals move from the Uniswap Forum → Snapshot temperature check → on-chain vote.
• Delegation: Most UNI is delegated to entities like a16z, GFX Labs, and other delegates.
• Execution: The Uniswap Governor Bravo contract manages proposals, with a 2-day voting period and a 2-day timelock. A famous example is the successful proposal to deploy Uniswap v3 to Polygon via a consensus grant.

A fungible token that confers voting rights within a decentralized protocol. Holders use these tokens to signal preferences, delegate votes, or submit proposals. The token's distribution model (e.g., to users, investors, or a treasury) is a critical design choice influencing governance centralization. Examples include UNI (Uniswap), AAVE, and MKR (MakerDAO).

The specific rule set for aggregating voter preferences into an outcome. Common mechanisms include:

• Token-weighted voting: One token equals one vote.
• Quadratic Voting: Voting power increases with the square root of tokens committed, reducing whale dominance.
• Conviction Voting: Voting power increases the longer a vote is held.
• Time-locked voting: Votes are weighted by how long tokens are staked. The mechanism directly impacts security and fairness.

The controlled pool of assets (often native tokens and stablecoins) owned by a DAO or protocol. Governance proposals frequently involve treasury allocations for grants, funding development, or liquidity provisioning. Managing multi-signature wallets, investment strategies, and runway are core treasury functions. Proposals must specify amount, recipient, and purpose for any treasury expenditure.

A high-stakes type of governance proposal that modifies the protocol's core logic. This often requires a timelock delay between proposal passage and execution, allowing users to exit if they disagree. Upgrades can change fee structures, add new features, or fix critical bugs. The process is managed by an upgradeable proxy pattern or a dedicated governance module like OpenZeppelin's Governor.

The process where a token holder assigns their voting power to another address (a delegate). This enables participation without constant engagement and allows experts to represent communities. Delegates often publish voting platforms or manifestos. Systems may allow for partial delegation or topic-specific delegation (e.g., delegating treasury votes to a different expert than technical votes).