Proposal Workflow

The lifecycle begins with a proposal draft posted to the community forum or governance platform. This phase involves temperature checks and request for comments (RFC) to gauge initial sentiment and gather feedback before a formal, on-chain vote. Key activities include:

• Defining the proposal's specification and rationale.
• Estimating technical feasibility and resource requirements.
• Soliciting community feedback to refine the proposal.

A finalized proposal is submitted on-chain, triggering a voting delay period. A critical step is taking a snapshot of token holdings or delegated voting power at a specific block height. This ensures a fair and immutable record of eligible voters, preventing manipulation via last-minute token transfers (vote buying). The proposal enters a formal review period where details are finalized.

The core decision-making phase where token holders cast their votes. Voting mechanisms include:

• Simple majority: >50% approval.
• Supermajority: A higher threshold (e.g., 67%) for significant changes.
• Quadratic voting: Voting power increases with the square root of tokens held.
• Weighted voting: Power is delegated to representatives or multisig signers. Votes are typically cast as For, Against, Abstain, or with more granular options.

After the voting period ends, the proposal is evaluated against predefined governance parameters.

• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid.
• Threshold: The required percentage of yes votes for passage. If both are met, the proposal is queued for execution. Failed proposals may be revised and resubmitted. This phase often includes a timelock delay to allow users to react to passed changes.

Successful proposals enter an execution phase. A timelock is a mandatory delay between a proposal's passing and its execution, a critical security feature. It allows users to:

• Review the finalized code or action.
• Exit positions if they disagree with the change.
• Serve as a last line of defense against malicious proposals that might have passed. After the timelock expires, the proposal's actions are executed automatically or by a designated executor.

The final stage involves monitoring the effects of the implemented change. This may include:

• Reporting on outcomes versus expectations.
• On-chain analytics to track new metrics or parameter impacts.
• Archival of the proposal data for transparency and historical record. This phase closes the feedback loop, informing the drafting of future proposals and potential adjustments to the governance process itself.

A formal proposal follows a standard path from ideation to execution. The typical stages are:

• Drafting & Discussion: Informal forum discussion to refine the idea.
• Temperature Check: A non-binding signal vote to gauge community sentiment.
• Formal Proposal Submission: The proposal is formalized and submitted on-chain with required parameters and code.
• Voting Period: Token holders cast votes, often weighted by stake.
• Timelock & Execution: If passed, the proposal enters a mandatory delay (timelock) for review before automatic on-chain execution.

This lifecycle ensures due diligence and prevents rash changes.

Governance activities are categorized by where they occur.

On-Chain Governance: Voting and execution happen directly via smart contracts on the blockchain. Examples include Compound's Governor Bravo and Uniswap's governance. It is transparent and automatic but can be expensive.

Off-Chain Governance: Discussion, signaling, and rough consensus happen in forums (e.g., Discourse, Commonwealth) or through snapshot votes. Formal execution is often manual. This is lower-cost and more flexible for early-stage discussion but relies on trusted actors for final implementation.

Most protocols use a hybrid model.

The rules that determine how votes are counted and what constitutes a valid outcome.

• Vote Weighting: Typically by token ownership (one-token-one-vote) or via delegated voting power.
• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid (e.g., 4% of circulating supply).
• Approval Threshold: The percentage of cast votes required to pass (e.g., >50% for simple majority, 66% for super-majority).
• Vote Options: Standard options are For, Against, and Abstain. Some systems include Veto or multi-choice voting.

These parameters are critical for security and legitimacy.

A system where token holders can delegate their voting power to other entities, enabling participation without constant engagement.

• Delegates: Individuals or entities (often DAOs or protocols) that research proposals and vote on behalf of their delegators.
• Voting Power: Calculated from the sum of a delegate's own tokens plus all tokens delegated to them.
• Incentives: Some protocols incentivize delegation to ensure an active, informed voter base.
• Tools: Platforms like Tally and Boardroom provide interfaces for delegates and delegators to track voting history and mandates.

This creates a representative democracy model within the protocol.

Different protocols implement distinct workflow models.

• Compound & Uniswap: Use a formal Governor contract system. Proposals execute code directly after a timelock.
• MakerDAO: Employs a complex Executive Vote (for immediate changes) and Governance Poll (for signaling) system, with power vested in MKR holders.
• Optimism Collective: Uses a bicameral system separating Token House (OP holders) and Citizens' House (non-token-based).
• Cosmos SDK Chains: Feature on-chain parameter change and software upgrade proposals voted on by staked validators.

These models illustrate the spectrum from pure token voting to more complex governance structures.

Proposal workflows face several systemic challenges.

• Voter Apathy: Low participation rates can lead to quorum failure or capture by a small, active group.
• Whale Dominance: Concentrated token ownership can lead to plutocracy, where a few large holders dictate outcomes.
• Proposal Fatigue: An overwhelming number of complex proposals can reduce voter engagement and quality of review.
• Implementation Risk: Bugs in proposal code or unexpected interactions can lead to catastrophic execution errors.
• Timelock Races: Malicious actors may front-run or attack a protocol during the delay between vote passage and execution.

The initial phase where a governance participant drafts and funds a proposal. This involves:

• On-chain submission: The proposal's executable code or text is posted to the blockchain.
• Security deposit: A bond (often in the native token) must be staked to prevent spam. This deposit is typically refunded if the proposal passes a preliminary review or vote threshold.
• Example: On Cosmos chains, a minimum deposit (e.g., 512 ATOM) must be met within a deposit period for the proposal to proceed to a vote.

A critical off-chain and sometimes on-chain phase for community feedback and security review before a binding vote.

• Forum discussion: Proposals are debated on platforms like Commonwealth or governance forums, allowing for technical and economic analysis.
• Temperature check: A non-binding snapshot vote may be used to gauge sentiment without incurring on-chain gas costs.
• Purpose: This stage identifies potential vulnerabilities, economic impacts, and coalition-building before committing to a formal, binding on-chain vote.

The binding phase where token holders cast votes to accept or reject a proposal, subject to specific security parameters.

• Voting mechanisms: Common methods include simple majority, supermajority (e.g., 66.7%), and quadratic voting.
• Quorum requirement: A minimum percentage of the total voting power must participate for the vote to be valid. This prevents a small, active minority from controlling governance.
• Vote locking: Tokens may be locked for the duration of the vote to prevent vote selling or double-spending voting power.

The final security-focused phase that enforces a delay between a proposal's approval and its on-chain execution.

• Timelock period: A mandatory waiting period (e.g., 48 hours) after a vote passes but before the proposal's code is executed. This is a critical security grace period.
• Purpose: Allows users to exit the system if they disagree with the outcome and provides a final window to detect malicious code or economic attacks.
• Automated execution: Once the timelock expires, the proposal's payload is typically executed automatically by a governance module without further manual intervention.

Mechanisms to aggregate voting power and prevent manipulation through fake identities.

• Delegation: Token holders can delegate their voting power to trusted validators or delegates, improving participation but creating centralization risk.
• Sybil resistance: Governance systems rely on token-weighted voting (1 token = 1 vote) rather than one-person-one-vote to resist Sybil attacks. Alternative models like proof-of-personhood are being explored.
• Security implication: Concentrated voting power in few delegates creates a governance attack vector if those delegates are compromised.

Contingency plans and privileged controls for responding to critical security incidents outside the standard proposal timeline.

• Emergency multisig: A multisignature wallet controlled by a trusted committee (e.g., core developers) can execute transactions immediately to pause contracts or fix critical bugs.
• Security vs. Decentralization: This creates a trust assumption and represents a centralization point, often justified as a temporary fail-safe.
• Example: Many DeFi protocols like Compound have a pause guardian address with the power to disable borrowing/lending in an emergency.