Setting Up a Proposal Submission and Review Process

Prediction market governance manages changes to core protocol parameters, market creation rules, fee structures, and treasury allocations. Unlike simple token voting, effective governance requires a structured pipeline to ensure proposals are well-defined, technically sound, and aligned with the protocol's long-term health. A typical process involves three key stages: proposal submission, a community review period, and an on-chain voting execution. Platforms like Polymarket and Omen have implemented variations of this model, often using snapshot voting for signaling and Gnosis Safe multi-sigs for execution.

The first step is establishing clear submission criteria. Proposals should be submitted via a public forum, such as a Discourse or Commonwealth channel, using a standardized template. This template must require: a concise title, a detailed specification of the change, the underlying rationale and expected impact, a link to any relevant code (e.g., a GitHub pull request for smart contract upgrades), and a formal on-chain voting proposal ready for execution. This pre-voting review period is critical for gathering community feedback, identifying flaws, and building consensus before committing gas fees for an on-chain vote.

During the review phase, delegates and token holders analyze the proposal. Key checks include security implications (audits for contract changes), economic effects on market liquidity and fee revenue, and legal compliance. For example, a proposal to change the dispute resolution mechanism in Augur v2 would undergo intense scrutiny regarding its game-theoretic incentives. Many protocols use a temperature check—a lightweight snapshot vote—to gauge initial sentiment before proceeding to a binding vote. This prevents network congestion and voter fatigue from poorly conceived proposals.

Finally, the proposal moves to an on-chain execution vote using a governance token like POLY or REP. The voting contract, often a customized Governor contract from OpenZeppelin, enforces a quorum and a majority threshold. A successful vote might automatically execute a function call, such as upgrading a proxy contract via TransparentUpgradeableProxy, or it may authorize a multi-sig to perform the action. It's vital to include a timelock between vote passage and execution, giving users a final window to exit positions if the change is contentious.

A well-designed governance process begins with defining the proposal lifecycle. This is a state machine that governs a proposal's journey from creation to resolution. Typical states include Pending, Active, Succeeded, Queued, and Executed. Each transition is triggered by specific conditions, such as passing a vote or a timelock delay. For on-chain systems, this logic is encoded in smart contracts, often using a governor contract pattern like OpenZeppelin's Governor. The contract must define key parameters: the voting period, quorum requirements, proposal threshold, and timelock duration.

Before writing any code, establish the prerequisites for proposal submission. This prevents spam and ensures serious contributions. Common requirements include holding a minimum amount of governance tokens (e.g., 0.1% of total supply) or delegating voting power. The system must also define the proposal format. Will proposals be simple function calls to upgrade a contract, or complex, multi-step operations described in an off-chain document? For the latter, a standard like EIP-4824: DAO Governance Interface proposes a common JSON schema for DAO metadata, linking an on-chain proposal ID to an off-chain description hosted on IPFS or Arweave.

The voting mechanism is a critical design choice. Will you use simple majority, quadratic voting, or conviction voting? Each has different trade-offs for security and voter engagement. The system must also handle vote delegation, allowing token holders to delegate their voting power to representatives or "delegates." This is often managed by a token contract that implements the IVotes interface. Furthermore, consider gas optimization. Voting on-chain can be expensive; solutions like Snapshot allow for gasless off-chain voting with on-chain execution, but introduce different trust assumptions.

Integration with a timelock contract is a security best practice for executable proposals. After a vote passes, the proposal actions are not executed immediately. Instead, they are queued in a timelock (e.g., OpenZeppelin's TimelockController) for a mandatory delay (e.g., 48 hours). This gives the community a final safety window to react if a malicious proposal slips through. The timelock becomes the sole executor for the Governor contract, centralizing privileged operations and allowing for transparent review of pending transactions.

Finally, design the review and challenge process. On-chain voting alone may not be sufficient for complex technical proposals. Many DAOs implement a multi-step flow: 1) A Temperature Check (off-chain poll) to gauge sentiment, 2) A Formal Submission with full specifications, 3) An Audit or Review Period where delegates or a security committee can analyze code, and 4) On-chain Voting for final ratification. Tools like Tally and Boardroom provide interfaces to manage this lifecycle. The system's smart contracts should be thoroughly audited, as they will control the DAO's treasury and core protocol logic.

A well-defined proposal standard is a set of rules and a template that all governance submissions must follow. It specifies required sections—like Abstract, Motivation, Specification, and Budget—and defines formatting rules. This standardization reduces administrative overhead for core teams and makes proposals easier for token holders to evaluate. For example, the Uniswap governance process mandates a specific forum post template and a seven-day discussion period before any on-chain vote, creating a predictable review cycle.

To set up a submission process, you first need to choose a platform stack. Most DAOs use a combination of a discussion forum (like Discourse or Commonwealth), a snapshot tool for off-chain signaling (e.g., Snapshot.org), and an on-chain voting contract (like OpenZeppelin Governor). The process typically flows: 1) Draft & social discussion, 2) Formal forum post using the template, 3) Temperature check via Snapshot, 4) Final on-chain proposal. Each stage should have clear entry criteria, like a minimum forum discussion period or a threshold of supporting votes in the temperature check.

The proposal template itself should enforce clarity and completeness. Key technical sections include a Technical Specification with any relevant smart contract addresses, function calls, and parameters. For a treasury spend proposal, this would detail the recipient address, amount, and asset. A code upgrade proposal must include the new contract address, a link to verified source code, and any audit reports. Using a markdown template in your forum ensures this data is consistently presented. Tools like GitHub Issues with predefined forms can also automate template enforcement for technical proposals.

Integrating these standards with your smart contracts is the final step. Your on-chain voting contract, such as a Governor contract, should be configured to only accept proposals that meet predefined criteria. This can include a minimum proposal submission deposit, a whitelist of proposer addresses (often based on token threshold), and validation logic that checks for required data in the proposal's calldata. The OpenZeppelin Governor documentation provides examples of using propose function modifiers to enforce these rules programmatically, preventing malformed proposals from reaching a vote.

Before code is written or a formal vote is cast, every substantial proposal must begin with a public, off-chain discussion. This typically occurs in a community forum like the Discourse-based Ethereum Magicians forum for Ethereum Improvement Proposals (EIPs), a dedicated Discord channel, or a Snapshot forum for DAO-specific governance. The goal is to socialize the idea, gather initial feedback, and gauge community sentiment. Skipping this step often leads to proposals failing due to unforeseen technical flaws, economic misalignments, or simply a lack of supporter awareness.

A well-structured discussion draft should clearly articulate the problem statement, the proposed solution, and the implementation details. For a protocol upgrade, this includes specifying the new contract functions and state variables. For a treasury spend proposal, it requires a detailed budget breakdown and deliverables. Participants should scrutinize the proposal's technical feasibility, security implications, and economic impact. Tools like temperature checks—informal polls on platforms like Snapshot—are used during this phase to measure support without committing on-chain resources.

The mandatory discussion period serves as a filter for low-effort or malicious proposals and a refinement workshop for good ones. It allows developers to point out potential vulnerabilities in the proposed code, economists to model tokenomics impacts, and delegates to understand their constituents' views. For example, a proposal to change Uniswap's fee switch mechanism would undergo weeks of debate on the Uniswap Governance Forum, with community members analyzing its effect on liquidity providers, traders, and UNI token holders before any formal voting.

To participate effectively, you should monitor the official governance forums for your protocol. When drafting a proposal, use templates provided by the DAO (like the Aave Request for Comments template) to ensure all necessary information is included. Engage with critics constructively and be prepared to publish multiple revised drafts based on feedback. This collaborative process transforms a raw idea into a robust, community-vetted executable plan, dramatically increasing its chances of successful on-chain passage.

An on-chain governance proposal is a transaction containing executable code or parameter changes. To submit one, you must construct a MsgSubmitProposal transaction. This message includes the proposal's title, description, a deposit amount, and the messages that will be executed if the proposal passes. These execution messages are defined using the chain's native Protobuf types, such as MsgCommunityPoolSpend for funding requests or MsgParameterChangeProposal for parameter updates. The proposal is signed and broadcast to the network by the proposer's wallet.

Upon submission, the proposal enters a deposit period, typically lasting 1-2 weeks. The initial deposit from the submitter is often only a fraction of the total min_deposit required by the chain's parameters (e.g., 64 ATOM for Cosmos Hub). During this period, any token holder can contribute to the proposal's deposit by sending a MsgDeposit transaction. This design prevents spam by requiring significant community skin-in-the-game before a proposal consumes network resources for a full vote. Proposals that fail to meet the min_deposit by the deadline are automatically removed, and deposits are refunded.

Once the total deposit meets or exceeds the min_deposit threshold, the deposit period ends immediately, and the proposal progresses to the voting period. The transition is automatic and is a key security feature, ensuring only proposals with demonstrated initial support move forward. It's crucial for proposers to calculate gas costs accurately and ensure their initial deposit is sufficient to get the proposal noticed, or to coordinate with delegates and community members to secure the remaining deposit promptly.

The voting period is the fixed duration during which token holders can cast their votes on a live proposal. This is defined in blocks (e.g., 65,000 blocks for ~7 days on a 9-second block chain) or seconds. A well-chosen period balances community engagement with decision-making speed. Too short a period risks low participation; too long can stall protocol evolution. In OpenZeppelin's Governor contracts, this is set via the votingDelay and votingPeriod parameters in the constructor or initializer.

Quorum is the minimum number of votes required for a proposal to be valid. It's typically defined as a percentage of the total token supply (e.g., 4%). This is a critical security parameter that prevents a small, potentially malicious group from passing proposals. Modern implementations like GovernorVotesQuorumFraction calculate quorum dynamically based on the token's total supply at the block a proposal is created, protecting against supply manipulation. Setting this value requires analyzing historical voter turnout and desired security thresholds.

Here is an example of initializing a Governor contract with these parameters using OpenZeppelin's modular system:

solidityCopy
contract MyGovernor is Governor, GovernorSettings, GovernorVotesQuorumFraction {
    constructor(IVotes _token)
        Governor("MyGovernor")
        GovernorSettings(7200 /* 1 day delay */, 50400 /* 1 week period */, 0)
        GovernorVotesQuorumFraction(_token, 4) // 4% quorum
    {}
}

The GovernorSettings sets a 1-day voting delay (blocks before voting starts) and a 1-week voting period. The GovernorVotesQuorumFraction sets a 4% quorum based on the _token supply.

After a proposal passes, it enters a timelock period before execution. This is not part of the voting configuration but is a separate security measure enforced by a TimelockController contract. The timelock gives users time to react to governance decisions, such as exiting a protocol if a malicious proposal passes. The governance executor must be the TimelockController, creating a clear separation between proposal approval and execution.

To manage these settings post-deployment, consider implementing a governance parameter upgrade path. Critical parameters like quorum or voting period may need adjustment as the community grows. The safest method is to make the governor itself upgradeable via a transparent proxy pattern, where changes to these settings require a new governance proposal, ensuring the community retains control over its own operating rules.

After a governance proposal passes, its execution must be handled securely to prevent malicious or erroneous state changes. The standard solution is a Timelock contract, which acts as a programmable delay and execution buffer. Instead of proposals executing immediately, they are queued in the Timelock for a predefined period (e.g., 48 hours). This creates a security window where stakeholders can review the calldata and destination addresses. If a proposal is found to be harmful, the community has time to prepare a counter-proposal to cancel it before execution.

Technically, the Timelock is the ultimate owner of the protocol's core contracts. When a proposal passes, the executor (often the Governor contract) does not call the target directly. Instead, it calls Timelock.queue(), which schedules the operation. The function requires parameters like target, value, data, and predecessor. A unique operationId is generated as a hash of these parameters. After the delay elapses, anyone can call Timelock.execute() with the same parameters to finally enact the change. This two-step process is critical for transparent and reversible governance.

Here is a simplified example of the flow using OpenZeppelin's Governor and Timelock contracts:

solidityCopy
// Proposal passes, now queue it
function queueProposal(uint256 proposalId) public {
    (address[] memory targets, uint256[] memory values, bytes[] memory calldatas, bytes32 descriptionHash) = governor.getActions(proposalId);
    for (uint i = 0; i < targets.length; ++i) {
        timelock.queue(targets[i], values[i], calldatas[i], 0, descriptionHash);
    }
}

// After delay, execute
function executeProposal(uint256 proposalId) public {
    (address[] memory targets, uint256[] memory values, bytes[] memory calldatas, bytes32 descriptionHash) = governor.getActions(proposalId);
    for (uint i = 0; i < targets.length; ++i) {
        timelock.execute(targets[i], values[i], calldatas[i], 0, descriptionHash);
    }
}

State management post-execution involves updating the DAO's on-chain records. The Governor contract should track a proposal's status through stages: Pending, Active, Canceled, Defeated, Succeeded, Queued, Expired, and Executed. After successful execution via the Timelock, the state must be finalized to Executed. This prevents re-entrancy or replay attacks where the same proposal actions could be executed again. Ensure your Governor's state() function checks the Timelock to confirm execution before returning the final state.

Best practices for this setup include: - Setting a minimum delay (e.g., 1-3 days) appropriate for your community's responsiveness. - Using a multisig or guardian role with the ability to cancel queued proposals in emergencies, as seen in Compound's Governor Bravo. - Clearly emitting events at each stage (ProposalQueued, ProposalExecuted) for off-chain indexing and notification bots. - Conducting dry-run simulations on a testnet fork before mainnet deployment to verify the entire queue/execute flow works with your specific contract interfaces.

Integrating a Timelock adds complexity but is non-negotiable for securing high-value protocols. It transforms governance from a single, irreversible transaction into a process with checks and balances. When designing your system, document the exact steps for users: 1) Vote on proposal, 2) Wait for voting period to end, 3) Queue proposal in Timelock, 4) Wait for Timelock delay, 5) Execute proposal. Tools like Tally and Defender can help automate monitoring and execution, reducing the operational burden on DAO members.

A successful governance deployment requires a phased rollout. Begin by deploying your smart contracts to a testnet like Sepolia or Goerli. Conduct a comprehensive audit of the entire workflow: test proposal creation, simulate voting with multiple wallets, and verify the execution of passed proposals. Use tools like Tenderly or Hardhat to create detailed transaction traces and monitor for any unexpected reverts or gas inefficiencies. This stage is critical for identifying logic errors before real funds are at stake.

After testing, plan your mainnet launch. For established DAOs, consider a timelock-enabled upgrade to a new contract. For new DAOs, deploy the contracts and initialize them with your chosen parameters: votingDelay, votingPeriod, proposalThreshold, and quorum. Use a multisig wallet (e.g., Safe) as the initial executor and admin. This provides a safety mechanism to pause the system or execute critical updates if a vulnerability is discovered post-launch, aligning with the principle of progressive decentralization.

Finally, document and socialize the process. Create clear guides for your community on platforms like Commonwealth or Discourse. Explain how to create a proposal, the standards for a successful submission (e.g., required templates, Snapshot space), and the review timeline. Establish clear roles: who are the protocol delegates or governance stewards responsible for initial review? Transparency here builds trust and increases participation. Your next step is to monitor governance activity and be prepared to iterate on parameters based on real-world usage and community feedback.