Governance Proposal

Proposals can be executed on-chain, where votes are recorded directly on the blockchain (e.g., using a smart contract), or off-chain, where signaling occurs through platforms like Snapshot. On-chain voting is binding and requires gas fees, while off-chain voting is typically gasless and used for non-binding sentiment checks before a final on-chain execution.

A standard proposal follows a defined path:

• Drafting & Discussion: Informal debate on forums (e.g., Commonwealth, Discord).
• Temperature Check: A lightweight poll to gauge initial sentiment.
• Formal Submission: Proposal is submitted on-chain with a required deposit.
• Voting Period: A fixed window (e.g., 3-7 days) for tokenholder voting.
• Timelock & Execution: If passed, changes are often queued in a timelock contract for security before being executed.

Voting power is typically weighted by a user's stake in the protocol's governance token. Quorum is the minimum percentage of total voting power that must participate for a vote to be valid. Vote delegation allows users to delegate their voting power to experts or representatives, a model central to Delegated Proof-of-Stake (DPoS) and veToken systems.

Proposals can govern various protocol aspects:

• Parameter Changes: Adjusting fees, interest rates, or collateral ratios.
• Treasury Management: Allocating funds from the community treasury.
• Protocol Upgrades: Authorizing new smart contract code.
• Whitelisting: Adding new collateral assets or integrations. Key parameters include the proposal deposit, voting delay, voting period, and execution delay.

Governance systems must defend against specific threats:

• Vote Buying: Accumulating tokens temporarily to swing a vote.
• Timelock Exploits: Bypassing the execution delay.
• Governance Capture: A single entity acquiring a majority of voting power.
• Proposal Spam: Flooding the system with low-quality proposals. Mitigations include quorums, timelocks, proposal deposits, and veto mechanisms.

• Fork: The ultimate governance mechanism, where a dissenting community creates a new chain.
• Multisig: A transitional or emergency control mechanism, often used by a DAO's core team.
• Optimistic Governance: Proposals execute immediately but can be challenged and reversed during a dispute period.
• Quadratic Voting: A system where vote cost increases quadratically to reduce whale dominance.

A governance proposal follows a structured path from ideation to execution. The typical stages are:

• Drafting & Temperature Check: Informal discussion on forums (e.g., Discourse, Commonwealth) to gauge community sentiment.
• Formal Submission: The proposal, including executable code or parameter changes, is submitted on-chain, often requiring a proposal deposit.
• Voting Period: Token holders cast votes, with weight determined by their stake. Common voting models include token-weighted and delegated voting.
• Timelock & Execution: If passed, changes are often queued in a timelock contract for a security delay before automatic execution.

Proposals can be categorized by their scope and intent:

• Parameter Change: Adjusting system variables (e.g., interest rates, fee percentages).
• Treasury Allocation: Authorizing payments from the community treasury for grants, bug bounties, or development.
• Code Upgrade: Deploying new smart contract logic, requiring a governance-controlled upgrade mechanism.
• Informational: Signaling community sentiment on a direction without executing code.
• Emergency: Fast-tracked proposals to address critical bugs or security vulnerabilities, often with reduced voting delays.

The voting system defines how consensus is reached. Key elements include:

• Voting Power: Typically derived from a governance token balance, often with mechanisms for vote delegation.
• Quorum: The minimum percentage of total voting power that must participate for a vote to be valid.
• Approval Threshold: The majority required (e.g., >50% simple majority, >66% supermajority) for a proposal to pass.
• Vote Options: Usually For, Against, and Abstain. Some systems use more complex quadratic voting to reduce whale dominance.

On-chain governance introduces unique risks that protocols mitigate through specific mechanisms:

• Timelocks: A mandatory delay between a vote passing and execution, allowing users to exit or review final code.
• Governance Minimization: Limiting the scope of what governance can control to reduce attack surface.
• Vote Snapshot: Using a historical block height (snapshot) to determine voting power, preventing last-minute token borrowing (vote buying).
• Emergency Multisigs: A fallback controlled by trusted entities to pause the system in case of a malicious proposal passing.

A suite of specialized tools supports the proposal lifecycle:

• Discussion Forums: Snapshot, Discourse, and Commonwealth for off-chain sentiment.
• Voting Platforms: Snapshot (off-chain, gas-free signaling) and Tally (on-chain governance dashboard).
• Block Explorers: Etherscan's "Read/Write as Proxy" feature to interact with Governor contracts.
• Delegation Platforms: Sites like Sybil.org for discovering and delegating to representatives. These tools abstract complexity, making participation accessible to non-technical token holders.

An attack where a malicious actor submits a high volume of low-quality or fraudulent proposals to clog the governance system, wasting community attention and resources. This can be used as a denial-of-service (DoS) tactic to delay or prevent legitimate proposals from being seen or voted on. Mitigations include requiring a proposal deposit or implementing a spam filter based on token holdings or reputation.

Exploiting the fixed voting period of a proposal. Attackers may:

• Vote Sniping: Wait until the final moments of a vote to cast a decisive ballot, preventing opponents from mounting a counter-response.
• Timing Manipulation: Propose changes that are beneficial only if executed at a specific future block, exploiting knowledge of upcoming events or market conditions unknown to other voters.

A direct attack where a malicious proposal seeks to transfer protocol treasury funds to an attacker-controlled address. This relies on voter apathy, low turnout, or vote manipulation to pass. High-profile examples include the attempted $1 billion drain of the Mango Markets treasury and the Beanstalk Farms $182 million exploit, which passed via a flash loan to acquire voting power.

A subtle attack where a proposal alters critical protocol parameters to create an exploitable financial imbalance. Examples include:

• Adjusting fee parameters or interest rate curves in lending protocols.
• Modifying collateral factors or liquidation thresholds.
• Changing the reward distribution in a liquidity pool. These changes can be engineered to benefit the proposer through subsequent arbitrage or liquidation events.

The practice of accumulating voting power (often via flash loans or token borrowing) or forming coalitions to pass proposals for private gain at the expense of the broader community. This undermines the one-token-one-vote ideal. Defenses include:

• Time-weighted voting (e.g., veToken models).
• Quorum requirements and supermajority thresholds.
• Sybil resistance mechanisms.

The risk that a proposal's on-chain execution contains hidden malicious logic or exploits, even if its description appears benign. This includes:

• Proxy upgrades that change a contract's logic to a malicious implementation.
• Self-destruct functions or privileged roles granted to the proposer.
• Reentrancy or logic bugs introduced in new code. Mitigation requires rigorous audits, formal verification, and timelocks to allow for community review before execution.

The voting mechanism defines the rules for how votes on a proposal are cast, tallied, and executed. It is a critical design choice for security and fairness.

• Common Types: Token-weighted voting (1 token = 1 vote), Quadratic voting (cost increases quadratically with vote weight), and Conviction voting (vote weight increases over time).
• Parameters: Includes quorum (minimum participation required), voting delay, voting period, and approval threshold.

A smart contract upgrade is a common and high-stakes type of governance proposal. It involves modifying the immutable code of a protocol's core contracts.

• Methods: Can be executed via proxy patterns (where logic is separate from storage), module upgrades, or migration to a new contract.
• Risk: Requires extreme caution; a flawed upgrade can lead to fund loss or protocol failure.
• Example: Proposals to change fee parameters or add new features to a DeFi protocol.

Treasury management proposals involve allocating funds from a protocol's community treasury. This is a primary function of on-chain governance.

• Uses: Funding grants for development, liquidity incentives, operational expenses, or strategic acquisitions.
• Process: Proposals specify recipient addresses, amounts, and vesting schedules.
• Transparency: All transactions are recorded on-chain, allowing for full auditability of fund flows.