How to Design a SubDAO Treasury Management Framework

A SubDAO treasury management framework defines the rules, tools, and processes for a decentralized sub-organization to hold, allocate, and spend its assets. Unlike a simple multi-signature wallet, a robust framework incorporates on-chain governance for proposal voting, transparent accounting for all transactions, and clear spending policies aligned with the SubDAO's mandate. The core components typically include a Gnosis Safe or Safe{Wallet} for custody, Snapshot or a custom governor contract for voting, and a tool like Llama or Parcel for budgeting and disbursements. The goal is to balance security, operational efficiency, and decentralized control.

The first step is establishing secure custody and access controls. A multi-signature wallet is the foundational layer, requiring a predefined threshold of signatures (e.g., 3-of-5) to execute any transaction. For Ethereum-based treasuries, Gnosis Safe is the industry standard. Governance then dictates who are the signers—often elected council members or key contributors. For more complex, programmatic rules, you can use a Zodiac module to connect the Safe to a governor contract (like OpenZeppelin's Governor), allowing token-based voting to directly authorize transactions. This creates a clear separation between the proposal/voting layer and the execution layer.

Next, define the operational workflow for treasury actions. A typical flow starts with a temperature check on a forum like Discourse or Commonwealth. A formal proposal is then created on Snapshot (for gasless voting) or directly on-chain. The proposal should specify the recipient address, amount, asset (ETH, USDC, governance tokens), and purpose. Upon approval, an authorized executor submits the transaction to the multi-sig. Tools like Llama automate this by creating budget streams and pull-based payments, reducing administrative overhead. It's critical to maintain full transparency by logging all proposals and transactions in a public dashboard or a tool like Dune Analytics.

Asset allocation and risk management are crucial for long-term sustainability. A SubDAO treasury isn't just a checking account; it's a balance sheet. A basic strategy might segment funds into categories: an operational runway in stablecoins, a contributor grant pool in the native token, and a diversified reserve in blue-chip assets like ETH or staked ETH. For on-chain diversification, consider using DeFi primitives through trusted multi-sig signers or via a smart contract vault with strict whitelists. However, any DeFi strategy must be explicitly approved via governance to mitigate smart contract and market risks. The key is to codify these allocation guidelines in the SubDAO's charter.

Finally, implement reporting and accountability mechanisms. Regular on-chain financial reporting is non-negotiable. Use a script or a service to generate monthly statements of assets, liabilities, and expenses. Transparency portals built with The Graph for indexed data or Dune for dashboards allow any community member to audit treasury flows. Establish clear rage-quit or exit procedures for members, defining how treasury assets are handled upon a SubDAO's dissolution or a member's departure. By designing the framework with these elements—secure custody, governed workflows, strategic allocation, and transparent reporting—you create a SubDAO treasury that is both functional and trustworthy.

A SubDAO treasury is not an isolated contract; it's a system integrated into a broader governance and execution stack. The primary prerequisite is a live DAO framework with established governance mechanisms. This is typically a parent DAO using a governance standard like OpenZeppelin Governor or a DAO-specific platform such as Aragon OSx or DAOstack. Your SubDAO's authority and permissions will be derived from this parent entity. You must also have a clear multi-signature wallet or safe (like Safe{Wallet}) designated as the initial treasury custodian, controlled by the parent DAO's authorized signers.

On the technical side, you need proficiency with smart contract development and tooling. Assumptions include familiarity with Solidity, Hardhat or Foundry for development and testing, and Ethers.js or Viem for front-end integration. You should understand token standards (ERC-20, ERC-721) and governance standards (ERC-5805, ERC-6372). The framework will rely on existing audited primitives for security; for example, using OpenZeppelin's Governor contracts and TimelockController for proposal execution delays. A basic CI/CD pipeline for contract deployment and verification is also assumed.

Finally, establish clear operational and financial assumptions. Define the SubDAO's scope of authority: what asset types (native ETH, stablecoins, LP tokens) it can manage and what transaction types (swaps, stakes, grants) it can execute. Determine the proposal lifecycle, including thresholds for proposal submission, voting duration, and quorum requirements. Assume the need for off-chain data via oracles (like Chainlink) for price feeds if automated strategies are planned. These assumptions form the blueprint that your smart contract framework will codify, moving from abstract governance rules to enforceable on-chain logic.

A well-defined treasury policy establishes clear governance parameters and operational guardrails. Start by defining the core objectives: is the treasury for protocol development, community grants, liquidity provisioning, or a diversified endowment? Explicitly state the treasury's risk tolerance—whether it's conservative (favoring stablecoins and blue-chip assets) or growth-oriented (allocating to higher-risk DeFi strategies). This document should be ratified by the parent DAO or via the SubDAO's own governance process, making it a binding smart contract or a publicly verifiable on-chain record.

The policy must specify decision-making authority. Outline which actions require a full governance vote versus delegated authority to a multisig committee or a dedicated treasury manager. For example, rebalancing a portfolio within pre-defined bands might be delegated, while investing in a new asset class requires a vote. Define transaction limits and approval thresholds (e.g., any single transaction over $50,000 requires 3-of-5 multisig signatures). Tools like Safe{Wallet} and Zodiac modules are commonly used to encode these rules into executable on-chain roles.

A critical section is asset allocation and risk management. Detail the approved asset classes (e.g., stablecoins, ETH, staked assets, LP positions) and set maximum allocation percentages for each. Mandate regular portfolio reporting using tools like Llama or Karpatkey for transparency. Include protocols and strategies that are whitelisted for interaction (e.g., Aave for lending, Uniswap for liquidity) and explicitly blacklist high-risk or unaudited protocols. This reduces operational risk and prevents ad-hoc, speculative decisions.

Finally, the policy should establish operational procedures for recurring tasks. This includes a schedule for financial reporting (e.g., monthly balance sheets), processes for handling airdrops or unexpected income, and a clear emergency response plan for security incidents or market crashes. The policy is a living document; include an amendment process requiring a governance vote to ensure it evolves with the SubDAO's needs and the broader market landscape.

The first decision is selecting a multi-signature wallet provider. For Ethereum and EVM-compatible chains, Gnosis Safe is the industry standard, securing over $100B in assets. Alternatives like Safe{Wallet} (formerly Gnosis Safe) offer a robust, audited smart contract suite with a user-friendly interface. For Solana, Squads provides similar multi-sig functionality. Your choice should be based on the native chain of your treasury assets, desired features like transaction scheduling, and the level of integration with other treasury management tools.

Before deployment, you must define the signer set and signature threshold. The signer set is the list of wallet addresses (typically belonging to core contributors or elected council members) authorized to propose and approve transactions. The threshold is the minimum number of signatures required to execute a transaction. A common configuration for a 5-member council is a 3-of-5 threshold, balancing security with operational efficiency. Carefully document each signer's public address and their associated real-world identity or role within the SubDAO.

Deployment is done through the provider's web interface or via script. For a Gnosis Safe on Ethereum mainnet, you would connect your wallet (using one of the designated signer addresses) to app.safe.global, create a new Safe, and input the signer addresses and threshold. The process deploys a new smart contract wallet, incurring a one-time gas fee. It is critical to verify the contract address on a block explorer like Etherscan after deployment. Store this address securely, as it will be the public treasury address for your SubDAO.

Post-deployment, establish clear internal procedures. This includes how to initiate a transaction (e.g., a payment request form), the process for signers to review and approve, and rules for emergency transactions. Many teams use a dedicated transaction hash in their communication tool (like Discord or a forum) to track each proposal from initiation to execution. Test the wallet with a small transaction first to ensure all signers can successfully confirm. This dry run validates your process and familiarizes the team with the interface.

Finally, integrate your new multi-sig address into your SubDAO's ecosystem. Update your DAO's front-end (like a Snapshot space or custom dashboard) to display the treasury address. Connect it to on-chain analytics platforms like Dune Analytics or Nansen for transparent tracking of balances and inflows/outflows. The deployed multi-signature contract is now the secure, programmable vault for your community's assets, ready for the next step: funding and defining a spending policy.

A budgeting and spending cycle formalizes how a SubDAO proposes, approves, and executes financial decisions. This replaces ad-hoc spending with a predictable, auditable process. The core components are a budget proposal, a voting period for approval, and a disbursement mechanism for on-chain execution. Popular frameworks include quarterly budgeting cycles aligned with roadmap milestones or continuous funding through streaming platforms like Sablier or Superfluid. The choice depends on your SubDAO's operational tempo and funding needs.

The budget proposal is the foundational document. It should specify the allocation amount, recipient address(es), funding timeframe, and success metrics (KPIs). For transparency, proposals are often drafted using templates in forums like Discourse or Commonwealth before moving to a formal snapshot. Smart contracts can encode these details, making the approved budget an executable on-chain object. For example, a proposal might allocate 50,000 USDC to a developer guild over Q3, with 25% released upfront and the remainder streamed monthly contingent on code commits verified by OpenZeppelin Defender.

On-chain execution separates approval from payment, preventing unilateral control. After a proposal passes, funds are typically moved from the treasury's core Gnosis Safe to a dedicated spending module. For one-time payments, a multisig transaction suffices. For recurring expenses, use a streaming payment contract. Tools like LlamaPay allow for gasless, automated streaming to contributors. To enforce accountability, consider vesting contracts with cliffs or conditional disbursements using oracles like Chainlink to verify off-chain deliverables before releasing funds.

Implementing a spending cycle requires careful smart contract design. A basic Solidity escrow contract can hold funds and release them to a predefined address after a timelock. More advanced setups use Governor contracts (from OpenZeppelin) where the proposal's calldata includes the target contract and function call for disbursement. Here's a simplified example of a budget release function:

solidityCopy
function releaseBudget(address beneficiary, uint256 amount) external onlyGovernance {
    IERC20(token).transfer(beneficiary, amount);
    emit FundsReleased(beneficiary, amount, block.timestamp);
}

The onlyGovernance modifier ensures only a successful proposal can trigger payment.

Continuous improvement is critical. After each cycle, the SubDAO should review budget vs. actual spending and KPI attainment. This post-mortem, documented on-chain via Snapshot votes or DAO tooling like Boardroom, informs the next budget cycle. It creates a feedback loop where spending efficiency improves over time. This process transforms the treasury from a static vault into a dynamic capital allocation engine, directly linking community votes to executable financial operations and measurable outcomes.

Transparent financial reporting is the cornerstone of a trustworthy SubDAO treasury. It moves beyond simple balance checks to provide a comprehensive audit trail of all inflows and outflows. A well-designed framework answers key questions for token holders: Where did the funds come from? How are they being spent? What is the treasury's current runway and financial health? This transparency builds trust, deters misuse, and provides the data necessary for the DAO to make strategic financial decisions. Without it, governance becomes guesswork.

The foundation of this system is on-chain data aggregation. Tools like Dune Analytics, Flipside Crypto, or custom subgraphs should be used to create a real-time dashboard tracking the treasury's wallet addresses. Key metrics to display include: total asset value (in ETH/USD), breakdown by asset type (e.g., native token, stablecoins, LP positions), historical transaction volume, and a list of recent approved proposals with their disbursed amounts. This dashboard becomes the single source of truth for the community.

However, on-chain data alone is insufficient. A complete framework integrates off-chain reporting for context. This includes quarterly financial statements published on the DAO's forum or documentation site. These reports should reconcile on-chain activity, explain the rationale behind major expenditures (linking to governance discussions), provide commentary on budget vs. actuals, and forecast future runway based on current burn rates. Using a standardized template, like a simplified income statement and balance sheet, ensures consistency and comparability over time.

For technical implementation, consider automating report generation. A script can be written to query the Dune API or a subgraph, compile the data into a structured format (like JSON or CSV), and generate the core figures for the quarterly report. For example, a Node.js script using axios can fetch data and pdfkit can create a PDF summary. This reduces manual effort and minimizes errors. The code and data sources should be open-sourced to further enhance verifiability.

javascriptCopy
// Example snippet for fetching treasury balance from Dune API
const axios = require('axios');
async function getTreasuryBalance(apiKey, queryId) {
  const response = await axios.get(
    `https://api.dune.com/api/v1/query/${queryId}/results`, 
    { headers: { 'X-Dune-API-Key': apiKey } }
  );
  return response.data.result.rows[0].eth_balance;
}

Finally, establish a clear reporting cadence and review process. Mandate that financial summaries are posted to the governance forum at the end of each epoch or month, with a comprehensive quarterly report. These reports should then be followed by a dedicated community call or AMA where treasury stewards present the findings and answer questions. This closes the feedback loop, ensuring the reporting is not just a data dump but a tool for active governance and continuous improvement of the SubDAO's financial strategy.

The key to successful implementation is starting with a Minimum Viable Treasury (MVT). Begin by codifying your core governance model and risk parameters in a smart contract, even if initial execution remains manual. For example, a Gnosis Safe with a basic Snapshot voting strategy for budget approvals is a common starting point. This establishes the foundational governance layer upon which automated multisig execution and more complex DeFi strategies can be layered later. Prioritize transparency from day one by publishing all transactions and proposal outcomes on-chain or to an explorer like Dune Analytics.

Your next technical steps should focus on automation and integration. Use a tool like Safe{Core} Protocol and its SDK to programmatically create transactions that execute upon successful Snapshot votes, moving beyond manual proposal fulfillment. Investigate treasury management platforms like Llama or Coinshift, which provide interfaces for proposal creation, fund streaming via Superfluid, and reporting. For on-chain asset management, start by integrating with a yield aggregator like Yearn Finance or a lending protocol like Aave using their smart contract APIs to put idle stablecoins to work, always within pre-defined risk limits.

Continuous iteration is critical. Establish regular review cycles—quarterly is a good baseline—to assess framework performance against KPIs like treasury runway, asset diversification, and yield generated. Use this data to propose parameter adjustments, such as increasing the delegated authority limit for the finance working group or adding new whitelisted protocols for deployment. Engage your community in these reviews through governance forums to maintain alignment and trust.

Finally, remember that no framework is complete without a clear contingency plan. Document and test emergency procedures for responding to a governance attack, a critical protocol hack affecting your assets, or a sudden market downturn. This should include a designated emergency multisig with a high threshold, a communication plan, and pre-approved actions like moving funds to cold storage. By building iteratively, automating deliberately, and planning for failure, your SubDAO can develop a treasury that is not just secure, but a strategic asset driving long-term growth.