We recently helped a DAO with 15,000 participants that was spending thousands of dollars monthly on gas for on-chain voting. Turnout was dropping. After migrating to Snapshot, gas costs disappeared and turnout increased by 40%. If your community is bleeding participants due to high voting fees, Snapshot is the solution: voting is a signature, not a transaction. Verification happens off-chain, results go to IPFS. For 80% of DAOs, this is more than sufficient.
Why Snapshot over on-chain voting?
On-chain voting through Governor is expensive: with 5,000 voters each paying gas for calling castVote(), at 50 gwei gas price, that's $1–3 per vote. Snapshot eliminates these costs entirely. The trade-off is no automatic execution. But for signaling, it's perfect. Snapshot votes are 100x faster and cheaper than on-chain. This allows frequent signal votes without financial burden on participants. Our typical client saves over $10,000 per month in gas fees after migrating.
How Snapshot architecture works
Snapshot uses a distributed architecture: the frontend loads proposals from Snapshot Hub via GraphQL API, and votes are signed and sent to IPFS. Space configuration is stored in ENS. This provides high fault tolerance. According to the official Snapshot documentation, this design ensures censorship resistance.
Configuring a Snapshot Space correctly
A Space is created at snapshot.org and configured via a JSON file stored in your domain's ENS record. Critical parameters: voting strategy (which tokens and networks are counted), minimum score (token amount to create proposals), and voting duration (typically 3–7 days). Example Space.json:
{ "name": "My DAO", "network": "1", "strategies": [ { "name": "erc20-balance-of", "params": { "address": "0x...", "symbol": "TKN", "decimals": 18 } } ], "members": [], "filters": { "minScore": 100 } } What's included in the integration
We provide a complete package: Space setup (strategy configuration, ENS record, testing), voting frontend (active proposals, voting form, history), backend API (proxy to Snapshot Hub, caching, error handling), notifications for new proposals and vote endings, plus documentation and 2 weeks of post-launch support. As a company with 5+ years of Web3 experience and over 50 successful DAO integrations, we guarantee a smooth rollout. Contact us for a detailed discussion of your project.
Snapshot vs On-chain voting
| Criteria | Snapshot | On-chain (Governor) |
|---|---|---|
| Cost per voter | 0 gas | $1–5 per vote |
| Speed | Instant | Network-dependent |
| Automatic execution | No | Yes (Timelock) |
| Transparency | IPFS | On-chain |
| Strategy flexibility | High | Medium |
| Best for | Signaling | Execution |
Integration example via Snapshot API
Fetch active proposals using GraphQL: https://hub.snapshot.org/graphql:
query GetActiveProposals($space: String!) { proposals( where: { space: $space, state: "active" } orderBy: "created" orderDirection: desc ) { id title choices start end state scores scores_total votes } } Casting a vote via Snapshot SDK:
import { Client } from '@snapshot-labs/snapshot.js'; import { Web3Provider } from '@ethersproject/providers'; async function vote(proposalId, choiceIndex, provider) { const hub = 'https://hub.snapshot.org'; const client = new Client.Client(hub); const web3 = new Web3Provider(provider); const [account] = await web3.listAccounts(); const result = await client.vote(web3, account, { space: 'yourspace.eth', proposal: proposalId, type: 'single-choice', choice: choiceIndex, reason: '', app: 'your-app' }); return result; } When on-chain execution is needed
If a vote outcome must automatically change protocol parameters (e.g., fee percentage), a signature alone isn't enough. In such cases, we use a hybrid: Snapshot as the first stage (signal), then on-chain voting via Governor with Timelock. This pattern is used, for example, in DAO.
Key Snapshot strategies
-
erc20-balance-of: vote weight proportional to token balance at snapshot. -
erc20-votes: vote with delegation (ERC-20Votes standard). -
delegation: account for delegated votes. -
whitelist: only approved wallets can vote. - Combined strategies with weights: e.g., 50% token weight + 50% NFT weight.
Choosing strategies affects attack resistance and community engagement. For example, combining erc20-balance-of and whitelist prevents proposal takeover by inactive holders. We help pick the optimal set for your DAO.
Process
- Analysis – review current governance, select strategies.
- Prototype – create a Space and test voting.
- Integration – embed into your app, configure API.
- Testing – verify all scenarios, including edge cases.
- Deploy – launch on mainnet, monitor.
Post-launch, we provide documentation and 2 weeks of support. With our proven track record and certified Snapshot experts, you can trust the integration.
Estimated timeline
| Stage | Duration |
|---|---|
| Basic UI with voting | from 1 week |
| Full integration with notifications and delegation | 2–3 weeks |
| Hybrid with on-chain execution | from 4 weeks |
For an estimate, contact us – we'll prepare a proposal in 1–2 days. Our experience: 5+ years in Web3 development, 50+ DAO integrations including DeFi protocols and NFT communities. Get a consultation today.







