DAO treasuries sit on balance sheets that would put them in the top quartile of mid-cap funds, and run on signing setups that would not pass a credit-card company's onboarding. Closing that gap, without sacrificing the decentralisation that defines DAOs, is the work.
This is the playbook we run through with DAO operations teams. None of it is novel; all of it is consistently underdone.
The four risks every DAO treasury faces
1. Signer compromise. A 5-of-9 multi-sig where signers don't know each other personally is a real social attack surface. Spoofed Discord DMs, fake calendar invites, malicious transaction simulation, the social layer of the multi-sig is where attackers focus, because the cryptographic layer is hard.
2. Governance approving the wrong calldata. DAOs routinely approve proposals calling unaudited contracts. The community sees the proposal title; the Safe signs the calldata. Without a review process, governance becomes the vulnerability, and there is no exploit needed, just a successful Snapshot vote.
3. Cross-chain complexity. Funds on Ethereum, L2s, lending markets, LSTs, RWAs. The treasury surface grows with every yield strategy. Tracking exposure, custody, and counterparty risk is a continuous job, not a quarterly one.
4. No CEO to call when things break. When something goes wrong, there is no clear escalation path. Every incident becomes a forum thread instead of a coordinated response.
The architecture
The default architecture we recommend has four wallets, each with a different threshold and a different scope:
Cold treasury
The bulk of the assets. 5-of-9 or 6-of-9 multi-sig, signers on hardware wallets, geographically distributed, with at least two signers in each major timezone. No regular operations, just rebalances voted on by governance, with a 48-72h timelock.
This wallet is touched on the order of once a month. Touching it is a deliberate, scheduled event with a review checklist.
Working treasury
The operational float, typically a few weeks of grant payments, contributor compensation, and operational expenses. 3-of-5 multi-sig, signers on hardware wallets, faster threshold to assemble. Low cap on outstanding balance; replenished from cold treasury on a schedule.
A drain of the working treasury is a bad day. It does not touch the cold treasury.
Per-strategy wallets
Each yield strategy or external integration gets its own multi-sig. If the strategy goes wrong, only that wallet is exposed. If the strategy needs to be exited, only the relevant signers need to coordinate.
This is the principle of compartmentalisation, applied to DeFi. It costs a bit more in operational overhead and is worth orders of magnitude more in incident bounding.
Emergency pause
If your protocol has emergency pause functions, the holder of those functions is its own multi-sig, typically a smaller set of signers chosen for availability and timezone coverage rather than political balance. The mandate is narrow: pause when needed, nothing else.
Signer selection and operational hygiene
Who signs is an operational decision, not just a political one.
Diversity of identity and infrastructure. Signers should not all work for the same entity, all use the same email provider, all run the same browser, all keep their hardware wallet in the same physical building. If a single attacker can compromise one organisation and reach five signers, the threshold is fictional.
Hardware wallets, no exceptions. Every signer signs from a hardware wallet (Ledger, Trezor, GridPlus, Keystone). The signer is responsible for verifying the calldata on the device, not on the dApp UI, not in the simulation. The device display is the source of truth.
Documented signing procedure. Every transaction goes through:
- Proposal posted in the multi-sig with the calldata.
- Signers review the calldata. Senior or technical signers should run Tenderly or equivalent simulation independently and post the result.
- Signers verify on hardware-wallet display before signing.
- Threshold reached, transaction executed.
Skipping any step has cost real DAOs real money. The procedure exists because the failures exist.
Onboarding and offboarding signers is a ceremony. Adding a signer is a multi-step procedure with hardware procurement, testnet drills, identity verification. Removing a signer is a ceremony too, and not optional when a contributor leaves.
We deliver this as part of a Wallet Setup engagement: the architecture, the signer list, the runbooks, and a live training session for the signers themselves.
Governance hardening
A multi-sig that signs whatever Snapshot tells it to is a governance vulnerability disguised as decentralisation.
Calldata review before voting. Every executable proposal should have a calldata review attached, what addresses it touches, what functions it calls, what value it moves, what permissions it grants. The forum post that lacks a calldata review should not be voted on, full stop.
Standardised contract patterns. The DAO maintains a library of approved contracts (governance modules, treasury managers, distribution mechanisms). New patterns require review by the security working group before use. This dramatically narrows the calldata-review surface for any single proposal.
Timelocks proportional to value. Routine rebalance: 48 hours. Smart-contract upgrade: 7 days. Treasury policy change: 14 days. The timelock is the time the community has to react to a bad proposal, including the time to socially coordinate a counter-proposal.
Quorum that costs money to defeat. Snapshot votes that pass with 2% participation are not governance; they are theatre. Adjust quorum requirements upward as TVL grows.
Continuous monitoring
The architecture and the procedures are static; the threat surface is not. New strategies launch, new bridges deploy, new exploit patterns appear.
Wallet Surveillance on the treasury wallets and on the addresses they interact with is the continuous layer:
- Queued transactions in the Safe surface in alerts before they execute.
- Approvals to unfamiliar contracts trigger review.
- Outflows that diverge from baseline are flagged.
- Interactions with sanctioned or known-malicious addresses are blocked at the alerting layer.
The cost is small. The benefit is the difference between catching a malicious proposal in the queue and reading about it in a post-mortem.
When something goes wrong
A DAO without a written incident-response procedure will run its first incident through its forum. This is bad for the funds and worse for the community.
The procedure that works:
- A pre-authorised Working Group of contributors with the mandate to coordinate response.
- A written escalation path: who gets paged, in what order.
- A standing relationship with an Incident Response firm, engaged on retainer or at least pre-vetted, so the first hour is execution, not procurement.
- Drafted communication templates for "we are aware", "we have contained", "post-mortem", to be filled in and approved fast.
The DAOs that have survived incidents, and there have been a few, survived because they had the response in place before they needed it. The ones that did not, did not survive.
Where this lands
A DAO treasury that is properly structured can run for years through every kind of market without a serious incident. The work is upfront, architecture, runbooks, signer training, monitoring setup, and ongoing, quarterly review, annual exercises, regular signer rotation.
The alternative is the long tail of DAOs whose treasuries have been drained, often by a single signer's mistake, often documented on-chain forever. That outcome is not random; it is the predictable result of skipping the work.
We do this work for DAO treasuries of every size, from small protocol DAOs to nine-figure ecosystem treasuries. The pattern transfers across scale; only the dollar value of the consequences scales.