How to create a DAO: contracts, voting, treasury and legal wrapper

To create a DAO you make three decisions. First, where votes happen: offchain on Snapshot, or onchain through a Governor contract. Second, who can move the money: a multisig, a timelock controlled by the vote, or both. Third, what legal entity, if any, stands behind it. Most new projects should start with a Safe multisig plus Snapshot and move to onchain governance once the treasury or protocol powers are large enough to justify the cost and attack surface.

The rest of this post is the order we would do it in, with the parameters and failure cases that matter.

Do you actually need a DAO?

A DAO is a decision process with a shared treasury. It is worth building when:

• A community or set of token holders should control money or protocol parameters, and you want that control to be credible.
• You plan to hand off control of a protocol and need a mechanism that outlives the founding team.
• Grants, investment clubs or collectives need transparent collective spending.

It is a poor fit when one team still makes every product decision. A token vote on decisions the team will make anyway trains holders to ignore governance, and it creates legal exposure for little benefit. If you are designing the token alongside the DAO, read our token economics guide first, since voting power usually comes from the token.

Step 1: decide what governance controls

Write a scope document before any contract. List every power that exists in your system and who holds it today:

• Treasury spending, by size.
• Protocol parameters (fees, collateral factors, rate curves).
• Contract upgrades and proxy admin.
• Emergency pause.
• Grants and contributor payments.
• Membership (for NFT or reputation DAOs).

Then decide, for each one, whether it goes to token holders, to an elected council, to a multisig with a narrow mandate, or stays with the team for now. A DAO that votes on everything stalls. A DAO that votes on nothing is a marketing claim.

Step 2: choose a voting model

Where votes happen

Snapshot's weakness is that the vote is a suggestion. If the multisig signers ignore it, nothing happens. oSnap closes most of that gap. An onchain Governor closes it fully and adds gas cost and a larger attack surface.

What gives voting power

• Fungible token. Standard for protocols. Use a token with checkpoints, such as OpenZeppelin's ERC20Votes, so voting power is read at a past block.
• NFT membership. One member, one vote, for collectives and clubs.
• Reputation or non-transferable credentials. Harder to buy influence, harder to build.

Plan for delegation from day one. Most holders will never vote. Delegation lets them hand their votes to someone who will.

Step 3: configure the onchain Governor

If you go onchain, OpenZeppelin Governor is the default on EVM chains, and tools like Tally read it out of the box. The modules you will use:

• GovernorVotes reads voting weight from an ERC20Votes token.
• GovernorVotesQuorumFraction sets quorum as a percentage of total supply.
• GovernorSettings makes voting delay, voting period and proposal threshold changeable by governance.
• GovernorTimelockControl routes execution through a TimelockController. The docs point out that the timelock executes proposals, so the timelock must hold the governed assets, not the Governor.

Parameters and what they protect against

These starting points are our defaults, not rules. The values are counted in the contract's clock, which by default is blocks, so convert using your chain's block time. A common community example uses 7,200 blocks of delay and 50,400 blocks of voting period, roughly one day and one week at Ethereum's 12-second blocks, with 4% quorum.

Two attacks to design against

Flash-loaned votes. In April 2022, Beanstalk lost about $182M when an attacker flash-borrowed enough tokens to reach a supermajority and passed a malicious proposal through an emergencyCommit function with no execution delay. The standard fix is to read voting power at a block before the proposal (checkpointed tokens), and put a timelock between passing and execution so anyone can react.

Low-turnout capture. In July 2024, Compound's Proposal 289 to move 499,000 COMP (about $24M) into a vault controlled by one group passed 682,191 votes to 633,636 over objections from much of the community. Nothing was hacked. The rules allowed a determined minority to win because most supply did not vote. Defences include a quorum set against real turnout, a veto or guardian role during the timelock window with a narrow mandate, and limits on how much treasury a single proposal can move.

If any of your governed contracts are upgradeable, read our proxy patterns guide. Upgrade rights held by governance are the highest-value target in the system.

Step 4: set up the treasury

Practical setup for most DAOs:

• Main treasury in a Safe, owned by the timelock once governance is onchain, or by a multisig before that.
• Operating multisig with a budget approved by governance each quarter, so day-to-day payments do not need a vote.
• Signers spread across people, organisations and time zones, with hardware wallets. A threshold like 3 of 5 or 4 of 7 is common; write down what happens if a signer disappears.
• Spending limits per proposal and per period, enforced in contracts where possible.
• Diversification. A treasury held entirely in the DAO's own token loses value exactly when the DAO needs money.

Step 5: pick a legal wrapper

Skipping this is a decision too, and it has been expensive for others. In the Ooki DAO case, a US court treated the DAO as an unincorporated association that could be sued and fined, and imposed a $643,542 penalty. In November 2024, a California federal court ruled that Lido DAO could be treated as a general partnership, allowing claims against identifiable participants, including large investors, to proceed. In a general partnership, members can be personally liable.

The main options people use today:

This table is a starting map, not advice. Talk to a lawyer who has formed these before, and pick the wrapper before the token launches, because restructuring later means moving the treasury and possibly changing token rights.

Step 6: plan for low participation

Low turnout is the normal state of token governance. A 2025 paper on delegation summarises several studies finding concentrated control and very low participation across samples of 21 and 50 DAOs, and in Uniswap and Compound. Design for it:

• Measure turnout on Snapshot signalling votes before you set an onchain quorum. Quorum above real turnout means nothing passes. Quorum far below it invites capture.
• Run a delegate program. Publish delegate statements, track voting records, and consider paying active delegates.
• Use a forum and a temperature check before formal proposals. Most quality problems get fixed in discussion, not in the vote.
• Go optimistic for routine spending. Pre-approved budgets with a veto window beat a full vote for every invoice.
• Fewer, bigger votes. Batch parameter changes so holders see one meaningful proposal a month, not five trivial ones a week.
• Make the UI readable. Show what the proposal executes in plain language next to the calldata.

That last point is where we have spent a lot of our own time. For the Aleph Zero governance platform we built proposal creation, voting and result verification in one interface, with voting statistics, power metrics and a built-in forum for refining proposals before submission. Syncra, a privacy-first DAO management platform on Substrate networks, added confidential voting, automated treasury management and no-code DAO setup. Both taught us that the contracts are the easy half.

Step 7: test, audit, launch in stages

1. Deploy Governor, timelock and token to a testnet. Run full proposal lifecycles, including cancel, defeat and expiry.
2. Write tests for the attacks above: flash-loan voting, proposals that drain the timelock, quorum edge cases.
3. Audit any changes to standard Governor code and anything the timelock controls. Our audit checklist covers preparation.
4. Launch with the team multisig as guardian, with a narrow, written mandate and a date to remove it.
5. Hand over powers in steps: treasury first, parameters next, upgrades last.

Budget and timeline

Our planning estimates for the software side:

Audit and legal formation are extra and depend on scope and jurisdiction.

FAQ

How much does it cost to create a DAO?

A Safe multisig and a Snapshot space cost little beyond gas. An onchain Governor with custom contracts, an audit and a legal wrapper is a real project; our planning estimate for the software alone is 4 to 8 weeks of work.

Is Snapshot voting binding?

Not by itself. A Snapshot vote is a signed record. Someone has to execute it, either multisig signers by hand or a module like oSnap that executes through a Safe after a dispute window.

Does a DAO need a legal entity?

Not technically, but courts have treated unwrapped DAOs as associations or general partnerships, which can expose members to liability. Most serious DAOs now use a wrapper.

What is a good quorum for a DAO?

One based on your measured turnout. Run signalling votes first, then set quorum somewhere you can reach on important votes but high enough that a single large holder cannot pass proposals alone.

How do I stop governance attacks?

Read voting power at a past block, add a timelock before execution, cap what one proposal can move, and keep a narrowly scoped guardian during the early period.

Can I create a DAO without coding?

Yes, for basic setups. Safe, Snapshot and no-code DAO platforms cover multisig treasuries and offchain voting. Custom voting power, onchain execution or protocol control needs contract work.

Talk to us

We design and build governance systems: Snapshot and Safe setups, custom Governor contracts and governance apps. If you are planning a DAO or handing control of a protocol to token holders, contact us and we will help you decide what to put onchain first. More on our DAO governance services.