Governance Proposal

A unique, sequential identifier (e.g., Proposal #123) and a human-readable title that succinctly states the proposal's intent. This is the primary reference for discussion and voting.

• On-chain Record: The ID is permanently recorded on the blockchain, creating an immutable audit trail.
• Clarity: A clear title (e.g., "Increase ETH Staking Rewards to 5%") is critical for voter comprehension.

The core explanatory text that outlines the why and how of the proposal. This section provides the necessary context for informed voting.

• Motivation: Details the problem being solved, opportunity seized, or rationale for the change.
• Specification: Provides the technical implementation details, including smart contract addresses, parameter changes (e.g., fee=0.05%), or links to code commits.

Defines the rules for the vote, including the voting system (e.g., single-choice, approval voting) and the available choices.

• Common Options: Typically include For, Against, and Abstain.
• Weighted Voting: Votes are usually weighted by the voter's governance token balance or voting power.
• Execution Logic: The proposal specifies the on-chain action that triggers automatically upon a successful vote.

The two critical timers and thresholds that determine a proposal's validity and outcome.

• Voting Period: A fixed timeframe (e.g., 3-7 days) during which token holders can cast votes.
• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid. Prevents low-turnout decisions.
• Timelock: Many protocols include a delay between vote passage and execution for final review.

The entity (EOA or contract) that submits the proposal and the bond required to prevent spam.

• Proposer Responsibility: The submitter is responsible for framing the discussion.
• Security Deposit: A deposit of native or governance tokens is often required, which may be forfeited if the proposal fails to meet a minimum vote threshold.
• Delegate Submission: Proposals can be submitted by delegates on behalf of token holders.

The sequential states a proposal moves through from creation to resolution. Common states include:

• Pending: In a review/deposit period before voting starts.
• Active: The voting period is open.
• Succeeded/Defeated: Vote has concluded, meeting quorum, with a majority for/against.
• Queued/Executed: (For successful proposals) In timelock or action has been performed.
• Canceled/Expired: Manually canceled or failed due to time or quorum.

Requests to allocate funds from the protocol's treasury for specific initiatives. These are used to fund development, marketing, research, or community initiatives. Proposals typically specify the recipient address, amount, and a detailed justification for the expenditure.

• Examples: Funding a security audit, sponsoring a hackathon, or providing a grant to a core development team.
• Key Metrics: Proposal includes the requested amount in the native token or stablecoins.

Proposals to adjust the configurable parameters of a protocol's smart contracts. This is a core function of on-chain governance, allowing the community to fine-tune system economics and risk settings without a full upgrade.

• Examples: Changing the collateral factor on a lending platform, adjusting the staking reward rate in a PoS network, or modifying the fee structure for a DEX.
• Process: Requires precise specification of the contract address and the new parameter value.

Proposals to deploy new smart contract code or modify existing logic, often requiring a hard fork or migration. These are the most technically complex proposals, as they change the core protocol rules.

• Examples: Adding a new feature to a DEX, implementing a new token standard, or fixing a critical bug.
• Key Steps: Proposal includes the new contract bytecode, an audit report link, and a detailed technical specification. Execution often requires a timelock for security.

Non-binding proposals used to gauge community sentiment on a topic before a formal, executable proposal is submitted. They serve as a temperature check and help build consensus.

• Examples: Signaling support for a potential partnership, deciding between two technical roadmaps, or expressing a philosophical stance on a protocol direction.
• Purpose: These proposals have no on-chain effect but are crucial for social coordination and avoiding contentious hard forks.

Proposals to modify the governance structure itself by appointing or removing delegates, forming sub-committees, or changing voting power rules. They manage the human and procedural elements of governance.

• Examples: Electing members to a security council or grants committee, changing the delegate reward structure, or approving a new multi-signature wallet configuration for treasury management.

A secure governance process enforces a structured lifecycle with mandatory delays. Key stages include:

• Submission & Voting Period: A proposal is submitted with a deposit and debated.
• Timelock Delay: After passing, a mandatory waiting period (e.g., 48 hours) is enforced before execution. This is a critical security feature that allows users to review the final code and exit the system if the change is malicious.
• Execution: The proposal's payload is autonomously executed on-chain. The timelock is the primary defense against a rushed, malicious upgrade.

Governance security depends on the integrity of the voting mechanism. Major risks include:

• Token-based Vote Buying: A malicious actor can acquire a large stake of governance tokens to force through proposals. This is a wealth concentration risk.
• Sybil Attacks: An attacker creates many fake identities to gain disproportionate voting power. This is mitigated by sybil-resistant mechanisms like token-weighted voting or proof-of-personhood systems.
• Low Voter Turnout: Can lead to proposal hijacking by a small, coordinated group.

The proposal's payload contains code that will modify the protocol. Inherent risks are:

• Buggy Code: The proposed smart contract may contain vulnerabilities, leading to loss of funds upon execution. Audits are crucial but not foolproof.
• Unintended Consequences: Even well-intentioned code can have second-order effects that destabilize the protocol's economics or security.
• Governance Capture: If the proposal system itself has a bug, an attacker could take control and upgrade it to a malicious version, a so-called governance takeover.

Many proposals adjust core protocol parameters, which carries systemic risk.

• Critical Parameters: Changes to collateral factors, liquidation penalties, or reward emissions can instantly affect user positions and the protocol's solvency.
• Economic Exploits: A proposal could be designed to subtly drain value, for example, by tweaking fee distributions or oracle configurations.
• Example: A proposal to increase the debt ceiling on an undercollateralized asset could lead to instant insolvency if the asset price falls.

Protocols implement safeguards to mitigate governance risks.

• Multisig Guardians: A decentralized multisig of trusted entities may hold emergency pause authority or the ability to veto clearly malicious proposals before a timelock expires.
• Governance Minimization: Designing systems where as few parameters as possible are governable reduces the attack surface.
• Separation of Powers: Some protocols separate the vote on a proposal's intent from the vote on its exact code, adding a layer of review.

A Proposal Factory is a smart contract template that standardizes and secures the creation of governance proposals. It mitigates risk by:

• Enforcing Standards: Ensuring all proposals have a valid structure, a timelock, and correct target addresses.
• Reducing Human Error: Minimizing mistakes in proposal construction that could lead to failed execution or unintended effects.
• Improving Auditability: Using a verified factory contract makes the proposal code more predictable and easier for the community to review.