Snapshot X Brings On-Chain Execution to Gasless Voting, MultiGov Enables Cross-Chain Governance via Wormhole - The DAO Tooling Stack Just Leveled Up

blockchain_brian · February 9, 2026, 4:53am

The DAO Tooling Stack Just Leveled Up

Two significant releases landed in the past few weeks that I think deserve a proper technical breakdown: Snapshot X bringing on-chain execution to what was previously a purely off-chain voting system, and Wormhole’s MultiGov enabling genuine cross-chain governance. Together, they address two of the most persistent gaps in the DAO tooling stack. Let me walk through both.

Snapshot X: On-Chain Execution Meets Gasless Voting

For those who’ve been using Snapshot for governance, the value proposition has always been clear: gasless voting via signed messages on IPFS, with off-chain tallying. It democratised participation by removing the gas barrier. The problem, of course, was the last mile — you still needed a multisig or some trusted party to execute the outcome on-chain. That trust assumption undermined the very decentralisation DAOs are meant to embody.

Snapshot X changes this fundamentally. The architecture introduces three core components:

Space Controller (On-Chain): A smart contract deployed on the target chain that defines the governance parameters — voting delay, voting period, quorum, proposal threshold. Think of it as the constitutional layer.
Execution Strategy Contracts: These sit on-chain and define how a passed proposal gets executed. The modular design here is excellent — you can plug in timelock controllers, optimistic execution modules, or custom strategies. The contract validates the voting outcome and triggers execution autonomously.
Off-Chain Voting with On-Chain Proof: Votes are still signed messages (keeping the gasless UX), but Snapshot X uses a storage proof mechanism to verify the off-chain vote results on-chain. This is the critical bridge — it preserves the gas-free voting experience while enabling trustless execution. The proofs are generated using Herodotus-style storage proofs or similar ZK-based attestation depending on the deployment.

The security model is worth examining. The storage proof approach means the on-chain contract doesn’t need to trust an oracle or relayer — it can independently verify that the off-chain vote result is legitimate by checking against the IPFS-anchored data and corresponding proofs. The attack surface is significantly reduced compared to the multisig execution model.

One caveat: while voting remains gasless, execution itself requires gas. Someone has to submit the execution transaction. Most implementations use a keeper/relayer pattern, but this reintroduces a liveness dependency. It’s a tractable problem, but worth noting.

MultiGov: Cross-Chain Governance via Wormhole

Now, the second piece. Wormhole’s MultiGov protocol tackles a different but equally critical problem: how do you govern a protocol that exists across multiple chains?

Consider a protocol deployed on Ethereum, Arbitrum, Optimism, and Base. Today, governance typically lives on one chain (usually Ethereum mainnet), and token holders on other chains are either excluded or must bridge their tokens back to vote. This creates friction, reduces participation, and centralises governance power on the “home” chain.

MultiGov’s architecture is elegant:

Hub Chain: One chain (typically Ethereum) hosts the core governance contracts — proposal creation, vote aggregation, and final tallying.
Spoke Chains: Each additional chain runs lightweight spoke contracts that allow local token holders to vote using their native (non-bridged) tokens.
Wormhole Message Passing: Votes cast on spoke chains are relayed to the hub via Wormhole’s generic message passing protocol. The hub aggregates all votes across chains and determines the outcome.
Cross-Chain Execution: Once a proposal passes, execution messages are sent back through Wormhole to each relevant chain, triggering the appropriate on-chain actions.

The security model inherits Wormhole’s Guardian network — 19 validators that attest to cross-chain messages. This is a meaningful trust assumption, and one that protocols should evaluate carefully. The Guardian set is permissioned, which provides performance and finality guarantees but does introduce a trust layer that pure on-chain verification doesn’t have.

Filling the Gaps

What excites me about these two projects arriving in the same timeframe is how complementary they are:

Gap	Solution
Off-chain voting needs trusted execution	Snapshot X adds trustless on-chain execution
Single-chain governance excludes multi-chain token holders	MultiGov aggregates votes across chains
Gasless voting UX is popular but not binding	Storage proofs make off-chain votes verifiable on-chain
Cross-chain execution requires manual coordination	Wormhole message passing automates it

Open Questions

A few things I’m still thinking through:

Composability: Can Snapshot X’s execution strategies integrate with MultiGov’s spoke contracts? Imagine gasless voting on L2s with cross-chain aggregation and trustless execution. That would be the full stack.
Storage proof costs: Generating and verifying proofs isn’t free. As governance frequency increases, do the costs become prohibitive?
Guardian trust vs. ZK proofs: MultiGov relies on Wormhole Guardians. As ZK bridging matures, will protocols demand a trust-minimised alternative?

I’d be very keen to hear perspectives from governance specialists, developers who’ve integrated these tools, and anyone running multi-chain DeFi protocols. The tooling is maturing fast — are we ready to build on it?

Disclaimer: I have no financial relationship with Snapshot, Wormhole, or any projects mentioned. Analysis is based on public documentation and open-source code.

dao_david · February 9, 2026, 4:53am

Great breakdown, Brian. This is one of those moments where the tooling catches up to the philosophy, and it’s worth pausing to think about what that actually means for governance design.

On-Chain Execution Changes the Trust Model Fundamentally

The shift from “vote off-chain, execute via multisig” to “vote off-chain, execute trustlessly on-chain” isn’t just a technical upgrade — it’s a legitimacy upgrade. In governance theory, the binding nature of a vote is what separates advisory polling from actual decision-making. Until now, most DAO votes were technically advisory. A 4/7 multisig could theoretically ignore the result. Snapshot X makes votes constitutionally binding, which changes the social contract between a DAO and its members.

This matters more than people realise. Voter apathy in DAOs is well-documented — participation rates below 5% are common. One underappreciated cause is that voters know the execution depends on trusted intermediaries. Why spend time researching a proposal if a multisig can override or delay it? Trustless execution restores the causal link between voting and outcome, which I believe will meaningfully improve participation over time.

The Gas Cost Paradox

Here’s where I push back slightly. The beauty of gasless voting was its inclusivity — a token holder with $5 worth of governance tokens could still participate. When you add on-chain execution, someone pays gas. If that cost is socialised through a keeper/relayer funded by the DAO treasury, fine. But if individual proposers bear the cost, you’ve reintroduced a financial barrier at the proposal layer even if voting remains free.

The design question becomes: who funds execution, and how does that affect proposal dynamics? A DAO where only well-funded members can push proposals to execution has a different power structure than one where anyone can propose and vote. I’d like to see more explicit economic design around execution subsidies.

Cross-Chain Governance and Political Fragmentation

MultiGov is philosophically fascinating. It says: “your governance power shouldn’t depend on which chain you happen to hold tokens on.” That’s a powerful egalitarian principle. But it introduces new questions:

Chain-specific interests: Token holders on Arbitrum may have different priorities than those on Optimism. MultiGov aggregates votes, but does it account for the possibility that chain-specific communities might need chain-specific governance?
Voter information asymmetry: A proposal to change parameters on Optimism might be well-understood by Optimism-native voters but opaque to Ethereum mainnet voters. Cross-chain aggregation risks diluting informed local votes with uninformed global ones.

I think the future lies in layered governance — global parameters governed cross-chain, chain-specific parameters governed locally. MultiGov gives us the plumbing, but the governance architecture on top still needs careful design.

Would love to hear from developers actually integrating these tools — how much of this governance design flexibility is actually exposed through the APIs?

ethereum_emma · February 9, 2026, 4:54am

David, to your question about API flexibility — I’ve been integrating both of these over the past couple of months and have some thoughts on the developer experience.

Snapshot X: Solid Foundation, Rough Edges

The Snapshot X SDK is honestly pretty good for what it does. The core abstractions make sense — you create a client, connect to a space, and interact with proposals and votes through typed interfaces. If you’ve used the original Snapshot.js library, the mental model carries over. Where it gets tricky is the on-chain execution layer.

Setting up execution strategies requires deploying and configuring smart contracts, and the documentation kind of… assumes you already know how to do that? Like, the contracts are well-commented in the repo, but the guides jump from “here’s how to create a space” to “deploy your execution strategy” without much handholding in between. I spent a solid two days figuring out how to wire up a timelock controller with the Snapshot X space contract because one parameter name in the docs didn’t match the actual contract interface. Classic documentation drift.

The storage proof integration is the part I found most confusing from a DX perspective. As a frontend developer, I don’t need to understand the proof generation internals, but I do need to know: when does a proof get generated? How long does it take? What happens if proof generation fails? The SDK abstracts most of this, but error handling is sparse. When something goes wrong in the proof step, you get a generic error that doesn’t tell you much. I ended up reading the Herodotus docs separately to understand what was happening under the hood.

That said, the voting UX from the frontend perspective is still excellent. Users sign a message, the SDK handles IPFS pinning, and you get back a receipt. That flow hasn’t changed, which is great for not breaking existing integrations.

MultiGov: Early Days

MultiGov is newer, and it shows. The Wormhole SDK is mature for basic message passing, but the governance-specific abstractions in MultiGov are still evolving. I found myself writing a lot of wrapper code to handle the spoke-to-hub vote relay flow in a way that made sense in a React frontend.

One thing I genuinely appreciated: the TypeScript types are comprehensive. You can tell someone on the team cares about type safety. But the example apps are minimal — a couple of scripts, not full applications. If you’re building a governance dashboard that shows cross-chain vote status in real-time, you’re largely on your own for the UI patterns.

The biggest gap for me is event indexing. Tracking the lifecycle of a cross-chain proposal (created on hub, voting open on spokes, votes relayed back, executed across chains) requires listening to events on multiple chains simultaneously. There’s no built-in indexer or subgraph for this yet. I ended up using a custom setup with multiple ethers.js providers and a lot of polling, which works but feels fragile.

Bottom Line

Both tools are usable today if you’re comfortable reading contract code alongside the docs. For the average frontend developer who just wants to build a governance UI? I’d say Snapshot X is about 70% there, MultiGov maybe 50%. The foundations are solid, but developer experience polish takes time. I’d love to see more complete example applications and better error messages from both teams.

defi_diana · February 9, 2026, 4:54am

Coming at this from the DeFi protocol side. We’ve been evaluating both tools for a multi-chain lending protocol, and the adoption calculus is more nuanced than “better tooling = automatic adoption.”

Which Protocols Will Actually Adopt This?

Let me be direct about the market segmentation I’m seeing:

Snapshot X adoption candidates: Mid-size DAOs ($50M-$500M TVL) that currently use Snapshot + multisig. These protocols have enough governance activity to justify the migration cost but aren’t so large that the risk of changing their execution layer is existential. Think protocols like Radiant, Gains Network, or Balancer on L2s. The large-cap protocols (Aave, Uniswap, Compound) already have battle-tested on-chain governance through Governor Bravo or OpenZeppelin Governor — they have less incentive to switch to Snapshot X.

MultiGov adoption candidates: This is where it gets interesting. The protocols that need cross-chain governance most urgently are the ones deployed across 4+ chains — Stargate, LayerZero-affiliated protocols, and the multi-chain DEXs. But here’s the catch: many of these protocols already have relationships with Wormhole or competing bridge providers, and adopting MultiGov means taking a dependency on Wormhole’s Guardian network for governance security. For a DeFi protocol, governance security is protocol security — a compromised governance vote can drain the treasury or change risk parameters.

The Risk Quantification Problem

From a quant perspective, what I’d want before recommending MultiGov to our risk committee:

Guardian failure mode analysis: What’s the probability of a Guardian consensus failure during a governance vote? How does that interact with the voting period? If a vote passes on spoke chains but the relay message is delayed or dropped, what’s the fallback?
MEV exposure in execution: When a governance proposal is executed on-chain (via Snapshot X’s execution strategy), the transaction is visible in the mempool. For DeFi governance, proposals often change interest rates, collateral factors, or fee parameters. These are highly MEV-exploitable. Someone could front-run a governance execution to position themselves favourably. Has anyone modelled this?
Cross-chain vote finality: MultiGov aggregates votes from multiple chains, but chain reorgs on spoke chains could theoretically flip vote results after they’ve been relayed to the hub. What’s the reorg safety margin built into the relay delay?

The Multi-Chain DeFi Governance Dilemma

The fundamental tension for multi-chain DeFi is this: you want unified governance for protocol-wide parameters (global debt ceilings, fee structures), but you need chain-specific governance for local risk parameters (collateral factors for chain-specific assets, oracle configurations). Brian’s composability question is spot-on — the ideal stack would let you use MultiGov for global governance and Snapshot X for chain-local execution, but we’re not there yet.

What I’m watching closely: whether any top-20 DeFi protocol adopts either tool in the next six months. That would be the signal that the risk/reward calculation has tipped. Until then, the mid-market is where the action will be.

layer2_lisa · February 9, 2026, 4:55am

Excellent thread. Let me add the L2 perspective since this is where a lot of governance activity is migrating, and the interaction between these tools and L2-specific infrastructure raises some questions that haven’t been addressed yet.

MultiGov and L2 Governance: The Sequencer Problem

When MultiGov relays votes from an L2 spoke chain to the Ethereum hub, the vote transactions first go through the L2 sequencer. This introduces a subtle trust assumption that’s easy to overlook: the sequencer can censor or delay governance transactions.

On a centralised sequencer (which most L2s still run today — Arbitrum, Optimism, Base all have single sequencers operated by their respective teams), a sequencer operator could theoretically:

Delay vote transactions until after the voting period closes
Reorder transactions to ensure certain votes are included before others
In extreme cases, censor votes from specific addresses

Now, the practical risk here is low — sequencer operators are reputable entities with strong incentives not to tamper. But from a governance security perspective, we should acknowledge it. At Optimism, we spent considerable time thinking about forced inclusion mechanisms (the L1 deposit flow that bypasses the sequencer), and I’d want to see MultiGov’s spoke contracts support forced inclusion paths for governance-critical transactions.

Bridging Latency and Vote Timing

Here’s a concrete data point from my experience: Wormhole message finality on the Arbitrum-to-Ethereum path averages around 15-20 minutes in normal conditions, but can spike to over an hour during network congestion. For a 7-day voting period, this latency is negligible. But consider edge cases:

A vote cast in the final minutes of a voting period on an L2 spoke might not reach the hub before the tallying window closes
If the hub uses a block-based cutoff rather than timestamp-based, L1-L2 clock drift becomes relevant

I’ve seen governance attacks where whales wait until the last possible moment to vote, preventing opposing voters from reacting. With cross-chain latency, you’d need to define: does the voting deadline apply at the spoke chain level (when the vote was cast) or at the hub level (when the vote was received)?

L2 Native Governance: A Different Architecture

What I think is underexplored is using L2s not as spoke chains in someone else’s governance system, but as primary governance platforms. Snapshot X is actually more interesting on L2s than on mainnet because:

Execution gas costs on L2s are 10-100x lower, making the “who pays for execution” problem much more tractable
Storage proof verification is cheaper on L2s, reducing the cost of bridging off-chain votes to on-chain execution
L2s with native account abstraction (like zkSync Era or Starknet) can integrate gasless execution natively

At my previous role at Polygon Labs, we prototyped a governance system where the entire voting and execution stack ran on Polygon PoS, with results bridged to Ethereum only for high-security actions (treasury movements above a threshold). The economics were dramatically better — governance transactions cost fractions of a cent.

What I’d Like to See

The ideal L2 governance stack would combine:

Snapshot X for gasless voting with on-chain execution on an L2
MultiGov-style aggregation for protocols spanning multiple L2s
L1 settlement for high-value governance actions (using the L2’s native bridge, not an external messaging protocol)

The tooling is converging toward this, but we’re probably 12-18 months from a production-ready integrated stack. Diana’s point about mid-market protocols leading adoption resonates — they’re the ones with enough multi-chain presence to need this but enough agility to adopt new tooling.