Proposal Lifecycle

The lifecycle begins with a proposal draft posted to a community forum (e.g., Discord, governance forum). This is the temperature check or Request for Comments (RFC) phase, where the community debates the idea's merits, feasibility, and potential parameters before formal submission. Key activities include:

• Defining the proposal's specification and rationale.
• Gathering initial community sentiment and feedback.
• Iterating on the draft based on technical and economic feedback.

Once refined, the proposal is submitted on-chain as a governance transaction, which typically requires a proposal deposit. A formal voting period (e.g., 3-7 days) begins, during which token holders cast votes. Voting mechanisms include:

• Simple majority or supermajority thresholds.
• Weighted voting based on token quantity or vote delegation.
• Quorum requirements to ensure sufficient participation.

If the vote passes, the proposal does not execute immediately. It enters a timelock period, a mandatory delay (e.g., 48 hours) before the encoded actions are executed. This critical security feature allows users to:

• Review the finalized, executable code.
• Exit systems or positions if they disagree with the outcome.
• Provides a final safeguard against malicious proposals that have gained approval.

After the timelock expires, the proposal's payload is automatically executed by the protocol's governance executor (e.g., a smart contract). This can trigger various on-chain actions, such as:

• Updating protocol parameters (e.g., interest rates, fees).
• Deploying new smart contract logic via a governance upgrade.
• Allocating funds from a community treasury.
• Adding new collateral assets to a lending protocol.

The initial, informal stage where a proposal idea is shared with the community. A temperature check is a non-binding signal vote (often using Snapshots) to gauge sentiment before dedicating on-chain resources. This stage filters out clearly unpopular ideas and refines proposals through community feedback.

• Purpose: Validate interest and gather initial feedback.
• Key Tool: Off-chain voting platforms (e.g., Snapshot).
• Security Consideration: Prevents spam and wasted gas by filtering proposals before they reach the formal, on-chain voting stage.

The proposal is formalized into executable code or a precise governance action and submitted on-chain. This typically requires a proposal deposit to prevent spam. The proposal enters a timelock or voting delay period, allowing users to review the final code before voting begins.

• Core Components: Includes target contract addresses, calldata, and description.
• Security Mechanisms: Proposal deposits, timelocks for review.
• Critical Step: The exact code to be executed is frozen and made public for audit.

Token holders cast votes, with weight typically proportional to their stake. A successful vote must meet two key thresholds:

• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid. Prevents a small, active minority from controlling outcomes.
• Approval Threshold: The percentage of participating votes required to pass (e.g., simple majority, supermajority).

Voting strategies can include token-weighted, delegated, or conviction voting.

After a proposal passes, it does not execute immediately. It enters a timelock period, a mandatory delay (e.g., 48-72 hours) before the encoded actions can be executed. This is a critical security feature.

• Purpose: Provides a final window for users to exit systems or for emergency measures (like a governance veto) to be enacted if a malicious proposal slips through.
• Execution: Once the timelock expires, any authorized address (often a multisig or the proposer) can trigger the execute transaction to enact the change.

The proposal lifecycle is a target for several attack vectors:

• Proposal Fatigue: Spamming proposals to dilute attention and voter participation.
• Governance Capture: An entity acquires enough voting power to pass self-serving proposals.
• Timelock Exploitation: If the timelock is too short, it may not provide adequate reaction time.
• Malicious Calldata: A proposal that appears benign but contains hidden, harmful execution logic.

Mitigations include quorum thresholds, delegation, veto powers, and extended timelocks.

A core governance challenge is ensuring sufficient and informed participation. Vote delegation allows token holders to delegate their voting power to experts or representatives, improving decision quality but creating principal-agent risks.

• Voter Apathy: Low participation can lead to failed quorums or governance capture by a small, dedicated group.
• Solutions: Delegation platforms (e.g., Tally), governance mining incentives, and gasless voting (via signatures) aim to increase participation and security.

An informal, off-chain polling stage used to gauge community sentiment before drafting a formal proposal. It helps filter ideas and build consensus using tools like Discourse forums or Snapshot votes. Key aspects:

• Low barrier to participation (often no token locking).
• Results are not binding but inform subsequent steps.
• Prevents network spam by filtering unserious proposals early.

The formal act of publishing a binding governance proposal to the blockchain, typically requiring a proposal deposit. This transaction includes the executable code or text of the proposal and triggers the voting period. Requirements often include:

• A minimum deposit of native tokens (sometimes refundable).
• A formal description following a specific template.
• Specification of the target contract and calldata for execution.

The period where token holders cast votes, subject to meeting a quorum—the minimum percentage of voting power that must participate for the result to be valid. Voting mechanisms include:

• Simple majority: >50% of votes cast.
• Supermajority: e.g., 66.7% or 75% threshold.
• Weighted voting: votes are proportional to staked tokens or delegated power.
• Vote delegation: users can delegate voting power to representatives.

A security mechanism that imposes a mandatory delay between a proposal's approval and its on-chain execution. The timelock period allows users to review passed code or exit systems before changes take effect. The execution phase involves:

• A privileged address (e.g., Governor contract) executing the proposal's calldata.
• Automatic execution if votes meet criteria, or manual execution by a proposer.
• Failed execution if conditions change (e.g., insufficient funds) post-approval.

A safety mechanism allowing a privileged entity to cancel a passed proposal, typically to prevent governance attacks or critical bugs. Implementations vary:

• Multisig Veto: A council or core team holds veto power via a multisig wallet.
• Guardian/Vetoer: A designated smart contract or address can veto within a time window.
• Security Council: A decentralized group elected to act as a circuit breaker in emergencies.

Governance systems categorize proposals by their scope and impact, often using standards like EIP-4824 for common interfaces. Common types include:

• Core Protocol Upgrades: Changes to consensus or monetary policy.
• Parameter Changes: Adjusting fees, rewards, or limits.
• Treasury & Grants: Allocating funds from a community treasury.
• Informational/Signaling: Non-binding votes to guide future decisions.