Proposal Submission

Protocols define specific proposal types to standardize submissions. Common templates include:

• Parameter Change: Adjusting fees, rewards, or economic constants.
• Treasury Spend: Allocating funds from the community treasury.
• Code Upgrade: Deploying new smart contract logic (e.g., via a governance module).
• Informational: Signaling votes for broader community direction. Templates ensure proposals contain all necessary data for proper evaluation.

To prevent spam, proposals require a proposal deposit—a stake of native tokens that is forfeited if the proposal fails to reach a voting quorum. Key requirements include:

• Minimum Deposit: A threshold that must be met, often through a crowd-funding period.
• Proposer Weight: Some systems require the proposer to hold a minimum voting power.
• Metadata: Title, description, and on-chain execution payload must be formatted correctly. These gates ensure only serious, well-formed proposals enter the voting stage.

The proposal is submitted as a transaction to the protocol's governance smart contract. This module:

• Validates the proposal format and deposit.
• Emits events to indexers and front-ends.
• Initiates the voting period once the deposit is secured.
• Queues for execution if the vote passes. This automated, trustless process is the core technical mechanism of on-chain governance.

A submitted proposal moves through a defined state machine:

1. Deposit Period: Open for staking to meet the minimum deposit.
2. Voting Period: Delegates cast votes for Yes, No, NoWithVeto, or Abstain.
3. Passed/Rejected: Determined by quorum and majority thresholds.
4. Execution: Passed proposals are automatically executed or manually triggered via a timelock. Each state is immutable and recorded on-chain.

The submission process introduces key attack vectors that protocols mitigate:

• Proposal Spam: Mitigated by deposit requirements and quorum thresholds.
• Malicious Payloads: Audits and timelock delays between vote passage and execution allow for emergency intervention.
• Vote Sniping: Voting periods are fixed to prevent last-minute manipulation.
• Gas Optimization: Proposal data structures are designed to minimize submission and storage costs on-chain.

A clear, concise title and an executive summary that outlines the proposal's purpose and high-level impact. This section is critical for voter comprehension and should avoid technical jargon to be accessible to all stakeholders.

• Purpose: Communicates the "what" and "why" at a glance.
• Key Elements: Often includes a proposal ID (e.g., BIP-9, EIP-1559) and a one-paragraph abstract.

The core technical document. The Motivation explains the problem being solved, while the Specification provides the exact technical implementation details.

• Motivation: Includes background, rationale, and desired outcomes.
• Specification: Defines the precise changes to protocol rules, smart contract code, or parameters. This often includes code snippets, state transitions, or new contract addresses.

The executable component that defines what will happen if the proposal passes. This is not a description, but the actual calldata for the transaction.

• Target Contract: The smart contract address that will receive the governance call.
• Calldata: The encoded function call (e.g., setParameter(uint256 1000000)).
• Value: Any native token (e.g., ETH) to be sent with the call.

Defines the rules for the voting process itself. These are often set by the governance framework but can be specified in the proposal.

• Voting Delay: Time between proposal submission and start of voting.
• Voting Period: Duration of the active voting window (e.g., 7 days).
• Execution Delay: Time between a successful vote and when the action can be executed.
• Quorum: Minimum percentage of voting power required for the vote to be valid.

A critical section for complex upgrades, detailing potential security risks, economic impacts, and contingency plans. For code changes, links to audit reports are mandatory.

• Security Considerations: Lists known vulnerabilities, attack vectors, and mitigation strategies.
• Audit Links: References to reports from reputable security firms.
• Rollback Plan: Steps to revert changes in case of critical failure.

Demonstrates the proposal has been rigorously tested and outlines the steps for deployment. This builds confidence in the technical soundness of the proposal.

• Testnets: Evidence of successful deployment on test networks (e.g., Goerli, Sepolia).
• Simulation Results: Data showing the expected impact of parameter changes.
• Deployment Steps: A sequential plan for mainnet execution, often involving a Timelock contract for a safety delay.

Most protocols require the proposer to deposit or lock a minimum amount of the network's governance token (e.g., MKR, UNI, COMP) to submit a proposal. This acts as a spam-prevention mechanism and a signal of commitment. The deposit is often returned upon successful execution or slashed if the proposal is deemed malicious or fails to pass.

• MakerDAO: Requires a Governance Security Module (GSM) pause delay and a vote from MKR holders.
• Uniswap: A proposal requires 2.5 million UNI delegated to the proposer's address to be submitted.

Proposals can be submitted for binding on-chain execution or for non-binding off-chain signaling.

• On-Chain (e.g., Compound, Aave): The proposal contract contains executable code. If passed, it autonomously modifies protocol parameters or upgrades contracts.
• Off-Chain (e.g., Uniswap, early Snapshot votes): Uses platforms like Snapshot for gas-free voting to gauge community sentiment. A separate, trusted transaction is required to implement the result. This separates the signaling and execution phases.

A standard submission triggers a multi-stage process:

1. Temperature Check: An informal off-chain poll to gauge initial interest.
2. Consensus Check: A more formalized discussion to refine the proposal's details.
3. Governance Proposal: The final, executable proposal is submitted on-chain with a defined voting period.
4. Timelock & Execution: If passed, the proposal enters a timelock period (a security delay), after which it can be executed to enact the change.

The most common type of proposal involves adjusting a protocol's economic or risk parameters. Examples include:

• Lending Protocols: Changing collateral factors, reserve factors, or interest rate models.
• DEXs: Adjusting protocol fee percentages or fee distributor weights.
• DAOs: Modifying grant treasury payout limits or delegation parameters. These are often submitted by delegated experts or risk management teams.

DAOs use proposal submission to manage their treasury and fund ecosystem growth. This includes:

• Grant Funding: Requesting funds for development, marketing, or research work (e.g., Uniswap Grants Program).
• Working Group Budgets: Allocating quarterly budgets to sub-DAOs or contributor groups.
• Token Swaps: Proposing to use treasury assets for strategic token swaps or liquidity provisioning. These proposals detail the recipient, amount, and justification for the expenditure.