Building a DAO from Scratch: Governance, Tokens, and Tooling

A practical, up-to-date blueprint for launching a production-grade DAO in 2025: concrete governance architectures, token mechanics you can ship, and a vetted tooling stack (onchain, offchain, or hybrid) with security and legal guardrails.

Who this is for

Decision-makers at startups and enterprises evaluating whether a DAO structure makes sense for a product, protocol, network, or ecosystem program—and who need specifics you can take to your engineering, legal, and finance leads tomorrow.

The 3 decisions you must lock first

What are you governing?

Protocol parameters and upgrades (e.g., rollup config, emissions, fee splits)
Treasury and grants (budgets, program ops)
Brand and ecosystem (trademarks, partnerships)
Multi-chain deployments (hub and spokes)

Who gets power?

Token-holders (economic stake)
Contributors with reputation/roles (operational stake)
Bicameral models mixing both (e.g., Optimism’s Token House + Citizens’ House). (community.optimism.io)

How “onchain” is the process?

Offchain voting + onchain execution (Snapshot + Safe module)
Fully onchain (Governor on an L2/mainnet)
Hybrid (e.g., cross-chain voting aggregated to a hub chain, onchain execution)

Legal wrapper: what’s working in the U.S. (and offshore) in 2025

Wyoming’s DUNA (Decentralized Unincorporated Nonprofit Association) gives DAOs legal personhood, limited liability, ability to own property, contract, and govern via smart contracts. Requirements include ≥100 members and explicit election into the act. For governance, the statute explicitly permits using distributed ledger tech in whole or in part. Good fit for “protocol stewards” that require nonprofit posture with power to pay compensation. (law.justia.com)
Wyoming’s earlier DAO LLC remains viable if you want for‑profit clarity or fewer than 100 members. Combine with DUNA for ecosystem bifurcation: DAO LLC for product/ops entities; DUNA for protocol stewardship and neutrality. (law.justia.com)
Marshall Islands DAO LLC remains a common offshore alternative for token-based DAOs seeking an internationally recognized LLC wrapper acknowledging onchain voting and tokenization. (theblock.co)

Practical tip:

If your governance must sign vendor contracts or hire staff, give the DAO a wrapper (DUNA/DAO LLC) and keep the Governor or Safe as the onchain executive. Your wrapper can designate the Governor/Safe as “authorized signatory” in board minutes or operating agreements.

Governance architecture: patterns that scale in 2025

Bicameral or multi-stakeholder governance

Token-weighted house (treasury, protocol knobs) + personhood/reputation house (strategic intents, vetos) reduces capture and aligns diverse stakeholders. Optimism’s model is the leading production reference; it added more stakeholder granularity in 2025 (Season 8). (community.optimism.io)

Security Council as circuit breaker

For L2s and critical infra, adopt a 9-of-12 (or similar) Security Council with emergency upgrade powers, explicit reporting, and delayed non-emergency actions. Document thresholds, delays, and transparency requirements in your constitution. This is how Arbitrum protects users while keeping tokenholders in charge. (docs.arbitrum.foundation)

Onchain vs. offchain voting

Offchain (Snapshot) + execution module: Lowest friction; pair with a Safe module to execute passing votes trust-minimized. The Zodiac Reality Module confirms Snapshot outcomes via Reality.eth; widely used and framework-agnostic. (zodiac.wiki)
Note: UMA’s oSnap (an optimistic Snapshot execution path) is being deprecated with support ending December 15, 2025—plan migrations accordingly. If you’re using oSnap, follow Snapshot’s migration guide and consider Reality.eth or transitioning to onchain voting. (docs.snapshot.box)
Fully onchain: Use OpenZeppelin Governor v5.x, now with flexible counting and EIP‑6372 “Clock” support. Cheaper and safer on an L2; retains onchain auditability and composability. (openzeppelin.com)
Snapshot X: If you need onchain, gasless voting with cross-chain balance proofs and Snapshot’s UX, Snapshot X runs on Starknet and verifies L1/L2 holdings via storage proofs; 10–50× cheaper than L1 voting and supports gas sponsorship. Great middle ground when you want verifiable onchain votes without L1 costs. (starknet.io)

Multichain from day one

If your protocol spans chains, avoid fragmented governance by using Tally MultiGov (hub-and-spoke model). Votes happen on spoke chains and aggregate back to a hub Governor (OZ Governor + Flexible Voting). Used by Wormhole DAO; supports EVM and Solana. (docs.tally.xyz)

Private and fair voting

Enable Snapshot’s Shielded Voting (Shutter) to prevent herd behavior and last-minute whale swings by encrypting votes during the voting window. A “permanent shielded voting” upgrade (homomorphic tally with ZK proofs) is on the roadmap and has a public PoC as of October 2025. (shutter.network)

Token engineering that resists attacks and invites participation

Your safest default in 2025:

ERC20Votes + OpenZeppelin Governor v5.1+ (Fractional/Flexible counting now in OZ) + Timelock
Delegation enabled at mint; default self-delegations via UI nudges
Quorum as a fraction of total supply with guardrails to prevent sudden drops
Delay and voting period tuned for your chain’s block time and community cadence

What to implement:

ERC20Votes (checkpointed voting power) plus EIP‑6372 Clock alignment ensures votes are based on past balances—critical to deter flash-loan vote attacks. Use GovernorVotes + GovernorVotesQuorumFraction; align token and Governor clocks. (docs.openzeppelin.com)
Fractional/Flexible Voting lets delegates split votes (e.g., 60/40 For/Against) and enables pooled or bridged voting without losing nuance. Incorporated into OZ v5.1 and maintained by ScopeLift. (openzeppelin.com)
Parameter ranges that work (start point, adjust empirically):
- Voting delay: 1–2 days on L2 (gives time to delegate or rally voters)
- Voting period: 5–7 days for protocol changes; 3–5 days for grants
- Quorum: 2–5% of total supply (or votable supply), with a dynamic ratchet based on rolling participation medians
- Proposal threshold: 0.05–0.25% of supply or reputation-weight equivalents
Shielded voting for offchain proposals (Snapshot), permanent privacy when available; for onchain, explore flexible voting with private tally add‑ons as they mature. (shutter.network)

Sybil resistance for token‑light or personhood‑heavy systems:

Use Gitcoin Passport stamp thresholds or model-based scores to gate proposal creation or amplify voting weight in quadratic/community votes. Publish which stamps and score you accept (e.g., “score ≥20” is a common threshold in funding programs). (support.passport.xyz)

Roles, accountability, and execution authority (beyond tokens)

Onchain roles via Hats Protocol: Assign granular, revocable authorities (ERC‑1155 non-transferable “hats”) to teams, contributors, or AI agents. Tie permissions to Safe signing, Snapshot/Tally rights, term limits, or eligibility rules; automate compensation streams to the role (not the person) via Sablier/Superfluid. Production usage includes SafeDAO and ecosystem DAOs like Purple. (forum.safe.global)
Treasury execution via Safe + Zodiac
- Reality Module: Resolve offchain votes to onchain, set minimum bonds and cooldowns, and make proposal execution permissionless while keeping a veto path. Works with any governance frontend. (zodiac.wiki)
Moloch v3 (Baal) for membership DAOs and sub‑DAOs: Built around shares/loot, ragequit guarantees, and Safe treasuries via Zodiac. Lets you compose simple contributor DAOs under a protocol DAO without sacrificing ragequit protections. (docs.daohaus.club)

Tooling that’s shipping well in 2025

Smart contracts: OpenZeppelin Contracts 5.2 adds cross‑chain and account‑abstraction utilities (ERC‑4337, ERC‑7579 modules) for building advanced governors and smart accounts. Use this baseline for long‑lived deployments. (openzeppelin.com)
Governance frontends:
- Tally (Governor-native, MultiGov cross‑chain support) for onchain votes. (docs.tally.xyz)
- Snapshot v2 for offchain; Snapshot X for gasless onchain voting with storage proofs. (starknet.io)
- Agora for delegate discovery and participation improvements (e.g., ENS delegate UX upgrades in 2025). (agora.ensdao.org)
- Karma for delegate reputation dashboards and contributor analytics to increase votable supply and accountability. (karmahq.xyz)
Simulation and ops:
- Safe/Tenderly simulations: simulate execTransaction payloads against your Safe before proposals go live. Bake this into your proposal template. (blog.tenderly.co)
- OpenZeppelin Defender is sunsetting (no new sign‑ups since June 30, 2025; shutdown July 1, 2026). Migrate to OZ’s open‑source Relayer/Monitor and equivalent CI/CD ops well before that date. (openzeppelin.com)

Treasury management reference

ENS Endowment is a practical blueprint: non‑custodial, onchain strategy management using Safe + Zodiac Roles, with external manager (karpatkey) and public reporting. Use it as a template if you’ll run an endowment. (basics.ensdao.org)

Chain selection in 2025: a crisp rule of thumb

Launch governance on an L2 where your users are (Optimism/Base/Arbitrum/Polygon zkEVM), keep execution costs low, and bridge only when necessary. If multi‑chain, use a hub Governor and spokes (Tally MultiGov). Keep treasury and Governor on the same chain to prevent cross‑domain execution risk unless you must span chains. (docs.tally.xyz)
If your security model requires an emergency backstop, copy established Security Council patterns (9‑of‑12, emergency vs non‑emergency flows, explicit reporting). (docs.arbitrum.foundation)

A 30‑day launch plan (with concrete defaults)

Day 1–5: Incorporate and scaffold

Pick wrapper: Wyoming DUNA (≥100 members, nonprofit steward) or DAO LLC (profit‑seeking); draft a governance charter mapping onchain powers to the wrapper’s officers. (law.justia.com)
Deploy Safe on your target L2; start with a 4/7 multisig as a temporary guardian.

Day 6–12: Ship the token and Governor

Deploy ERC20Votes with checkpoints and permit; pre-program delegation (self‑delegate on first claim).
Deploy OpenZeppelin Governor v5.1+:
- Modules: GovernorSettings, GovernorVotes, GovernorVotesQuorumFraction, GovernorTimelockControl, GovernorCountingFractional (flexible voting).
- Defaults (tune later): votingDelay=1 day, votingPeriod=5 days, proposalThreshold=0.1% supply, quorum=3% of supply. (old-docs.openzeppelin.com)
Stand up Tally for proposal flow; enable Flexible Voting for pooled or bridged token use. (github.com)

Day 13–18: Configure voting UX and execute path

Offchain track: Create Snapshot space; enable Shielded Voting; wire Zodiac Reality Module to your Safe for executing passing votes (set minimum bond= e.g., 1–5 ETH-equivalent, cooldown=24–48h). (shutter.network)
Onchain track: If you want gasless but onchain votes, set up Snapshot X on Starknet for storage‑proof powered voting; sponsor gas via relayer if needed. (starknet.io)

Day 19–24: Roles, delegates, and security

Launch a delegate program; integrate Agora/Karma dashboards; front‑load delegation prompts in your app. (agora.ensdao.org)
Define Hats roles for Security Council, Grants Council, and Ops Admin; wire role tokens to Safe signing or proposal‑creation rights; encode term limits and eligibility (e.g., Passport score, staking, elections). (forum.safe.global)
Draft Security Council charter: 9/12 emergency, onchain timelock for non‑emergency upgrades, immediate public transparency report for emergency actions. (docs.arbitrum.foundation)

Day 25–30: Dry runs and public launch

Simulate every initial proposal (parameter updates, module installs, first grants) in Tenderly against your Safe. Document exact calldata and expected state diffs in the forum thread. (blog.tenderly.co)
If using Defender today, open a migration task to OZ’s open‑source tools; set a deprecation reminder for Q1 2026. (openzeppelin.com)

Configuration details most teams miss (and later regret)

EIP‑6372 clock alignment: Ensure token and Governor clocks match (block vs timestamp); misalignment can produce unintuitive voting windows or “impossible” quorum snapshots. Test this explicitly in staging. (docs.openzeppelin.com)
Proposal templates: Provide a canonical JSON/ABI template for common actions (e.g., “transfer from Safe”, “upgrade proxy”, “grant role”). Enforce templates via CI to minimize malformed proposals.
Shielded voting defaults: If your DAO uses Snapshot, set Shielded Voting as default to reduce bias; publish a process for “public votes only” when audits or legal require open ballots. Watch for Snapshot’s permanent shielded voting availability and plan an activation vote. (blog.shutter.network)
Offchain execution modules: With oSnap deprecating, migrate to Reality Module or move to onchain voting for decisions that move funds. Update runbooks and moderator training accordingly. (docs.snapshot.box)
Cross‑chain votes: If adopting MultiGov, document hub/spoke bridges, failure modes, and fallback (e.g., grace periods if a spoke fails to relay). Keep parameter changes small until you’ve observed at least 3 successful cross‑chain proposals. (docs.tally.xyz)

Case-study snippets you can copy

ENS Endowment
- Structure: DAO treasury → Endowment Safe with Zodiac Roles → non-custodial DeFi strategies → monthly public reporting (Steakhouse) and forum oversight. This setup generated multi‑million net revenue in 2024 with a 3.7% net APY while preserving DAO control. (discuss.ens.domains)
Optimism governance
- Separation of stakeholder powers (token vs citizenship) with explicit vetoes and budget approvals; iterate seasons with scoped changes (e.g., new stakeholder groups in 2025) rather than wholesale rewrites. (community.optimism.io)
Arbitrum Security Council
- Emergency and non‑emergency flows, 9‑of‑12 threshold, and constitutional clarity around elections, delays, and transparency reporting. Adopt this pattern if your protocol holds user funds. (docs.arbitrum.foundation)

Emerging practices to watch through 2026

Permanent shielded voting with homomorphic tally on Snapshot: privacy before, during, and after votes without sacrificing public verifiability. PoC live; track rollout to mainnet. (blog.shutter.network)
Multichain voting as a norm: Hub‑and‑spoke governance (Tally MultiGov) with Flexible Voting, and Snapshot X storage proofs for gasless onchain voting. (docs.tally.xyz)
Account‑abstraction native DAOs: OZ 5.2’s AA utilities and ERC‑7579 modules enable programmable signers and policy‑based execution (e.g., role‑gated actions by Hats + AA modules). (openzeppelin.com)

Security checklist (don’t skip)

Use a Timelock for all non‑emergency executions; set at least 48–96 hours on L2, longer if user funds are at risk. (old-docs.openzeppelin.com)
Maintain an Emergency Council (signers with well‑opsec’d HSMs/passkeys) with documented scope and transparency duties; rotate keys per policy. (docs.arbitrum.foundation)
Simulate every proposal in Tenderly (or local anvil/Foundry fork) and publish diffs. (blog.tenderly.co)
Require proposal descriptions to include calldata, target addresses, and human‑readable intents; ban “opaque multisend blobs.”
Add “canary votes” with 0‑value actions in staging to test Reality or Snapshot X setups before live funds move. (zodiac.wiki)

The 7Block Labs recommended stack (Dec 2025)

Wrapper: Wyoming DUNA (protocol steward) + affiliated DAO LLC (ops) where applicable. (law.justia.com)
Chain: Optimism/Base/Arbitrum L2 (governor + treasury on same chain); MultiGov only when needed. (docs.tally.xyz)
Contracts: OpenZeppelin Contracts v5.1+ Governor with Flexible/Fractional voting; ERC20Votes token; Timelock; Hats for roles. (openzeppelin.com)
Voting UX: Snapshot with Shielded Voting by default; Snapshot X when onchain verifiability + gasless UX is required; Tally for onchain Governor flows. (shutter.network)
Execution: Safe + Zodiac Reality Module; avoid oSnap (deprecated) and migrate if in use. (zodiac.wiki)
Analytics & reputation: Agora + Karma dashboards; Gitcoin Passport gating for sybil‑resistant community decisions. (agora.ensdao.org)
Ops: Tenderly simulations; plan Defender migration to OZ open‑source tools by H1 2026. (blog.tenderly.co)

Final word

In 2025, “DAO from scratch” no longer means inventing governance. It means selecting proven components—legal, onchain, and operational—calibrated to your risk profile and user base. Start simple with a Governor on an L2, Shielded Voting on Snapshot, Safe + Reality for execution, and Hats for roles. Add MultiGov, Snapshot X, and advanced AA modules as complexity grows. The stack above is what we actively ship and maintain—and it will carry you from first vote to your first hundred proposals with confidence.