Decentralized proposals: From Draft to Vote to Execution with Auditability

This field guide is designed to support decision-makers as they create, launch, and manage a full governance pipeline. We’ll walk you through everything from drafting proposals to tracking verifiable actions. You’ll be utilizing reliable tools like Snapshot, OpenZeppelin Governor, Safe/Zodiac, MultiGov, EAS, IPFS, The Graph, and the newest monitoring stacks.

Why this matters in 2025

Onchain governance has shifted from being a "nice to have" to something we really can't live without. With protocol upgrades happening across both L1 and L2s, it's super important for off-chain signals to connect seamlessly with transactions. Plus, folks like auditors, partners, and regulators are now looking for records that are completely secure and tamper-proof.

The good news? The governance stack available today lets us create a fully auditable, customizable, and cross-chain pipeline without sacrificing user experience. In this post, we're diving into how top DAOs tackle the Draft → Vote → Execution process, sharing verifiable data that you can easily track, replicate, and prove on your own. Don’t forget to check it out here: (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)
- If you're after gasless voting, flexible strategies, and smooth on-chain treasury execution, this approach is just what you need. Dive deeper into it here: (docs.snapshot.box).
Fully On‑Chain Voting and Execution
- Tooling: OpenZeppelin Governor + Timelock + Tally
- Want to make sure your votes, tallies, and proposal statuses are all officially on-chain? This is the perfect solution for you. Check out more details here: (docs.tally.xyz).
Cross‑Chain Voting and Execution
- Tooling: MultiGov by Tally/Wormhole/ScopeLift
- If your tokenholders are scattered across Solana, Ethereum, and different Layer 2s, this setup is perfect for you. It allows for hub-and-spoke governance, plus it’s great for aggregating votes and executing actions across multiple chains. Want to dive deeper? Check it out here: (wormhole.com).

The rest of this guide is all about getting each path up and running with built-in auditability.

Path A -- Hybrid: Snapshot → SafeSnap → Safe execution

Snapshot provides gasless voting that's signed using EIP-712. SafeSnap ups the game by making those votes actually actionable on-chain. It verifies with Reality.eth to confirm if the off-chain vote was a success and ensures that the transaction payloads match up. After a cooldown period, anyone can go ahead and execute it through the DAO’s Safe. If you want to dive deeper into EIP-712, check it out here.

A1. Draft

To kick things off, you'll need to create a Snapshot “space.” Just a quick note--you’ll have to use an ENS name for that. Once you've got it all set up, you can dive into configuring your strategies and validations. Snapshot handles proposals and votes by storing everything on IPFS, and you can easily find the CIDs right in the user interface. And don’t forget to save your space configuration as an ENS text record that links to the IPFS CID. For more info, check out the details here.
Next, be sure you’re using EIP‑712 typed data for your proposal and vote signatures. Just a heads up, Snapshot stopped using personal_sign quite some time ago. If you want to dive deeper into this, check out the Snapshot Guide.
As you put your proposal together, make sure to include:
- An execution plan--this is essentially a list of Safe multisend tx payloads.
- CIDs for any attachments, like your risk analysis, audit notes, or simulation reports.
- An attestation reference (more details on EAS below). You can check out the guide here.

Practical Detail: Snapshot’s data layer tracks every action in IPFS and organizes everything in MySQL to boost performance. The UI makes it easy to access each action’s CID, which is crucial for keeping those audit trails intact. (docs.ipfs.tech)

A2. Vote

Voters can send gasless EIP‑712 messages, and your strategies will handle checking eligibility--whether it’s based on ERC‑20 balances, NFTs, or any custom rules you’ve set up. You might also want to consider using shielded voting with Shutter. It’s a good way to cut down on problems like vote-buying and social pressure, since it allows for public tallies while keeping ballots private. (docs.snapshot.box)
If you're brainstorming ways to improve Sybil resistance in programs like Optimism’s Citizens’ House, think about mixing off-chain identity and reputation checks with Snapshot validation logic. It could really help strengthen your approach. (community.optimism.io)

A3. Execution (SafeSnap)

The Zodiac Reality module is all about encoding a Reality.eth "question" that connects to the Snapshot proposalId (IPFS CID) along with the list of transaction hashes for the Safe multisend. Once the cooldown and arbitration period pass, anyone can step in and execute that queued multisend on the Safe. If you're curious, you can dive deeper here.
Here’s a handy checklist for operators to help you keep execution risk as low as possible:
- First things first--make sure to establish a solid Reality bond, pick your arbitrator, and stick to a cooldown period of at least 24 hours. If you want some more details, check this out here.
- Stay on top of ProposalQuestionCreated(questionId, proposalId) and outcome events, and set up alerts to let you know through Slack or PagerDuty when things happen.
- If you’re going with Tellor or other oracles instead of Reality, just double-check that the Snapshot proposalId and txHashes are consistently shown on-chain. You can find more info about that here.

Why This is Auditable

You can find a connection between the proposal's CID and every Safe transaction hash via Reality.eth events. On top of that, the Safe Transaction Service really simplifies accessing both module and multisig executions through its API--this is awesome for downstream indexing. For more info, take a look here.

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

OpenZeppelin’s modular Governor has quickly become the standard for managing governance, and it’s already being utilized by well-known platforms like ENS, Uniswap, and Compound. This flexible setup lets you pick and choose from various modules to manage voting power, quorum, counting, timelocks, and a bunch of safety features. You can even prevent late quorum and add a proposal guardian! Dive into the details in the docs!

B1. Draft

First things first, you'll need to encode your targets, values, and call data, and don’t forget to whip up a human-readable description. To grab your descriptionHash, just use keccak256(bytes(description)). Seriously, nailing this encoding is crucial for both the proposalId and those queue/execute calls down the line. I've seen plenty of teams run into issues with cancellations just because they didn’t hash it the right way. You can find more info on it here: (docs.openzeppelin.com)
First off, it’s a good idea to figure out your parameters ahead of time and make a note of them in your repo:
- votingDelay and votingPeriod: Stick to the ERC‑6372 clock mode to keep everything in sync with your token (docs.openzeppelin.com).
- quorum model: Decide whether you want to go with a For-only quorum (Bravo semantics) or For+Abstain, and you’ll need to include this in your module parameters (docs.openzeppelin.com).
- proposalThreshold: This is the minimum voting power you’ll need to put forward a proposal.
- timelock delay: A 2-day delay is pretty standard, just like with ENS or Uniswap (docs.ens.domains).
- safety extensions: Think about adding GovernorPreventLateQuorum, ProposalGuardian, SequentialProposalId, and Storage. These can really help with better enumerability (docs.openzeppelin.com).

Here are some solid references you can check out as benchmarks:

ENS: To get things rolling, you'll need a 1% quorum, which is about 1 million ENS. The voting period lasts for 7 days, followed by a 2-day timelock. Plus, there are thresholds of 10k/100k ENS for social and executable proposals. You can dive deeper into the details here.
Uniswap (Governor Bravo): If you're looking to make a proposal, you'll have to gather 2.5 million UNI. Just keep in mind that the voting lasts for 7 days and you’ll need a quorum of 40 million UNI. Also, don’t forget there’s a 2-day timelock to consider. For more info, check it out here.

B2. Vote

When you're working with ERC20Votes/IVotes for snapshots, remember that the Governor picks up the token's clock mode from ERC‑6372. This ensures that “past votes” lookups remain consistent across different Layer 2 solutions. You might also want to think about using Flexible Voting. This feature lets you create a fractional split between For/Against/Abstain, which can really help you gather votes from L2s, custodians, or yield vaults. Check it out here.
So, if you're transitioning from Bravo/Alpha, definitely check out Tally’s documentation. It lays out the function signatures and state machine requirements you’ll need to follow. Just be sure to align everything to keep your UI and API working seamlessly. For more info, you can dive into their docs here.

B3. Execution

Make sure you line up the same targets, values, call data, and descriptionHash that you used for your proposal. Once the timelock hits, go ahead and execute it. Doing this will kick off the ProposalQueued and ProposalExecuted events, creating your official, indexable audit trail. You can find all the details here: (docs.openzeppelin.com)

Safety Note: OpenZeppelin has just dropped a fix for a proposal-creation front-run DoS in v4.9.1 by adding optional proposer protection. If you're using an older version, be sure to upgrade or stick to protected endpoints when making your proposals. You can check out the full details here.

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

When your community spans multiple chains, MultiGov makes it super simple for token holders to create, vote, and execute actions across any of the supported networks like Solana, Ethereum, and EVM Layer 2s. Votes from “spoke” Governors are sent to a “hub” Governor through Wormhole VAAs. The hub handles the vote counting and kicks off the execution both locally and on the spokes. You can check it out here: (wormhole.com).

C1. Draft

Pre-requisites: Before you dive in, make sure you have an ERC20Votes governance token that fits with CLOCK_MODE timestamps (EVM), plus an SPL token from Solana. Oh, and just so you know, Flexible Voting is active on the hub. For all the juicy details, take a look here: wormhole.com.
Architecture components to provision: Get ready to roll up your sleeves and set up some essential components: HubGovernor, SpokeVoteAggregators, HubVotePool, and those super useful cross-chain message dispatchers. For all the details you need, check out the docs: docs.wormhole.com.

C2. Vote

Tokenholders submit their votes directly on their local chain, and then those votes get checkpointed and sent over to the hub. The Tally user experience keeps everything organized in one spot; Wormhole has been rolling out real proposals and participation stats since it launched in April 2025. (wormhole.com)

C3. Execution

After the hub finishes its tasks, it operates locally (don’t forget about those timelock rules) and sends cross-chain execution messages to the spokes. It’s wise for SREs to monitor message delivery to ensure that the hub and spoke states are in sync. You can learn more about it here: (wormhole.com)

Make it auditable: the data you must produce and keep

Auditability means that someone not involved in the process can understand what happened without needing any inside scoop from you. So, be sure to automatically send out these artifacts!

DAO Identity and Contract Map (machine-readable)

When you publish a daoURI and contractsURI according to ERC-4824, you help indexers and toolchains easily locate your members, proposals, and contracts across various chains. This approach is being used by over 200 organizations to make discovery a breeze. (eips.ethereum.org)

Proposal content and attachments (content‑addressed)

Ensure that every draft, forum link, and artifact gets its own IPFS CID. Snapshot has nailed this process, so it's definitely a good idea to look into different pinning services they use. They rely on “Pineapple” to enhance pinning speed, and they also back things up on S3 for extra durability. And hey, make sure to include the CID in your on-chain descriptions or metadata. You can read more about it here: (docs.ipfs.tech)

3) Attestations for Off-Chain Steps

Take a look at the Ethereum Attestation Service (EAS) if you're looking to get your proposal metadata certified. This covers things like the forum thread URL hash, simulation results, audit pull-request SHA, and KYC/KYB info for those grant recipients, among other details. EAS is all about keeping tabs on on-chain schemas and contracts across both the mainnet and L2s, and you can easily find the mainnet addresses available for everyone. Check it out here: (attest.org)

4) Contract Verification in Multiple Registries

Don't forget to check the governance, timelock, and treasury contracts on Sourcify for an exact match, as well as on Etherscan (API v2) and other explorers. Getting that “exact match” is crucial because it adds some cryptographic guarantees and provides better warnings for wallets. Sourcify has its own API v2 and even a cool multi-verifier plugin for Remix, so make sure you utilize those! Just a friendly reminder: Etherscan v1 API is going away on August 15, 2025, so it’s a good idea to migrate now if you haven't done so. You can find more details here: (docs.sourcify.dev).

5) Indexing for Analytics and Evidence

Set up a subgraph that grabs events such as ProposalCreated, VoteCast, ProposalQueued, ProposalExecuted, and any relevant Reality/Zodiac events. If you're looking for solid examples, The Graph has some fantastic ones, particularly from ENS Governance and Moloch/DAOhaus. For more info, check out this guide: thegraph.academy.

6) Monitors and Runbooks

Setting up monitors for things like governance, access control, suspicious activity, and any technical risks is definitely a smart move. You might want to consider using OpenZeppelin Defender Monitor, but just so you know, they stopped accepting new sign-ups as of June 30, 2025. If you’re exploring other options, there are some cool open-source alternatives like openzeppelin-monitor, or you could even create your own using explorer/websocket feeds. Just don’t forget to document those pager thresholds! For more info, check this out: OpenZeppelin Docs.

Implementation playbooks (copy/paste checklists)

A. Snapshot + SafeSnap in two weeks

Day 1-2: Start your journey by registering your ENS. After that, set up your Snapshot space. And hey, make sure to publish the space config CID in your ENS text record. You can find all the details here.
Day 3-4: It's deployment time for a Safe! Go ahead and add the Zodiac Reality module, and make sure to set the Reality templateId, arbitrator, timeout, cooldown, and minimum bond. For all the details, check it out here.
Day 5-6: Get started on your proposal by using multisend payloads. Don’t forget to add the IPFS CIDs for your attachments. Once you’re all set, publish it on Snapshot. If you need more details, check it out here.
Day 7-11: It's time to vote! If you've got any decisions that need a little extra privacy, you might want to turn on Shutter shielded voting. You can read all about it here.
Day 12-14: After Reality gives you the thumbs up and the cooldown period wraps up, it’s time to go for your multisend! Don’t forget to save the Safe tx hashes, questionId, and snapshot CID in your proposals registry. If you need more details, check out ERC‑4824. You can find it on GitHub.

B. OpenZeppelin Governor in three sprints

Sprint 1: Alright, let’s get started by deploying ERC20Votes and setting up the Governor with the following components:
- GovernorVotes and GovernorVotesQuorumFraction
- GovernorTimelockControl
- GovernorPreventLateQuorum and GovernorProposalGuardian
- Be sure to document the voting delay/period and the quorum numerator.
- Oh, and don’t forget to run those unit tests to check the proposalId hashing, as well as the queue/execute with descriptionHash. You can find more info here.
Sprint 2: It's time to get everything connected with Tally! We need to check those function signatures and state mappings, and don't forget, we've got to put the castVoteBySig processes through their paces. (docs.tally.xyz)
Sprint 3: We’re almost there! Time to get things rolling by publishing the daoURI and contractsURI. We also have to verify our contracts on Sourcify and Etherscan, deploy the subgraph, and fire up the monitors to keep tabs on everything. (eips.ethereum.org)

C. MultiGov (pilot on hub + one spoke)

Week 1: Alright, let’s kick things off by ensuring that ERC20Votes is ready to handle CLOCK_MODE. After that, we’ll launch the HubGovernor with Flexible Voting and get a SpokeVoteAggregator going (think Base). For more details, you can take a look here.
Week 2: Let’s get to work on a little proposal to tweak some parameters. We’ll vote on it at the spoke, double-check the tally at the hub, and then put it into action. Additionally, we need to run some tests for replay protection and make sure our messages are coming through loud and clear. You can find more details here.
Week 3: Time to broaden our horizons by adding a second spoke! We'll set up some monitors to track how smoothly the cross-chain delivery is working. Plus, we’ll make sure that the hub and spoke states are in sync once everything's wrapped up. If you want all the details, take a look here.

Emerging best practices you should adopt now

Get the Most out of Flexible Voting
- It's now integrated with OpenZeppelin (GovernorCountingFractional), allowing delegates to split their votes and enabling L2/custody voting. Lots of big-name DAOs are already jumping in on this! Take a peek here: (github.com)
Consider implementing some anti‑frontrun measures while drafting your proposals
- Ensure that your Governor version is at least v4.9.1 and take advantage of the proposer-protection feature. If that’s not possible, you might want to use protected RPCs when making your proposals. You can find more details here: (miggo.io)
Standardize your metadata
- By using ERC-4824's daoURI/contractsURI, you'll make governance way easier to read and comprehend across various tools and blockchains. Check it out here: (eips.ethereum.org)
Get Your Off-Chain Processes Certified
- EAS schemas are an awesome way to connect your off-chain reviews, audits, and compliance checks to proposal artifacts in a reliable manner. Take a look at it here: (attest.org)
Remember to stash those CIDs in your descriptions!
- It's super important to add the IPFS CIDs for your proposal documents in the Governor description before you hash them. This little step helps with replayability and makes it easier for others to validate things. If you want to dive deeper into hashing behavior, check out the OZ docs: (docs.openzeppelin.com)
Consider shielded voting for sensitive topics
- Shutter and Snapshot are introducing a “permanent shielded voting” feature, which is definitely worth considering for things like elections, compensation, or any proposals that might spark some lively discussions. You can find more info here: (blog.shutter.network)
Get ready for multi‑chain governance, even if you’re focused on just one chain for the moment
- MultiGov has made some impressive strides! Design your token using ERC20Votes and a neat CLOCK_MODE, so you’re prepared to grow later on. Check it out here: (wormhole.com)

Security, risk, and “what can go wrong”

Late-quorum attacks
- If you're dealing with late-quorum problems, you can use GovernorPreventLateQuorum to ensure that voting continues even if quorum is reached right before the close. For more information, dive into the details here.
Mis-hashed Descriptions and Broken Cancellations
- Remember to hash the raw bytes of the description string! Skipping this step can lead to mismatches that screw up cross-domain cancel flows. Make sure to test your queue/execute/cancel round-trips in CI. You can find more info here.
Off-chain oracle mis-resolution (SafeSnap)
- Choose a reliable arbitrator, set up a strong bond/escalation path, and stay vigilant on any questions that pop up. If you come across anything sketchy, you can use module hooks to invalidate those malicious proposals. For more details, take a look at the guidelines here.
Cross-chain delivery risk
- Always stay updated on VAAs and ensure that you’re reconciling the hub/spoke state. It's smart to have a runbook prepared for any failed deliveries and re-broadcasts in MultiGov. For more details, check it out here.

What “good” looks like: metrics to track

Participation
- Take a look at the delegate participation rate and see how voters are distributed across various chains, particularly for MultiGov. (newsletter.tally.xyz)
Latency
- Check out the timing from when a draft is created all the way to when voting kicks off, then closes, moves into the queue, and eventually executes. Let's see how this compares to what we usually see with ENS and Uniswap. (docs.ens.domains)
Integrity
- Let’s shine a light on the percentage of proposals where we’ve actually verified execution--this means looking at events combined with Safe transaction hashes. It’d also be great to include the percentage of proposals that feature EAS attestations and IPFS CIDs in their descriptions. Check it out here: (old-docs.openzeppelin.com)
Operability
- We should definitely keep track of the mean time to acknowledge (MTTA) for Reality questions and cross-chain delivery alerts. Plus, it’s crucial to keep an eye on how we’re covering governance events. Check out more details here.

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

ENS Governance Parameters Snapshot
- Quorum is set at just 1%, which is about 1 million ENS tokens. When it comes to on-chain voting, it lasts for a full week, plus there’s a 2-day timelock. If you're looking to get a proposal executed, you'll need at least 100k ENS tokens. It’s a great model for anyone interested in blue-chip token governance. Take a look here: (basics.ensdao.org)
Uniswap Governance Thresholds
- If you want to start a proposal, you'll need to gather up 2.5 million UNI tokens. For a quorum, you’re looking at 40 million UNI. The voting period lasts for a week, and there’s a 2-day timelock, which is pretty standard Bravo stuff. For more info, check this out: (docs.uniswap.org)
Cosmos-Style Deposit and Veto Parameters (For Contrast)
- If you're diving into chains that use the Cosmos SDK x/gov, you'll find that the minimum deposit requirement is 250 ATOM. You’ve got a 14-day window to make your deposit and cast your vote. To get things moving, there’s a need for a 40% quorum, and keep in mind there’s a 33.4% veto threshold. This could definitely be useful if you're in the process of crafting your own appchain. For more details, check it out here: (hub.cosmos.network)

Monitoring blueprint (one hour to value)

Be sure to subscribe to:
- Governor events: Keep your eyes peeled for events like ProposalCreated, VoteCast, ProposalQueued, and ProposalExecuted. You can find all the deets here.
- Zodiac Reality: You won't want to miss out on ProposalQuestionCreated and when the outcome gets wrapped up. All the info is available here.
- Safe Transaction Service: Keep yourself in the loop with module and multisig executions for your Safe. More details can be found here.
Set up alerts to ping your Slack or Telegram with those important severity tags. Also, remember to stash the raw event JSON and transaction receipts in an S3 bucket, neatly organized by proposalId. You can get started with Defender Monitor or go for the open-source openzeppelin-monitor. Check out the guide here.

Final recommendations (decision‑maker’s cut)

Looking to hit the ground running without sacrificing quality? You should definitely check out Snapshot + SafeSnap. This combo offers a great hybrid solution that provides the auditability crucial for grants and treasury operations. Just remember to pair it with some strong monitoring and EAS attestations. For more info, click here.
Have important decisions to make for your protocol? Consider using OpenZeppelin Governor along with PreventLateQuorum, ProposalGuardian, TimelockControl, and Flexible Voting. And hey, don’t forget to integrate Tally and publish that ERC-4824 metadata! For more details, check out OpenZeppelin's docs.
Considering a multi-chain approach? A great place to kick things off is by testing out MultiGov on one of your spokes. Make sure to monitor latency and participation rates, and when you meet your delivery SLOs, you can begin to scale up. For more details, take a look here.

7Block Labs has designed and tested pipelines like these for a bunch of different L1s and L2s. If you need a full-on blueprint--think contracts, subgraphs, monitors, and runbooks--we can put that together in sprints that fit your risk profile perfectly.

Appendix -- Glossary and references you’ll actually use

ERC‑4824 daoURI/contractsURI is all about making it easier for people to discover DAOs and ensuring that tools can work hand-in-hand. You can check it out here.
EIP‑712 brings in typed signatures for off-chain voting, making it a great choice if you’re looking to integrate with Snapshot. Get all the details here.
If you're in need of a solid governance toolkit, look no further than the OpenZeppelin Governor modules catalog. It covers everything you might need, from votes and quorum to timelocks, late quorum prevention, and proposal guardians. Dive into the docs here.
Check out Flexible Voting from ScopeLift, which lets you split votes fractionally and supports custody/L2 voting. You can find the project on GitHub.
Have you heard about MultiGov from Tally and Wormhole? It’s a cool hub-and-spoke solution for cross-chain governance. Learn more about it here.
If you want to manage attestations with ease, take a look at EAS. It provides schemas and mainnet deployments to simplify the process. Get the scoop on GitHub.
Lastly, for Sourcify/Etherscan verification, don’t forget to switch to Etherscan API v2 before August 15, 2025. You can find the verification process here.

Description: Take a look at this super useful 2025 field guide designed for decision-makers who want to set up and launch a governance pipeline that’s easy to audit. We’ll dive into everything from Snapshot and OpenZeppelin Governor to Safe/Zodiac and MultiGov. We’ll also touch on crucial standards like ERC‑4824 and EIP‑712, explore attestations with EAS, indexing with The Graph, and check out some monitoring tools you can start using immediately.