Operations
How to set up a multisig wallet for a DAO treasury
A multisig wallet requires several keys to approve one transaction. It is the standard way DAOs hold funds, and most of the risk lives in how it is configured rather than in the contract itself.
Choose the signer set first
Pick people who are independent of each other, reachable across at least three timezones, and accountable to the community. Publish who they are. A signer set nobody can name is not a control.
Avoid one organisation controlling enough keys to move funds alone, and avoid signers who share the same device, seed phrase or hardware supply chain.
Pick the threshold deliberately
Three of five is the usual starting point for a small treasury. Larger treasuries move to four of seven or five of nine. Higher thresholds are safer against compromise but slower and more likely to strand an approved decision.
Write down the recovery plan before you need it: how a lost key is replaced, who proposes the replacement, and how the community verifies it.
Connect the wallet to governance
The wallet should execute what governance approved, not what signers decide. That means the transaction is prepared from the proposal payload, signature collection starts automatically once the vote passes, and the timelock is respected.
Test the whole flow with a small transfer before any real money depends on it, and record the resulting hash against the proposal.
A setup checklist you can follow today
Name the signers publicly, confirm each one controls their key on separate hardware, deploy the wallet, set the threshold, and transfer a small test amount. Execute one test transaction end to end, including the timelock if you use one, before moving anything meaningful.
Document the process where members can read it: who the signers are, what threshold applies to which wallet, how a key is replaced, and where the transaction history can be verified.
The mistakes that cost DAOs money
Setting a threshold so high that routine payments stall, or so low that one compromised laptop drains the treasury. Both are configuration decisions, not contract risks.
Leaving signers unaccountable is the quieter failure. If nobody knows who holds keys, nobody notices when a signer stops responding, and the DAO discovers the gap only when a payment is urgent.
Keep the execution path connected: this guide pairs well with onchain audit trail, dao tooling and protocol parameter change, which cover the neighbouring steps between an approved vote and a settled onchain transaction.
Key concepts explained
New to this topic? These are the core terms you will meet again and again in governance work. Understanding them makes every proposal easier to read.
- Signer
- A key holder authorised to approve transactions from the wallet. Signers should be independent people, not one team on one device.
- Threshold
- The number of signatures required to move funds, written as three of five or four of seven.
- Key rotation
- Replacing a compromised or inactive signer key through a governed process rather than an informal handover.
- Spend cap
- A configured limit on how much value one transaction can move, used to keep fast operational wallets safe.
Frequently asked questions
- What threshold should a DAO multisig use?
- Three of five is a sensible default for small treasuries. Larger treasuries typically move to four of seven or five of nine, ideally paired with a timelock on high value actions.
- Can a multisig wallet be hacked?
- The contracts are well audited, so most incidents come from configuration and people: too few independent signers, keys on shared devices, or signers approving transactions they did not verify.
- What happens if a signer loses their key?
- The remaining signers approve a transaction that replaces the lost key with a new one, provided the threshold can still be met. Plan this before it happens, not after.