Treasury
DAO treasury management without the spreadsheet
Treasuries fail for boring reasons: unclear approvals, ad-hoc payouts and no permanent record. Governance-controlled execution fixes all three.
Design the approval ladder
Small grants can clear with a low quorum and a two-of-four signer set. Anything touching a material share of the treasury should demand a higher threshold and a longer timelock.
Encode payouts as transactions, not intentions
A treasury proposal should carry the token address, recipient, amount and chain. The vote then approves an exact transfer rather than a paragraph.
Report from the chain, not from memory
Every executed payout produces a hash. A treasury report built from hashes is impossible to fudge and trivial to reconcile.
Building a treasury policy people can follow
A treasury policy should answer three questions before any payment is proposed: what the money is for, who may move it, and what proof is filed afterwards. Written that way, most disputes disappear, because the argument happens once at policy level rather than every time a payment appears.
The strongest policies set spending tiers. Small operational payments clear through a working group multisig, medium spend needs a standard vote, and anything that materially changes runway needs a longer timelock so the community has time to react.
Runway, diversification and reporting
Runway is the honest measure of treasury health: months of committed spend covered by liquid, non native assets. A treasury denominated almost entirely in its own token has a paper balance, not a budget, because selling into a downturn is exactly when the price will not support it.
Report on a fixed cadence with the same format each time: opening balance, inflows, outflows by category, closing balance and the transaction hashes behind each line. Consistency matters more than sophistication, because it lets readers compare one quarter with the next.
Keep the execution path connected: this guide pairs well with rollup governance, governance proposal template and dao governance metrics, 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.
- Treasury
- The pool of assets a DAO controls onchain - native tokens, stablecoins and protocol revenue. Every movement should trace back to an approved governance action.
- Approval ladder
- A tiered policy where small payouts clear with light checks and large ones demand higher thresholds, more signers and longer timelocks.
- Batching
- Grouping multiple approved payouts into a single transaction to save gas and simplify record-keeping.
- Runway
- How many months a treasury can fund operations at the current spend rate. Healthy DAOs track runway per asset, not just in aggregate.
Frequently asked questions
- How does a DAO treasury actually pay someone?
- A payment is a transfer transaction from the treasury contract or multisig. It is authorised by a vote or by a delegated spending policy, then executed by signers, and the resulting hash becomes the receipt.
- How much of a DAO treasury should be in stablecoins?
- There is no universal figure, but a common approach is holding twelve to twenty four months of committed operating spend in stable assets so that contributor payments never depend on token price.
- Who controls a DAO treasury?
- The contract holding the funds does, and the contract answers to the governance rules configured for it. In practice that means token holders through votes, and signers who carry out approved transfers.