How to Design a Proposal and Voting Framework

The foundation of a DAO's governance is its proposal lifecycle. A standard process begins with a temperature check—an informal forum discussion to gauge community sentiment. If support is positive, the idea moves to a formal governance proposal. This proposal must be a self-contained document specifying the executable on-chain action, such as a treasury transfer or a smart contract upgrade. Clarity is critical; ambiguous proposals lead to failed execution or unintended consequences. Tools like Snapshot for off-chain signaling and Tally for on-chain execution are commonly used to manage this flow.

Proposal parameters define the rules of engagement. Key variables include the proposal threshold (minimum token balance to submit), voting delay (time between proposal submission and voting start), and voting period (duration votes can be cast). For example, a large protocol like Uniswap uses a 2.5 million UNI proposal threshold and a 7-day voting period. These settings balance agility with security—a short voting period may exclude global participants, while a long one can delay urgent decisions. The quorum requirement, a minimum percentage of total supply that must vote for a result to be valid, prevents low-turnout proposals from deciding major changes.

Voting mechanisms determine how preferences are aggregated. Token-weighted voting is the most common, where one token equals one vote. More advanced systems include quadratic voting (where cost scales quadratically with vote quantity to reduce whale dominance) and conviction voting (where voting power increases the longer a vote is locked). The choice impacts decentralization; simple token voting can lead to oligarchy, while complex systems may reduce participation. The voting options themselves—typically For, Against, and Abstain—must be clearly mapped to on-chain functions via a governance executor contract.

For on-chain execution, the proposal's calldata must target a specific function. In a Compound-style governor, a successful proposal queues for a timelock delay—a mandatory waiting period (e.g., 2 days) that allows users to exit if they disagree with the pending change. After the delay, anyone can execute the transaction. This pattern is crucial for security, providing a final window to veto malicious proposals. Here's a simplified structure for a proposal to transfer funds from a DAO treasury:

codeCopy
Target: TreasuryContract
Value: 0 ETH
Signature: transfer(address,uint256)
Calldata: [recipientAddress, 1000000000000000000] // 1 ETH

Effective frameworks also incorporate delegation to improve participation. Token holders can delegate their voting power to experts or representatives without transferring custody, as seen in the OpenZeppelin Governor standard. Post-vote, execution must be reliable. Using a multisig or a security council as a fallback executor can safeguard against bugs in proposal calldata. Continuous iteration is necessary; many DAOs use governance upgrades themselves to adjust parameters like quorum based on historical data, ensuring the system evolves with the community.

Before writing any code, you must define the core parameters of your governance system. This includes the proposal lifecycle (draft, active, voting, execution, closed), voting mechanisms (single-choice, quadratic, weighted), and quorum thresholds. Determine who can create proposals—will it be token holders, a council, or delegated representatives? Establish clear rules for voting power calculation, such as one-token-one-vote (1T1V), vote-escrowed tokens (veTokens), or non-transferable governance NFTs. These foundational decisions dictate the system's security, decentralization, and efficiency.

The primary technical prerequisite is a smart contract development environment. Use Hardhat or Foundry for local development, testing, and deployment. You'll need a basic understanding of Solidity to write the core contracts: a Governor contract (manages proposals), a Voting Token (ERC-20 or ERC-721), and optionally a TimelockController for secure, delayed execution. For rapid prototyping, consider using established standards like OpenZeppelin's Governor contracts, which provide audited, modular implementations for proposal lifecycle management, voting, and timelocks.

For on-chain voting, you must integrate with a token standard. An ERC-20Votes or ERC-721Votes contract is essential, as it provides a snapshot mechanism to prevent voting power manipulation during active proposals. Off-chain voting via Snapshot is a popular alternative for gas-free signaling. To implement it, you'll need to set up a Snapshot space, connect your token contract for voting strategies, and create an executor contract that can enact passed proposals on-chain, often using a bridge like the Snapshot X (formerly StarkNet) module or a Zodiac reality module for execution.

Security tooling is non-negotiable. Use Slither or MythX for static analysis during development. Before any mainnet deployment, a comprehensive audit from a reputable firm is mandatory. For ongoing operations, you'll need indexing and querying tools like The Graph to track proposal states and voting results. Frontend integration typically requires a Web3 library such as wagmi or ethers.js, and a UI component library like ConnectKit or RainbowKit to facilitate wallet connection and transaction signing for voters.

The foundation of on-chain governance is a formalized process for creating and deciding on proposals. A proposal is a structured request to execute a specific action, such as changing a protocol parameter, allocating treasury funds, or upgrading a smart contract. The voting framework defines the rules for how token holders or delegates can cast votes to approve or reject these proposals. Key initial decisions include determining who is eligible to propose (e.g., a minimum token stake) and the format proposals must follow (title, description, code links).

You must define clear voting parameters that balance security with participation. The primary parameters are:

• Voting Delay: The time between a proposal's submission and the start of voting. This gives the community time to review.
• Voting Period: The fixed duration (e.g., 3-7 days) during which votes can be cast.
• Quorum: The minimum percentage of the total voting power that must participate for the vote to be valid. A common mistake is setting this too high, which can lead to governance paralysis.
• Approval Threshold: The percentage of yes votes required for a proposal to pass (e.g., a simple majority of >50% or a supermajority of >66.6%).

Different voting mechanisms offer trade-offs. Token-weighted voting (one token, one vote) is simple but can lead to whale dominance. Quadratic voting reduces this by making the cost of votes increase quadratically, favoring broader consensus. Conviction voting allows users to stake tokens on a proposal over time, with voting power increasing the longer they support it, which is useful for continuous funding decisions. For most DAOs, starting with a straightforward token-weighted model using a governor contract like OpenZeppelin's Governor is recommended.

The execution of a passed proposal is a critical and often overlooked phase. After a vote succeeds, there is typically an execution delay or timelock period. This is a safety mechanism that prevents immediate execution, giving users a final window to exit the system if they disagree with the change. The proposal's calldata is then automatically executed by the governance contract, calling the target function with the specified parameters. It's crucial that proposals which transfer funds or upgrade contracts use a TimelockController contract as the executor to enforce this delay.

When designing your framework, analyze existing systems for reference. Compound's Governor Bravo and Uniswap's governance process are well-documented examples. Use established auditing firms to review your governance contracts before launch. Finally, consider gas costs for voters; optimizing voting strategies and potentially implementing vote delegation or snapshot voting (off-chain signaling) can improve accessibility and participation in your DAO's decision-making process.

On-chain governance allows token holders to vote directly on protocol changes, creating a transparent and decentralized decision-making process. OpenZeppelin provides a suite of audited, modular contracts that form the foundation for these systems. The core components are the Governor contract, which manages proposals; the Votes token, which tracks voting power; and the TimelockController, which introduces a security delay for executed actions. This modular design lets developers customize quorum rules, voting periods, and proposal thresholds while inheriting battle-tested security.

The first step is defining your voting token using OpenZeppelin's ERC20Votes or ERC721Votes extensions. These track historical voting power, preventing users from double-voting by transferring tokens after a proposal is created. For example, ERC20Votes uses checkpoints to record balances at the end of each block. You then deploy a Governor contract, such as GovernorCompatibilityBravo, and configure key parameters: votingDelay (blocks before voting starts), votingPeriod (blocks voting is open), and proposalThreshold (minimum tokens needed to propose).

Proposals are created by calling propose() on the Governor with a list of target addresses, values, and calldata for the actions to execute. Once a proposal is active, holders cast votes using castVote(), with options like For, Against, or Abstain. Voting power is calculated from snapshots taken at the proposal's creation block. After the voting period ends, the proposal must be queued through a Timelock, which enforces a mandatory delay (e.g., 2 days) before the actions can be executed. This delay gives users time to react to malicious proposals.

For enhanced security, integrate a TimelockController as the executor. The Timelock becomes the admin of the protocol's core contracts. When a proposal passes, it doesn't execute directly; instead, it schedules the calls via the Timelock. This pattern prevents a malicious proposal from executing instantly and allows for a "grace period" where users can exit the system if they disagree with the passed decision. The Governor must be granted the PROPOSER_ROLE on the Timelock, while a separate multi-sig or DAO should hold the EXECUTOR and CANCELLER roles.

Advanced configurations include setting a dynamic quorum using GovernorVotesQuorumFraction, which bases the required quorum on the total token supply at the block of the proposal. You can also support gasless voting by implementing EIP-712 typed signatures, allowing users to delegate votes via signed messages without paying gas. Testing is critical: use OpenZeppelin's test helpers to simulate proposal lifecycles across multiple blocks and ensure vote counting, state transitions, and execution delays work as intended under various scenarios.

A hybrid governance model leverages the strengths of both on-chain and off-chain systems. In this setup, Snapshot is used for gasless, flexible voting where members signal their preferences. Once a proposal passes off-chain, a trusted entity or smart contract executes the approved actions on-chain. This separation is crucial: it reduces voter fatigue from gas costs while maintaining the security guarantees of on-chain execution for treasury movements or protocol upgrades. Popular DAOs like Uniswap and Aave use this pattern to manage complex governance efficiently.

Designing your proposal framework starts with defining the voting strategies and validation criteria. In your Snapshot space settings, you configure how voting power is calculated—common strategies include erc20-balance-of (token-based), erc721-with-multiplier (NFT-based), or a custom strategy. You must also set the proposal validation rules, which determine who can create proposals. This is typically done by specifying a minimum token balance or a whitelist of addresses. These parameters establish the foundational rules of your DAO's decision-making process.

The core of the hybrid model is the execution bridge between Snapshot and your on-chain contracts. After a Snapshot vote succeeds, the result—proposal ID, votes for/against, and voter data—must be relayed on-chain. This is often handled by an off-chain executor (a multisig or a dedicated bot) or an on-chain relayer contract like Snapshot's SafeSnap module. The executor's role is to verify the proposal's passage on Snapshot and then call the corresponding function in your DAO's treasury or governor contract. This step enforces the community's will.

For technical implementation, you'll integrate with Snapshot's GraphQL API to fetch proposal results. A typical execution flow involves a script or a keeper that: 1) Queries the API for a specific proposal's state, 2) Validates it meets your predefined thresholds (e.g., quorum and majority), and 3) Submits the transaction. If using SafeSnap, you deploy a Module contract that allows a Gnosis Safe to execute transactions conditional on a verified Snapshot proof. The proof is generated using Snapshot's message signing scheme, ensuring the on-chain contract can trust the off-chain result.

Consider these security and design best practices. The executor (multisig or contract) should have limited, scoped permissions to only perform the actions defined in passed proposals. Implement a timelock on your treasury contracts to give users a window to exit if a malicious proposal passes. Clearly document the workflow for your community, specifying the delay between Snapshot voting and on-chain execution. Regularly audit the connection between your off-chain vote data and on-chain execution logic to prevent manipulation or replay attacks.

This hybrid approach is ideal for DAOs that require frequent, low-cost signaling on diverse topics but need enforceable, secure execution for financial transactions. By carefully designing your proposal thresholds, execution delay, and executor security model, you can create a resilient governance system that scales with your community's needs while protecting its assets.

The core of a decentralized governance system is a transparent and secure process for enacting changes. A well-designed framework typically involves three key stages: proposal creation, voting, and execution. Proposals are formal requests to execute specific actions, such as updating a protocol parameter or transferring funds from a treasury. These proposals are stored on-chain as struct objects, containing essential metadata like the proposer's address, a description, the target contract, the calldata for the action, and timestamps for the voting and execution periods.

The voting mechanism is the heart of community decision-making. Most frameworks use a token-weighted model, where voting power is proportional to the amount of governance tokens held. Key design considerations include the voting period (e.g., 3-7 days), quorum requirements (the minimum participation needed for a vote to be valid), and the vote differential (the margin required for a proposal to pass). Implementing these checks in the smart contract prevents low-turnout or contentious proposals from being executed. The OpenZeppelin Governor contract is a widely audited standard that provides a modular base for these features.

After a successful vote, the proposal must be queued in a timelock contract before execution. This is a critical security feature. The timelock introduces a mandatory delay (e.g., 48 hours) between a proposal's approval and its execution. This delay gives the community a final window to review the executed code and react if a malicious proposal somehow passed voting. The execution function should verify the proposal's state, ensure the timelock delay has elapsed, and then call the target contract with the approved calldata. This separation of voting and execution via a timelock is a best-practice pattern for mitigating governance attacks.

When auditing this framework, focus on several critical vulnerabilities. Ensure the proposal state (Pending, Active, Succeeded, Queued, Executed) transitions correctly and cannot be manipulated. Verify that the quorum and vote differential logic is mathematically sound and cannot be bypassed. Crucially, audit the interaction with the timelock: confirm that only the governance contract can queue and execute proposals on it, and that the timelock delay cannot be altered by a single proposal. Reentrancy guards should be present on state-changing functions.

For developers, integrating with OpenZeppelin's contracts provides a secure foundation. A basic proposal lifecycle in code involves: 1) calling propose() with target addresses and calldata, 2) users calling castVote() during the voting period, 3) anyone calling queue() after a successful vote to send it to the timelock, and 4) calling execute() after the delay passes. Always use the GovernorTimelockControl module to manage the timelock interaction. Thorough testing should simulate edge cases, such as proposals that change the voting parameters themselves.

A robust framework balances decentralization with security. The proposal and voting process empowers token holders, while the mandatory timelock delay acts as a final circuit breaker. By using battle-tested standards, implementing clear state machines, and conducting rigorous audits, projects can create governance systems that are both functional and resilient against exploitation. Always document the exact parameters (voting period, quorum, timelock delay) clearly for users.

The foundation of your framework is the proposal lifecycle. A proposal typically moves through distinct states: Pending (submitted), Active (voting open), Succeeded/Defeated (voting concluded), Queued (ready for execution), and Executed/Canceled. Smart contracts must enforce these state transitions and their associated permissions, such as who can create proposals, when voting starts, and how long it lasts. Common patterns are inspired by Compound's Governor Bravo and OpenZeppelin's Governor contracts, which provide modular, audited building blocks.

Voting mechanisms determine how power is expressed. The primary models are token-weighted voting (one token, one vote), where voting power is proportional to a user's stake, and delegated voting, which allows token holders to delegate their voting power to representatives. You must decide on vote counting: simple majority, quorum requirements (a minimum percentage of total supply must participate), and vote thresholds (e.g., 51% for, 20% quorum). Consider using snapshot voting for gas-free signaling off-chain before binding on-chain execution to reduce voter friction.

Implementation requires careful smart contract design. Use OpenZeppelin's Governor contract as a base, extending it with your voting token (IVotes), timelock controller (TimelockController), and custom voting delay/period settings. The proposal execution flow is critical: after a vote succeeds, proposals are typically queued in a timelock—a mandatory waiting period that allows users to react to passed proposals—before being executed. This is a key security feature. Always write comprehensive tests simulating the full lifecycle, including edge cases like proposal cancellation and quorum failure.

Security is paramount. Beyond the timelock, guard against governance attacks like vote sniping (last-minute vote manipulation) by using a voting period that ends at a fixed block, not a duration from proposal creation. Prevent proposal spam by requiring a minimum proposal threshold (e.g., 1% of token supply) to create a proposal. For ultimate upgrades, consider a multisig or guardian role as a fallback during the protocol's early stages, with a clear path to decentralization. Audit your contracts thoroughly, as governance modules hold supreme control.

Next steps involve deployment and community activation. Deploy your governance token, timelock, and governor contracts to a testnet first. Create clear documentation for users on how to create proposals, delegate votes, and participate. Use tools like Tally or Boardroom to provide a user-friendly interface for governance. Finally, establish initial governance parameters conservatively—shorter voting periods and lower thresholds can be adjusted later via governance proposals themselves, bootstrapping a live, self-governing system.