Decentralized proposals: From Draft to Vote to Execution with Auditability

This field guide shows decision‑makers how to design, launch, and audit an end‑to‑end governance pipeline—from drafting proposals to recording verifiable execution—using battle‑tested components like Snapshot, OpenZeppelin Governor, Safe/Zodiac, MultiGov, EAS, IPFS, The Graph, and modern monitoring stacks.

Why this matters in 2025

Onchain governance is no longer a “nice to have.” Protocol upgrades now span L1/L2s, off‑chain signaling must map deterministically to transactions, and auditors, partners, and regulators expect tamper‑evident records. The good news: today’s governance stack makes a fully auditable, configurable, cross‑chain pipeline practical—without sacrificing UX. This post distills how leading DAOs structure Draft → Vote → Execution with verifiable data exhaust you can monitor, reproduce, and independently prove. (docs.tally.xyz)

The three governance paths (and when to choose each)

Hybrid off‑chain voting with trustless execution
- Tooling: Snapshot + SafeSnap (Zodiac Reality module on Safe)
- Best when you want gasless voting, rich voting strategies, and on‑chain treasury execution. (docs.snapshot.box)
Fully on‑chain voting and execution
- Tooling: OpenZeppelin Governor + Timelock + Tally
- Best when votes, tallies, and proposal state must be canonical on chain. (docs.tally.xyz)
Cross‑chain voting and execution
- Tooling: MultiGov by Tally/Wormhole/ScopeLift
- Best when tokenholders are spread across Solana/Ethereum/L2s and you need hub‑and‑spoke governance with aggregated tallies and multi‑chain execution. (wormhole.com)

The rest of this guide shows how to stand up each path with auditability baked in.

Path A — Hybrid: Snapshot → SafeSnap → Safe execution

Snapshot gives gasless, EIP‑712‑signed voting; SafeSnap makes those votes executable onchain by asking Reality.eth “did the off‑chain vote pass and do these tx payloads match?”—then lets anyone execute via the DAO’s Safe after cooldown. (eips.ethereum.org)

A1. Draft

Create a Snapshot “space” (requires an ENS name) and configure strategies/validations; Snapshot stores proposals and votes on IPFS with CIDs visible in the UI. Store your space config as an ENS text record pointing to an IPFS CID. (docs.ipfs.tech)
Use EIP‑712 typed data for proposal and vote signatures (Snapshot deprecated personal_sign long ago). (snapshot.mirror.xyz)
Include in your proposal body:
- An execution plan (list of Safe multisend tx payloads).
- CIDs for attachments (risk analysis, audit notes, simulation reports).
- An attestation reference (see EAS below). (docs.ipfs.tech)

Practical detail: Snapshot’s data layer writes every action to IPFS and indexes in MySQL for performance; the UI links to each action’s CID—critical for audit trails. (docs.ipfs.tech)

A2. Vote

Voters sign gasless EIP‑712 messages; eligibility is enforced by your strategies (ERC‑20 balances, NFTs, custom logic). Consider enabling shielded voting via Shutter to mitigate vote‑buying and social pressure (public tally, private ballots). (docs.snapshot.box)
For Sybil resistance on some programs (e.g., Optimism’s Citizens’ House), pair off‑chain identity/reputation gating with Snapshot validation logic. (community.optimism.io)

A3. Execution (SafeSnap)

The Zodiac Reality module encodes a Reality.eth “question” that references the Snapshot proposalId (IPFS CID) and the array of tx hashes for the Safe multisend. After cooldown and arbitration window, anyone can execute the queued multisend on the Safe. (github.com)
Operator checklist that reduces execution risk:
- Set a meaningful Reality bond, choose an arbitrator, and use a ≥24h cooldown. (zodiac.wiki)
- Monitor ProposalQuestionCreated(questionId, proposalId) and outcome events; wire alerts to Slack/PagerDuty. (gnosisguild.github.io)
- If using Tellor or other oracles instead of Reality, ensure the Snapshot proposalId and txHashes are consistently referenced on‑chain. (github.com)

Why this is auditable: the proposal’s CID and each Safe transaction hash are linked via Reality.eth events; the Safe Transaction Service exposes module and multisig executions via API for downstream indexing. (docs.safe.global)

Path B — Fully on‑chain: OpenZeppelin Governor + Timelock

OpenZeppelin’s modular Governor is the de‑facto standard (used by ENS, Uniswap, Compound). You’ll pick modules for voting power, quorum, counting, timelock, and safety features (e.g., prevent late quorum, proposal guardian). (docs.openzeppelin.com)

B1. Draft

Encode targets/values/calldatas and a human‑readable description. Compute descriptionHash as keccak256(bytes(description))—this exact encoding matters for the proposalId and for later queue/execute calls. Many teams have broken cancellations by hashing differently. (docs.openzeppelin.com)
Choose parameters up front (and document them in your repo):
- votingDelay, votingPeriod (ERC‑6372 clock‑mode aligned with your token) (docs.openzeppelin.com)
- quorum model: For‑only quorum (Bravo semantics) or For+Abstain (disclosed via module params) (docs.openzeppelin.com)
- proposalThreshold (min voting power to propose)
- timelock delay (2 days is common, e.g., ENS/Uniswap) (docs.ens.domains)
- safety extensions: GovernorPreventLateQuorum, ProposalGuardian, SequentialProposalId, and Storage for enumerability. (docs.openzeppelin.com)

Concrete references you can benchmark against:

ENS: 1% quorum (≈1M ENS), 7‑day on‑chain vote, 2‑day timelock; 10k/100k ENS thresholds for social/executable proposals. (basics.ensdao.org)
Uniswap (Governor Bravo): 2.5M UNI to propose, 7‑day vote, 40M UNI quorum, 2‑day timelock. (docs.uniswap.org)

B2. Vote

Use ERC20Votes/IVotes for snapshots; the Governor inherits the token’s clock mode (ERC‑6372), ensuring consistent “past votes” lookups across L2s. Consider Flexible Voting (fractional split of For/Against/Abstain) to unlock voting from L2s, custodians, or yield vaults. (old-docs.openzeppelin.com)
If you’re upgrading from Bravo/Alpha, Tally’s docs enumerate the function signatures and state machine they expect; match them to ensure UI and API compatibility. (docs.tally.xyz)

B3. Execution

Queue with the same targets/values/calldatas and descriptionHash you used for proposing; execute after timelock expires. These actions emit ProposalQueued/Executed—and those events are your canonical, indexable audit trail. (docs.openzeppelin.com)

Safety note: OpenZeppelin fixed a proposal‑creation front‑run DoS in v4.9.1 by adding optional proposer‑protection. If you’re on older versions, upgrade or use protected endpoints when proposing. (miggo.io)

Path C — Cross‑chain: MultiGov (hub–and–spoke, aggregated tallies)

When your community spans chains, MultiGov lets tokenholders create, vote, and execute from any supported chain (Solana, Ethereum, EVM L2s). Votes from “spoke” Governors are transmitted to a “hub” Governor via Wormhole VAAs; the hub tallies and triggers execution locally and on spokes. (wormhole.com)

C1. Draft

Pre‑requisites: an ERC20Votes governance token that supports CLOCK_MODE timestamps (EVM) and an SPL token (Solana); Flexible Voting is used on the hub. (wormhole.com)
Architecture components to provision: HubGovernor, SpokeVoteAggregators, HubVotePool, and cross‑chain message dispatchers. (docs.wormhole.com)

C2. Vote

Tokenholders vote on their local chain; votes are checkpointed and relayed to the hub. UX is unified in Tally; Wormhole has reported real proposals and participation since launch in April 2025. (wormhole.com)

C3. Execution

After the hub finalizes, it executes locally (timelock rules apply) and dispatches cross‑chain execution messages to spokes. SREs should monitor message delivery and reconcile hub ↔ spoke state. (wormhole.com)

Make it auditable: the data you must produce and keep

Auditability means a third party can reconstruct what happened without asking you for internal context. Ship these artifacts automatically.

DAO identity and contract map (machine‑readable)

Publish a daoURI and contractsURI per ERC‑4824 so indexers and toolchains can locate your members, proposals, and contract set across chains. This is how >200 orgs standardize discovery. (eips.ethereum.org)

Proposal content and attachments (content‑addressed)

Every draft, forum link, and artifact should have an IPFS CID. Snapshot already does this; consider pinning via multiple services (Snapshot uses “Pineapple” to race pinning and stores to S3 for resilience). Put the CID into on‑chain descriptions or metadata. (docs.ipfs.tech)

Attestations for off‑chain steps

Use Ethereum Attestation Service (EAS) to attest to proposal metadata: forum thread URL hash, simulation results, audit pull‑request SHA, KYC/KYB for grant recipients, etc. EAS maintains on‑chain Schemas and contracts across mainnet and L2s; mainnet addresses are public. (attest.org)

Contract verification in multiple registries

Verify governance/timelock/treasury contracts on Sourcify (exact‑match), Etherscan (API v2), and other explorers; “exact match” adds cryptographic guarantees and improves wallet warnings. Sourcify provides API v2 and a multi‑verifier Remix plugin; Etherscan v1 API is being deprecated (Aug 15, 2025)—migrate now. (docs.sourcify.dev)

Indexing for analytics and evidence

Deploy a subgraph that ingests ProposalCreated, VoteCast, ProposalQueued, ProposalExecuted, and (if applicable) Reality/Zodiac events. Use The Graph; examples exist for ENS Governance and Moloch/DAOhaus. (thegraph.academy)

Monitors and runbooks

Set monitors for governance, access‑control, suspicious activity, and technical risk. You can use OpenZeppelin Defender Monitor (note: new sign‑ups disabled since June 30, 2025; open‑source alternatives like openzeppelin‑monitor exist) or roll your own with explorer/websocket feeds. Document pager thresholds. (docs.openzeppelin.com)

Implementation playbooks (copy/paste checklists)

A. Snapshot + SafeSnap in two weeks

Day 1–2: Register ENS; configure Snapshot space; publish space config CID in ENS text record. (docs.ipfs.tech)
Day 3–4: Deploy a Safe; add the Zodiac Reality module; set Reality templateId, arbitrator, timeout, cooldown, and minimum bond. (zodiac.wiki)
Day 5–6: Draft proposal with multisend payloads; include IPFS CIDs for attachments; publish on Snapshot. (docs.snapshot.box)
Day 7–11: Voting window; optionally enable Shutter shielded voting for sensitive decisions. (blog.shutter.network)
Day 12–14: After Reality resolves “yes” and cooldown expires, execute multisend; archive Safe tx hashes, questionId, and snapshot CID in your proposals registry (see ERC‑4824). (github.com)

B. OpenZeppelin Governor in three sprints

Sprint 1: Deploy ERC20Votes; deploy Governor with:
- GovernorVotes, GovernorVotesQuorumFraction
- GovernorTimelockControl
- GovernorPreventLateQuorum and GovernorProposalGuardian
- Voting delay/period and quorum numerator documented
- Unit tests verifying proposalId hashing and queue/execute with descriptionHash. (docs.openzeppelin.com)
Sprint 2: Wire Tally; validate function signatures and state mapping; test castVoteBySig flows. (docs.tally.xyz)
Sprint 3: Launch; publish daoURI/contractsURI; verify contracts on Sourcify/Etherscan; deploy subgraph; turn on monitors. (eips.ethereum.org)

C. MultiGov (pilot on hub + one spoke)

Week 1: Confirm ERC20Votes supports CLOCK_MODE; deploy HubGovernor with Flexible Voting; deploy one SpokeVoteAggregator (e.g., Base). (wormhole.com)
Week 2: Create a small parameter‑change proposal; vote on the spoke; confirm hub tally and execution; test replay‑protection and message reliability. (wormhole.com)
Week 3: Extend to a second spoke; add monitors for cross‑chain delivery success and reconcile hub vs spoke state after execution. (docs.wormhole.com)

Emerging best practices you should adopt now

Use Flexible Voting everywhere you can
- It’s now integrated with OpenZeppelin (GovernorCountingFractional), enabling delegates to split votes and enabling L2/custody voting—adopted across major DAOs. (github.com)
Bake anti‑frontrun into proposal creation
- Ensure your Governor is ≥ v4.9.1 and use the proposer‑protection mechanism; otherwise use protected RPCs for proposing. (miggo.io)
Standardize your metadata
- ERC‑4824 daoURI/contractsURI makes your governance machine‑readable across tools and chains. (eips.ethereum.org)
Attest your off‑chain process
- EAS schemas let you reliably tie off‑chain review, audits, and compliance checks to proposal artifacts. (attest.org)
Store CIDs in descriptions
- Include IPFS CIDs of proposal docs in the Governor description before hashing; this improves replayability and third‑party validation. See OZ docs for hashing behavior. (docs.openzeppelin.com)
Consider shielded voting for sensitive decisions
- Shutter + Snapshot “permanent shielded voting” is rolling out; plug it in for elections, compensation, or contentious proposals. (blog.shutter.network)
Plan for multi‑chain governance, even if you’re single‑chain today
- MultiGov has matured; design your token as ERC20Votes with clean CLOCK_MODE so you can expand later. (wormhole.com)

Security, risk, and “what can go wrong”

Late‑quorum attacks
- Use GovernorPreventLateQuorum to extend voting if quorum is reached just before close. (docs.openzeppelin.com)
Mis‑hashed descriptions and broken cancellations
- Always hash the raw bytes of the description string; mismatches break cross‑domain cancel flows. Test queue/execute/cancel round‑trips in CI. (openzeppelin.com)
Off‑chain oracle mis‑resolution (SafeSnap)
- Choose a credible arbitrator, set a meaningful bond/escalation path, and monitor questions; invalidate malicious proposals via module hooks if necessary. (realitio.github.io)
Cross‑chain delivery risk
- Monitor VAAs and reconcile hub/spoke state; define a runbook for failed deliveries and re‑broadcasts in MultiGov. (wormhole.com)

What “good” looks like: metrics to track

Participation
- Delegate participation rate; voter distribution across chains (for MultiGov). (newsletter.tally.xyz)
Latency
- Time from Draft → Vote open; Vote close → Queue; Queue → Execute (compare to ENS/Uniswap norms). (docs.ens.domains)
Integrity
- % proposals with verified execution (events + Safe tx hashes); % proposals with EAS attestations and IPFS CIDs in descriptions. (old-docs.openzeppelin.com)
Operability
- Mean time to acknowledge (MTTA) Reality questions and cross‑chain delivery alerts; monitor coverage for governance events. (docs.openzeppelin.com)

Brief, in‑depth details: concrete examples you can copy

ENS governance param snapshot
- Quorum: 1% (~1M ENS), on‑chain voting 7 days, 2‑day timelock, 100k ENS threshold for executable proposals. Use it as a starting point for blue‑chip token governance. (basics.ensdao.org)
Uniswap governance thresholds
- 2.5M UNI proposal threshold, 40M UNI quorum, 7‑day voting, 2‑day timelock; demonstrates classic Bravo semantics. (docs.uniswap.org)
Cosmos‑style deposit and veto parameters (contrast)
- For chains using Cosmos SDK x/gov: min deposit 250 ATOM, 14‑day deposit/voting, 40% quorum, 33.4% veto threshold—useful reference if you’re designing your own appchain. (hub.cosmos.network)

Monitoring blueprint (one hour to value)

Subscribe to:
- Governor events: ProposalCreated, VoteCast, ProposalQueued, ProposalExecuted. (old-docs.openzeppelin.com)
- Zodiac Reality: ProposalQuestionCreated, outcome finalized. (gnosisguild.github.io)
- Safe Transaction Service: module and multisig executions for your Safe. (docs.safe.global)
Send alerts to Slack/Telegram with severity tags; archive raw event JSON and tx receipts to an S3 bucket keyed by proposalId. Use Defender Monitor or the open‑source openzeppelin‑monitor as your starting point. (docs.openzeppelin.com)

Final recommendations (decision‑maker’s cut)

If you need fast time‑to‑value with real execution: Snapshot + SafeSnap is a proven hybrid that’s auditable enough for grants/treasury ops; pair it with strong monitoring and EAS attestations. (docs.snapshot.box)
If your decisions are protocol‑critical: deploy OpenZeppelin Governor with PreventLateQuorum, ProposalGuardian, TimelockControl, and Flexible Voting; integrate Tally; publish ERC‑4824 metadata. (docs.openzeppelin.com)
If you’re growing multi‑chain: pilot MultiGov on one spoke; measure latency and participation; expand once delivery SLOs are met. (wormhole.com)

7Block Labs has designed and audited pipelines like these across L1s/L2s. If you want a turnkey blueprint (contracts, subgraph, monitors, and runbooks) we can deliver it in sprints aligned to your risk profile.

Appendix — Glossary and references you’ll actually use

ERC‑4824 daoURI/contractsURI for DAO discoverability and tool interoperability. (eips.ethereum.org)
EIP‑712 typed signatures for off‑chain voting; see Snapshot integrator guidance. (eips.ethereum.org)
OpenZeppelin Governor modules catalog (votes/quorum/timelock/prevent‑late‑quorum/proposal‑guardian). (docs.openzeppelin.com)
Flexible Voting (ScopeLift) enabling fractional vote splits, custody/L2 voting. (github.com)
MultiGov (Tally/Wormhole) hub‑and‑spoke cross‑chain governance. (wormhole.com)
EAS for attestations (schemas + mainnet deployments). (github.com)
Sourcify/Etherscan verification (migrate to Etherscan API v2 before Aug 15, 2025). (docs.sourcify.dev)

Description: A 2025 field guide for decision‑makers to design and launch an auditable governance pipeline—from Snapshot or OpenZeppelin Governor to Safe/Zodiac and MultiGov—complete with standards (ERC‑4824, EIP‑712), attestations (EAS), indexing (The Graph), and monitoring you can deploy today.