Setting Up Proposal Creation Workflows

A proposal workflow is the structured process that governs how a new idea moves from initial submission to an on-chain vote. It defines the rules for proposal creation, validation, and progression. In decentralized autonomous organizations (DAOs) like Compound or Uniswap, these workflows are critical for managing protocol upgrades, treasury allocations, and parameter changes. A well-designed workflow balances accessibility with security, preventing spam while ensuring legitimate proposals can be heard. The core components typically include a proposal factory smart contract, a set of validation criteria, and defined timelocks or delays before voting begins.

The first step in setting up a workflow is defining the proposal lifecycle. This lifecycle consists of several states: Pending, Active, Succeeded/Defeated, Queued, and Executed. For example, in OpenZeppelin's Governor contracts, a proposal starts in a pending state for a set period before moving to an active voting window. After voting concludes, successful proposals often enter a timelock period (e.g., 48 hours) before they can be executed, providing a final safety check. You must configure these durations (votingDelay, votingPeriod, timelock) based on your community's needs for deliberation and security.

Next, implement proposal validation to filter submissions. This is often handled by a proposal threshold, requiring the proposer to hold a minimum amount of governance tokens. For instance, a Compound Governor Alpha contract might require 65,000 COMP to submit. Alternatively, you can use a proposal whitelist or a multisig guardian to approve proposals before they go on-chain, a pattern used by Optimism's Governance. Validation logic can also check for correct formatting, such as ensuring target contract addresses and calldata are valid to prevent execution failures.

Here is a basic example of creating a proposal using the OpenZeppelin Governor contract interface in Solidity. The core action is forming the propose function call, which takes arrays of target addresses, values, and calldata.

solidityCopy
// Example: Proposing a treasury transfer
address[] memory targets = new address[](1);
uint256[] memory values = new uint256[](1);
bytes[] memory calldatas = new bytes[](1);
string memory description = "Transfer 1000 ETH to grants multisig";

targets[0] = treasuryAddress;
values[0] = 1000 ether;
calldatas[0] = abi.encodeWithSignature(
    "transfer(address,uint256)",
    grantsMultisig,
    1000 ether
);

governor.propose(targets, values, calldatas, description);

This code bundles the execution logic into a proposal that voters can approve or reject.

For advanced workflows, consider integrating off-chain voting platforms like Snapshot with on-chain execution. In this hybrid model, a temperature check or signaling vote happens off-chain via Snapshot, which is gas-free and allows broader participation. Only proposals that pass this initial hurdle are submitted as formal, executable on-chain proposals. This two-step process, used by many large DAOs, reduces network congestion and costs while maintaining the finality of on-chain execution. Tools like the OpenZeppelin Defender can be used to automate the relay of successful Snapshot proposals to your Governor contract.

Finally, ensure your workflow is transparent and accessible. Publish the complete proposal creation steps, including any off-chain requirements, in your protocol's documentation. Provide a verification step, such as emitting events when a proposal is created or using Etherscan's contract verification so users can inspect the exact calldata. A clear, audited workflow reduces confusion, increases participation, and strengthens the legitimacy of your governance system. Always test the entire proposal lifecycle on a testnet like Goerli or Sepolia before deploying to mainnet.

Before creating any on-chain proposal, you must establish a secure and functional development environment. This involves setting up a local blockchain node or connecting to a reliable RPC provider, configuring a wallet with sufficient gas funds, and installing necessary command-line tools. For Ethereum-based governance systems, you will typically need Node.js (v18+), a package manager like npm or yarn, and a wallet such as MetaMask. Ensure your wallet is connected to the correct network (e.g., Ethereum Mainnet, a testnet like Goerli or Sepolia, or a Layer 2 like Arbitrum) and has a small amount of the native token to pay for transaction gas during testing and deployment.

The core of proposal creation involves interacting with smart contracts. You will need the contract's Application Binary Interface (ABI) and its deployed address. The ABI is a JSON interface that defines how to call the contract's functions. You can often obtain this from the project's official documentation, GitHub repository, or a block explorer like Etherscan. For example, to interact with a Compound Governor Bravo contract, you would need the GovernorBravoDelegate ABI. Tools like the ethers.js or web3.js libraries are essential for connecting your application to the blockchain and constructing transactions.

A critical prerequisite is understanding the specific governance parameters of the protocol you are engaging with. These parameters, stored in the governance contract, define the rules of proposal creation and include: the proposalThreshold (minimum token balance required to submit), votingDelay (blocks before voting starts), votingPeriod (duration of the voting phase), and quorumVotes (minimum votes required for passage. You must query the live contract to get these current values, as they can be updated via governance itself. Failing to meet these requirements will cause your transaction to revert.

For automated testing and simulation, set up a local development framework. Hardhat or Foundry are industry-standard choices. These frameworks allow you to fork the mainnet state locally, deploy a copy of the governance contracts, and test proposal creation and execution end-to-end without spending real gas. This step is non-negotiable for security; it lets you verify that your proposal's calldata targets the correct functions and will execute as intended. Write tests that simulate the entire lifecycle: proposal submission, voting, queuing, and execution.

Finally, prepare your proposal payload. This consists of the target contract addresses, the ether value to send (usually 0), the function signatures, and the encoded arguments for each action the proposal will execute. Use the encodeFunctionData method from ethers.js to properly encode your calls. Organize this data and the accompanying description in a structured format, often a Markdown file, that will be uploaded to IPFS (e.g., via Pinata or nft.storage) to obtain a hash. This hash is a critical component of your proposal transaction.

On-chain governance executes decisions automatically through smart contracts. When a proposal passes, the contract code enacts the change directly, such as adjusting a protocol parameter or deploying new logic. This model, used by protocols like Compound and Uniswap, offers transparency and finality but requires all logic and data to be on-chain, which can be expensive and inflexible for complex discussions.

Off-chain governance separates the signaling of intent from its execution. Communities debate and vote using tools like Snapshot or forums, but the results are not self-executing. A trusted entity or multi-sig must manually implement the approved changes. This model, common in early-stage DAOs and projects like MakerDAO's initial processes, allows for richer discussion and lower costs but introduces execution risk and potential centralization.

Setting up a proposal workflow begins by defining the proposal lifecycle. A typical flow includes: 1) a temperature check on a forum, 2) formal draft creation, 3) an off-chain Snapshot vote for consensus, and 4) final on-chain execution by a timelock contract. This hybrid approach balances community input with secure execution.

For on-chain execution, you'll need a governance contract like OpenZeppelin's Governor. A proposal's calldata—the encoded function call to execute—must be prepared in advance. For example, a proposal to change the quorum in a Governor contract requires generating the calldata for the updateQuorumNumerator function, which is then submitted as part of the proposal.

The technical setup involves deploying a series of contracts: a token for voting power, a timelock controller for secure execution delay, and the core governor contract. Frameworks like OpenZeppelin Contracts Wizard can generate this skeleton. The governor is configured with parameters like voting delay, voting period, and proposal threshold, which define the workflow's pace and accessibility.

Ultimately, the choice between models depends on the protocol's needs. High-value DeFi protocols often require the security guarantees of on-chain execution, while social DAOs may prioritize flexible discussion off-chain. Many modern systems use a hybrid model, ensuring robust community signaling before any code is automatically executed on-chain.

A proposal workflow is a structured sequence of steps that transforms an idea into an executable on-chain transaction. The core architecture typically involves three layers: an off-chain coordination layer for drafting and signaling, a validation layer for security checks, and an on-chain execution layer for final submission. Tools like Snapshot for off-chain voting, Safe{Wallet} for multi-signature approval, and Tally for on-chain governance are commonly combined to create these pipelines. The goal is to balance security, efficiency, and community participation.

Start by defining the proposal lifecycle stages. A common pattern includes: Drafting (collaborative document editing), Temperature Check (off-chain sentiment polling on Snapshot), Security Review (smart contract audit or multi-sig sign-off), and On-chain Vote (final execution via a governor contract). Each stage should have clear entry criteria, responsible parties, and expected outputs. For example, a temperature check may require a minimum 5% quorum of token holders before progressing to a full audit.

The technical implementation connects these stages. You can use a workflow engine like OpenZeppelin Defender to automate stage transitions based on predefined conditions. For instance, a Defender Autotask can monitor a Snapshot vote; if it passes, it automatically creates a transaction in a Safe{Wallet} for the council's review. This eliminates manual oversight and reduces errors. Always encode the final proposal calldata—the target contract address, function selector, and arguments—early in the drafting phase to ensure accuracy.

Security is paramount in the validation layer. Before any on-chain action, proposals interacting with smart contracts must undergo simulation. Use tools like Tenderly or Foundry's forge to simulate the transaction's effects on a forked mainnet. Implement a multi-signature requirement for proposals over a certain value threshold; Gnosis Safe is the standard for this. This creates a timelock period where transactions are queued, allowing for a final community review before execution.

Finally, integrate feedback loops and documentation. Every workflow should log its progress on a public platform like GitHub Discussions or a dedicated forum. Use issue templates to standardize proposal submissions. After execution, archive the proposal data, including vote totals and transaction hashes, for full transparency. This creates a verifiable history, which is critical for decentralized organizations. By designing a deliberate workflow, you reduce governance overhead and increase the legitimacy of passed proposals.

Off-chain governance platforms like Snapshot and Tally have become essential for managing decentralized communities. They enable gasless, flexible voting on proposals using a snapshot of token holdings, which is ideal for gathering community sentiment before committing to an on-chain transaction. This separation of duties creates a two-phase workflow: first, a temperature check and formal vote occur off-chain, then a successful proposal is executed via a multisig or automated smart contract on-chain. This model reduces voter fatigue, lowers costs, and allows for more nuanced discussion.

Setting up a proposal creation workflow begins with configuring your space on Snapshot or governor on Tally. You must define key parameters that mirror your DAO's values: the voting token (e.g., an ERC-20 or ERC-721), voting strategies (like token-weighted or quadratic voting), and proposal thresholds. For instance, a common setup requires a minimum proposal submission threshold (e.g., 10,000 tokens) and a quorum (e.g., 4% of total supply). These settings are critical for preventing spam and ensuring legitimate proposals reach the voting stage.

The technical integration involves connecting your voting strategy to your token's data. Snapshot supports plugins to read balances from multiple sources—not just the mainnet, but also layer-2s or sidechains via a specific block number. A basic voting strategy in a space.json configuration might look like this:

jsonCopy
{
  "strategies": [
    {
      "name": "erc20-balance-of",
      "network": "1",
      "params": {
        "address": "0xYourTokenAddress",
        "symbol": "GOV",
        "decimals": 18
      }
    }
  ]
}

This strategy calculates voting power based on ERC-20 balances on Ethereum mainnet at the snapshot block.

For on-chain execution, you must establish a clear path from a passed Snapshot vote. Many DAOs use a Gnosis Safe multisig where designated executors validate the off-chain vote outcome and submit the corresponding transaction. More advanced setups use relayer networks or custom executor contracts that automatically execute proposals meeting specific criteria, like the OzGovernorExecutor in OpenZeppelin's Governor contracts. This bridges the trustless vote with a secure, often time-delayed, on-chain action, ensuring the will of the token holders is carried out faithfully.

Best practices for a robust workflow include implementing a timelock between vote conclusion and execution, which allows users to exit positions if they disagree with a passed proposal. Furthermore, maintain transparency by linking the on-chain execution transaction hash back to the original Snapshot proposal page. Regularly audit your voting strategies and executor permissions. Tools like Tally provide a unified interface for viewing both off-chain sentiment and on-chain proposal states, making the entire governance lifecycle transparent and accessible to all stakeholders.

You have successfully implemented a foundational proposal creation workflow. The core components you've configured include: a proposal factory contract for standardized creation, a timelock controller for secure execution, and a voting token for governance power. This architecture ensures proposals follow a predictable lifecycle from submission to execution, with built-in security delays to protect the protocol. The next step is to integrate this workflow with a frontend interface, such as a custom dApp or a platform like Tally, to make it accessible to your community.

To enhance your system's resilience and functionality, consider implementing these advanced features. Automated proposal validation can be added using Chainlink Functions or Gelato to check prerequisites off-chain before submission. For complex multi-step proposals, explore proposal modules that allow bundling multiple actions into a single vote. Security audits are critical; engage firms like OpenZeppelin or Trail of Bits to review your custom governor and factory logic. Finally, establish clear off-chain governance forums (e.g., using Discourse or Commonwealth) to facilitate discussion before proposals reach the chain.

Your workflow should be treated as a living system. Monitor key metrics using tools like Dune Analytics or The Graph to track proposal volume, voter participation rates, and execution success. Plan for upgradeability by making your governor contract use a transparent proxy pattern (e.g., OpenZeppelin's TransparentUpgradeableProxy), allowing you to fix bugs or add features without migrating the entire system. Continuously educate your community through documentation and workshops. The strength of on-chain governance lies not just in the code, but in an engaged and informed electorate that uses it effectively.