Launching a Community Treasury with On-Chain Governance

A community treasury is a dedicated pool of assets—typically native tokens, stablecoins, or LP positions—controlled by a decentralized autonomous organization (DAO). Unlike a traditional corporate treasury, its allocation is governed by the collective will of token holders through transparent, on-chain voting. This model is foundational for projects like Uniswap, which manages billions via its Uniswap Grants Program, and Compound, which uses its treasury to fund protocol development and incentives. The core mechanism enabling this is on-chain governance, where proposals to spend funds are executed automatically by smart contracts upon passing a vote.

Setting up a treasury requires careful planning across several components. First, you must choose a governance framework and treasury management platform. Popular options include OpenZeppelin Governor contracts, which provide a modular system for proposal creation and voting, and Tally or Snapshot for front-end interfaces and voting delegation. The treasury's multisig wallet or Vault contract (like those from Safe{Wallet} or Aragon) must be configured with the correct signers or permissions. Crucially, the governance token's distribution and voting parameters—such as proposal threshold, voting delay, and quorum—must be calibrated to balance security with active participation.

The technical workflow begins with a community member submitting a funding proposal. This is a transaction that specifies the recipient address, amount, and asset from the treasury. Using a standard like EIP-712 for structured data signing, the proposal is posted on-chain, initiating a voting period. Token holders then cast votes, with their voting power often proportional to their token balance. If the proposal meets the predefined quorum and achieves a majority, it moves to a timelock period—a security delay—before being automatically executed by the governance contract, transferring funds without manual intervention. This entire process is transparent and verifiable on a block explorer.

Effective treasury management extends beyond the launch. Best practices include establishing a clear funding framework or grant charter to guide proposal evaluation, as seen with Optimism's RetroPGF rounds. Regular financial reporting using tools like Llama for analytics is essential for transparency. Furthermore, consider implementing treasury diversification strategies to mitigate volatility, such as converting a portion of native tokens into stablecoins or yield-bearing assets via DeFi protocols. Security is paramount; regular audits of governance contracts, the use of a timelock controller, and establishing an emergency multisig council for critical upgrades are non-negotiable safeguards for the community's assets.

A community treasury is a smart contract-managed pool of assets, governed by token holders. To build one, you must understand the core components: a governance token for voting rights, a treasury vault (like OpenZeppelin's Governor with a Treasury module or a Gnosis Safe), and a proposal system for fund allocation. Familiarity with Solidity for custom logic and the ERC-20 and ERC-721 token standards is crucial, as these assets typically populate the treasury. You should also grasp key governance concepts like proposal lifecycle, quorum, voting delay, and execution strategies.

Your development environment needs specific tooling. Install Node.js (v18+), npm or yarn, and a code editor like VS Code. You'll use Hardhat or Foundry for smart contract development, testing, and deployment. For interacting with existing protocols, knowledge of Ethers.js or Viem libraries is essential. Set up a wallet (MetaMask) with testnet ETH on networks like Sepolia or Goerli. You will also need an Alchemy or Infura account for RPC node access and an Etherscan API key for contract verification.

Practical experience with DAO frameworks significantly accelerates development. Study the documentation and examples for OpenZeppelin Contracts (specifically the Governor suite), Aragon OSx, and DAOstack's Alchemy. Deploying and testing a simple governor contract from these frameworks on a testnet is a highly recommended first step. Understanding how to use Tenderly for simulation or OpenZeppelin Defender for admin operations will be valuable for managing a live treasury.

A community treasury is a smart contract-controlled pool of assets (like ETH, stablecoins, or governance tokens) used to fund projects, pay contributors, or manage protocol reserves. Its core architectural principle is on-chain governance, where token holders directly vote on proposals to allocate funds. This model, pioneered by protocols like Compound and Uniswap, replaces centralized control with transparent, programmable rules. The system typically comprises three key components: the treasury vault (holds assets), the governance module (handles proposal creation and voting), and an optional executor (automates approved transactions).

The governance lifecycle follows a standard pattern. First, a proposer submits a transaction, such as transfer(recipient, amount), to the governance contract, often requiring a minimum token stake. The proposal enters a voting period, where holders vote with their tokens, using mechanisms like token-weighted or delegated voting. After voting concludes, if the proposal meets predefined thresholds (e.g., a 4% quorum and 51% majority), it is queued for execution. A timelock delay is a critical security feature here, giving the community time to react to malicious proposals before they execute on-chain.

For implementation, most projects build on established frameworks. Using OpenZeppelin's Governor contracts with a TimelockController is a common and secure starting point. A basic treasury setup involves deploying three contracts: a governance token (ERC20Votes), a timelock, and the governor itself. The timelock address is set as the governor's executor, meaning all approved proposals are routed through it. This architecture ensures no single transaction can bypass the governance process. The code snippet below shows a simplified deployment flow using Foundry/Hardhat.

solidityCopy
// 1. Deploy Governance Token
ERC20Votes token = new ERC20Votes("Community Token", "CT");
// 2. Deploy Timelock (min delay of 2 days)
TimelockController timelock = new TimelockController(2 days, [], []);
// 3. Deploy Governor, using token for voting and timelock as executor
GovernorContract governor = new GovernorContract(token, timelock);
// 4. Grant the governor the 'proposer' role on the timelock
timelock.grantRole(timelock.PROPOSER_ROLE(), address(governor));
// 5. Renounce admin role from deployer for decentralization
timelock.renounceRole(timelock.TIMELOCK_ADMIN_ROLE(), msg.sender);

Critical design decisions involve setting governance parameters that balance agility with security. The voting delay (time between proposal and voting start) and voting period (typically 3-7 days) must be calibrated. The proposal threshold prevents spam, while the quorum ensures sufficient participation. For a DAO treasury holding significant value, a longer timelock (e.g., 48-72 hours) is non-negotiable. It's also essential to decide on treasury asset management: will funds sit idle, be deployed in DeFi yield strategies via Gnosis Safe modules, or be diversified? Each choice adds complexity and risk to the architecture.

Post-launch, the system requires active maintenance. You must monitor proposal activity, educate the community on the voting process, and consider upgrades. Governance can be extended with tools like Snapshot for gas-free signaling, Tally for delegate management, and Safe{Wallet} for multi-signature execution. The ultimate goal is a resilient system where the community, not a central team, has verifiable and sovereign control over its shared resources, aligning incentives and fostering sustainable growth.

Before deploying, you must decide on the signature threshold for your Safe. This is the minimum number of owner signatures required to execute a transaction. For a community treasury, a common setup is a 2-of-3 or 3-of-5 multi-signature scheme, balancing security with operational efficiency. You'll also need to define the initial list of owner addresses, which should be the wallets of your core team or governance token holders. These parameters are immutable after deployment, so choose carefully.

Deployment is done via the official Safe web interface or programmatically using the @safe-global/safe-core-sdk. The interface is recommended for first-time users. You'll connect your wallet, pay the gas fee for deployment on your chosen network (e.g., Ethereum Mainnet, Arbitrum, Optimism), and configure the owners and threshold. The resulting Safe is a smart contract at a unique address, which becomes your treasury's official on-chain vault.

After deployment, you should perform essential configurations. First, give your Safe a name in the dashboard for easy identification. Next, consider enabling Safe Modules. The most critical for governance is the Zodiac Module, which allows the Safe to be controlled by an external contract, like a DAO's governance executor. You may also set up recovery mechanisms and spending limits for specific owner addresses to delegate routine operations safely.

Finally, fund your Safe. Send the initial treasury assets (like ETH, USDC, or governance tokens) to the Safe's contract address. All subsequent transactions—paying contributors, funding grants, or participating in DeFi—will require the pre-defined number of owners to sign off, ensuring collective custody. Your secure, on-chain treasury foundation is now ready to be connected to a governance framework.

Before deployment, you must finalize your governance parameters. These are hardcoded into the contract and define your DAO's core rules. Key parameters include the voting delay (time between proposal submission and voting start), voting period (duration of the voting window), proposal threshold (minimum token balance to create a proposal), and quorum (minimum percentage of total token supply required for a vote to be valid). For a new DAO, common starting values are a 1-block voting delay, a 3-day voting period, a 1-token proposal threshold, and a 4% quorum.

We will deploy a contract using the Governor pattern, which separates the governance logic from the treasury asset holding. The typical architecture involves two contracts: a Governor contract (e.g., GovernorCompatibilityBravo) that manages proposals and voting, and a TimelockController that holds the treasury funds and executes successful proposals after a mandatory delay. This separation is a critical security practice, as it prevents instant, unilateral execution of proposals.

Here is a simplified example of a deployment script using Hardhat and OpenZeppelin Contracts for a governance system with a native token (MyToken) and a Timelock. First, the Timelock is deployed with specified executors and proposers (initially just the deployer). Then, the Governor contract is deployed, linking it to the token and the Timelock address.

javascriptCopy
// Deploy TimelockController
const minDelay = 86400; // 1 day in seconds
const proposers = [deployer.address];
const executors = [deployer.address];
const timelock = await ethers.deployContract('TimelockController', [minDelay, proposers, executors]);

// Deploy Governor, using the token's address and the new timelock
const governor = await ethers.deployContract('MyGovernor', [token.address, timelock.address]);

After deployment, you must configure the permissions. The most crucial step is granting the Governor contract the PROPOSER_ROLE on the TimelockController. This allows only proposals that pass a governance vote to be queued for execution. You should also grant the Governor the EXECUTOR_ROLE (or often the publicExecutor address) so it can execute passed proposals after the timelock delay. Finally, you should revoke these administrative roles from the initial deployer address to achieve full decentralization.

Once deployed and configured, the governance contract's address becomes the central hub for your community. You should verify and publish the source code on a block explorer like Etherscan. The next step is to transfer the initial treasury funds (e.g., ETH, stablecoins, or project tokens) to the TimelockController address, where they will be securely locked and only accessible via the on-chain governance process you've just established.

The execution module is the smart contract that holds the treasury's assets and executes the will of the governance body. It is the only contract authorized to move funds after a proposal passes. This separation of concerns—voting logic in one contract, fund custody in another—is a critical security pattern. The module should inherit from OpenZeppelin's Ownable or a similar access control contract, initially owned by a deployer address that will later transfer ownership to the governance contract (like a Governor or Timelock).

Core functions include executeTransaction, which allows the owner (the governance contract) to send ETH or ERC-20 tokens to a specified address. For ETH, this uses call{value: amount}(""). For ERC-20s, it calls the token's transfer function. A critical security measure is to implement a receive function that rejects direct ETH transfers unless they are part of a governed action, preventing accidental fund locking. Always include event emissions like TransactionExecuted for full on-chain transparency.

For advanced treasuries, you can build functionality for recurring budgets or vesting schedules. A createStream function could use a linear vesting formula, releasing tokens from the treasury to a grantee address over time. This requires tracking stream IDs, start times, durations, and total amounts. The withdrawFromStream function would then calculate the releasable amount based on elapsed time. Consider integrating with Sablier or Superfluid for complex streaming logic instead of building it from scratch.

Thorough testing is non-negotiable. Write Foundry or Hardhat tests that simulate the full governance flow: a proposal is created, voted on, queued in a timelock, and finally executed by this module. Test edge cases: execution by a non-owner should revert, failed token transfers (e.g., insufficient balance) should be handled gracefully, and event logs must be correct. Use a forked mainnet environment to test with real ERC-20 tokens like DAI or USDC.

Once tested, deploy the execution module. The final, crucial step is to transfer ownership from the deployer EOA to the governance contract's address (e.g., the TimelockController). This action permanently enshrines the rule that only passed proposals can move funds. Verify this ownership transfer on a block explorer. The treasury is now live but inert; it awaits its first governed proposal to activate its economic power for the community.

A well-structured proposal is critical for voter comprehension and approval. It must clearly articulate the what, why, and how of the request. Core components include a descriptive title, a detailed specification of the work, a transparent budget breakdown in the native token or stablecoins, a defined recipient address (often a multi-sig), and a clear timeline for deliverables. For technical grants, linking to a full specification document or GitHub repository is a best practice. Platforms like Snapshot (for off-chain signaling) and Tally or the protocol's native governance portal are commonly used for submission.

The submission process involves interacting directly with the governance smart contracts. You'll typically call a function like propose() on the governor contract, passing an array of target addresses, values, and calldata for the transactions to execute if the proposal passes. For a simple funding proposal, the target is the treasury contract, the value is the requested amount, and the calldata encodes a transfer function call. Here's a conceptual example using a Solidity interface:

codeCopy
// Pseudocode calldata for a 10 ETH transfer
address treasury = 0x...;
uint256 amount = 10 ether;
bytes memory data = abi.encodeWithSignature("transfer(address,uint256)", recipient, amount);

governor.propose([treasury], [amount], ["Send grant"], [data], "Proposal: Fund Developer Grant #1");

Always verify the proposal ID returned by the contract.

Before submitting on-chain, conduct final checks. Verify all addresses (recipient, treasury) are correct. Ensure the requested amount is accurate and the treasury has sufficient liquidity. Confirm the proposal lifecycle parameters—voting delay, voting period, and quorum—set by the governance framework. Many communities require a pre-proposal discussion thread on forums like Commonwealth or Discourse to gauge sentiment and incorporate feedback; skipping this step can lead to swift rejection. Once submitted, the proposal enters a pending state before moving to active voting, where token holders will make the final decision.

Once a proposal passes the quorum threshold and the voting period concludes, the governance contract tallies the votes. The outcome is determined by simple majority, supermajority, or other predefined rules encoded in the contract. For a typical ERC-20 token-based system, each token equals one vote, though mechanisms like vote delegation or quadratic voting can modify this. The final state—Passed, Rejected, or Executed—is immutably recorded on-chain. This transparency ensures every community member can audit the decision-making process.

A passed proposal does not automatically execute. Most governance frameworks, including Compound's Governor Bravo and OpenZeppelin's Governor, implement a timelock pattern. The approved proposal's actions are queued in a Timelock contract for a mandatory waiting period (e.g., 48 hours). This delay is a critical security feature, providing a final window for the community to react if a malicious proposal was somehow approved. During this period, the proposal's target addresses and calldata are public, allowing for scrutiny.

After the timelock delay expires, any address (typically the proposal's creator or a designated executor) can call the execute function. This triggers the Timelock contract to perform the encoded transactions, such as transferring funds from the treasury or upgrading a protocol contract. The execution is atomic; if any transaction in the proposal bundle fails, the entire execution reverts. Successful execution marks the proposal's lifecycle as complete, and the treasury's state is updated according to the community's directive.