Setting Up Community Treasury Management with Token Governance

An on-chain treasury managed by token governance is a smart contract that holds a community's assets—such as native tokens, stablecoins, or NFTs—and allows token holders to propose and vote on how those funds are spent. This model replaces centralized control with a programmable, transparent, and democratic process. Core components include a treasury vault (e.g., a Gnosis Safe), a governance token for voting rights, and a governance module (like OpenZeppelin Governor) to manage proposals. Setting this up requires deploying a series of interconnected contracts that define the rules for proposal creation, voting, and execution.

The first step is to define your governance parameters, which are critical for security and efficiency. Key parameters include the voting delay (time between proposal submission and voting start), voting period (duration of the vote), proposal threshold (minimum tokens needed to submit a proposal), and quorum (minimum voter participation for a proposal to be valid). For a community DAO, typical values might be a 1-day delay, a 3-day voting period, a threshold of 0.5% of total supply, and a 4% quorum. These are set in the governance contract constructor and dictate the pace and security of your decision-making process.

Next, you must deploy and configure the treasury vault. The Gnosis Safe is the industry standard, acting as a multi-signature wallet that only executes transactions approved by the governance contract. After deploying a Safe, you set the governance contract as its sole owner. This is done by calling setup() with the governance address, a threshold of 1, and no other owners. All treasury assets are then sent to the Safe's address. The governance contract will be the only entity able to trigger transactions via the execTransaction method, but only after a successful vote.

The governance contract needs a way to interact with the treasury. This is achieved by writing and deploying a custom Treasury Module or using a pattern like Governor's TimelockController. This module contains the logic for executing approved proposals. A simple executeProposal function might take a target address, value, and calldata, and forward it to the Safe. Crucially, this function should include access control, such as the onlyGovernance modifier, to ensure only passed proposals can trigger payouts, grants, or investments from the community fund.

Finally, you integrate everything by connecting the governance token, governance contract, and treasury. Token holders can now create proposals by calling propose() on the governance contract, which includes an array of target addresses and calldata for the desired actions (e.g., sending 1000 USDC to a contributor). After the voting period, if quorum is met and the vote passes, anyone can call execute() to run the proposal's transactions through the treasury module. This entire flow—propose, vote, execute—ensures transparent, on-chain accountability for every treasury expenditure, governed directly by the community.

A community treasury is a smart contract that holds and manages a pool of assets, governed by a community's token holders. The core prerequisites are a governance token, a development environment, and a blockchain network. You'll need a governance token contract (like an ERC-20 or ERC-1155) already deployed, as it will be used for voting on treasury proposals. For development, set up Hardhat or Foundry with Node.js version 18 or later. You will also need a wallet (like MetaMask) with testnet ETH for deployment gas fees and interaction.

Choose your deployment network carefully. For testing, use a Sepolia or Goerli testnet. For production, consider mainnets like Ethereum, Arbitrum, or Optimism, balancing security, cost, and community preference. You must obtain testnet ETH from a faucet. Configure your .env file with a PRIVATE_KEY for your deployer wallet and an RPC URL from a provider like Alchemy or Infura. This setup allows your scripts to connect to the blockchain and sign transactions.

The treasury's logic is defined by its smart contract. You can use an audited base implementation like OpenZeppelin Governor with a Treasury module, or build a custom contract. Key contract components to understand are: the proposal lifecycle (create, vote, execute), the timelock for security delays, and the executor role. Install necessary dependencies: npm install @openzeppelin/contracts for standard contracts and dotenv for environment variables. Verify your setup by compiling a simple contract to ensure no configuration errors exist.

With the environment ready, write deployment scripts. A basic Hardhat script deploys three core contracts: the Token, the TimelockController, and the Governor contract that references them. The timelock becomes the treasury's owner, meaning only successful governance proposals can move funds. After deployment, you must initialize governance parameters: set the voting delay, voting period, proposal threshold, and quorum. These values define how responsive and secure your governance will be.

Finally, fund the treasury and delegate voting power. Transfer an initial amount of the governance token (or other assets like ETH or stablecoins) to the treasury contract's address. Token holders must then delegate their voting power to themselves or a representative to participate. Use the token contract's delegate function. Without delegation, tokens cannot be used for voting. This completes the foundational setup, creating a secure, non-custodial treasury ready for community proposals and fund management.

A community treasury managed by token governance is a foundational primitive for DAOs and decentralized protocols. Its core architecture consists of three key smart contracts: a treasury vault that holds assets, a governance token that confers voting rights, and a governor contract that processes proposals and executes transactions. The treasury vault is typically a multi-signature wallet or a more sophisticated contract like OpenZeppelin's TimelockController, which introduces a mandatory delay between proposal approval and execution. This delay is a critical security feature, allowing token holders to react to malicious proposals.

The governance token, often an ERC-20 or ERC-1155, must be carefully designed to prevent centralization and attack vectors. Common patterns include a linear voting model (one token, one vote) or a delegation model as seen in Compound's Governor system, where users can delegate voting power. The token's distribution mechanism—whether through a fair launch, airdrop, or liquidity mining—directly impacts the decentralization and security of the treasury. A common pitfall is concentrating too much voting power in the hands of early developers or investors, which can lead to governance capture.

The governor contract is the engine of the system. It defines the rules for creating proposals, the quorum required for a vote to be valid, and the voting period. A proposal to spend from the treasury, for instance, would encode a target transaction (e.g., send 100 ETH to a grant recipient) and be submitted for a vote. Using a standard like OpenZeppelin Governor provides battle-tested logic for these processes. The contract must be configured with sensible parameters: a voting delay (time between proposal submission and start of voting), a voting period (typically 3-7 days), and a proposal threshold (minimum tokens required to submit a proposal).

Security is paramount in treasury design. Beyond the timelock, consider implementing a multisig guardian role for emergency functions, setting spending limits per proposal, and requiring a high quorum (e.g., 4% of total supply) for large transactions. All treasury interactions should be transparent and verifiable on-chain. Tools like Tally and Snapshot are often integrated for off-chain signaling and voter interfaces, but the final execution must always be on-chain through the governor contract to ensure tamper-proof enforcement of the community's will.

To implement a basic version, you can deploy a suite of contracts using OpenZeppelin's wizard. First, deploy an ERC-20Votes token. Then, deploy a TimelockController as your treasury executor. Finally, deploy a Governor contract (e.g., GovernorCompatibilityBravo) that uses the token for voting and the Timelock for execution. The critical step is initializing the Governor with the token and Timelock addresses and setting the Timelock to recognize the Governor as a "proposer" role. This creates a secure loop where only successful proposals can schedule transactions on the Timelock.

For advanced architectures, consider modular systems like Governor Bravo with a custom treasury module or forks like NounsDAO's executor. The future lies in gas-efficient voting with ERC-5805 (DelegationCheckpoints) and cross-chain governance via Layer 2s or dedicated chains like Arbitrum Orbit. Always audit your contracts, start with a conservative, small treasury for testing, and use a staging environment to simulate governance attacks before deploying with significant funds.

To begin, navigate to the Juicebox website and connect your wallet. Click Create a project. You'll be prompted to configure your project's first funding cycle. The key parameters you define here are: the funding target (the amount of ETH or other tokens you aim to raise), the duration (how long this cycle lasts before rules can be reconsidered), and the reserved rate (the percentage of newly minted project tokens reserved for the team or designated addresses). Setting a finite duration and target creates natural checkpoints for community governance.

A critical component is the discount rate, which determines the bonding curve for your project's tokens. A 0% discount rate means contributors always get the same amount of tokens per ETH. A positive discount rate (e.g., 10%) makes tokens cheaper for earlier contributors, incentivizing early support. Conversely, a redemption rate can be set, allowing token holders to burn their tokens to reclaim a portion of the treasury's overflow, creating an intrinsic price floor. These rates are powerful levers for designing your project's economic model.

You must also configure the payouts and reserved tokens. Payouts are pre-approved addresses and amounts that can tap into the treasury's available funds, useful for paying contributors or covering operational costs. Reserved tokens are allocated to specific addresses (like the core team) from the token minting reserve defined by the reserved rate. For example, a 20% reserved rate with a 50/50 split between the team and a community treasury wallet would automatically mint tokens to those addresses whenever new tokens are issued to contributors.

Finally, you'll review and deploy your funding cycle configuration as a DAO (a JuiceboxDAO v3 contract instance) on your chosen network, such as Ethereum Mainnet or Optimism. This deployment creates your project's unique contract address, treasury, and token (JBX for v3). All parameters are editable for future cycles, but the current cycle's rules are immutable, ensuring predictability for contributors. After deployment, your project page will go live, ready to accept contributions and distribute tokens according to the rules you've established.

Token-based governance is the mechanism by which your DAO's community exercises control over its treasury. This is typically implemented using a governance token, where voting power is proportional to the number of tokens a member holds or has delegated to them. The core contract is often a Governor contract, such as OpenZeppelin's Governor or a fork of Compound's Governor Bravo, which manages the lifecycle of proposals from creation to execution. This system transforms the treasury from a static wallet into a dynamic, community-directed resource.

The governance process follows a standard sequence: Propose, Vote, Queue, Execute. A member with sufficient token balance submits a proposal—for example, a transaction to transfer 50 ETH from the treasury to a grant recipient. The proposal enters a voting period, where token holders cast their votes. If the proposal passes a predefined quorum and majority threshold, it can be queued and then executed, automatically performing the on-chain transaction. This ensures all treasury actions are transparent and require collective consent.

Key parameters must be carefully configured to balance security with participation. These include the voting delay (time between proposal submission and voting start), voting period (duration of the vote), proposal threshold (minimum tokens needed to submit a proposal), and quorum (minimum voting power required for a proposal to be valid). For a community treasury, a lower proposal threshold encourages participation, while a significant quorum (e.g., 4% of total supply) protects against low-turnout attacks.

Integrating with a treasury management contract like a Gnosis Safe is a common pattern. The Governor contract is set as a signer on the Safe. When a proposal executes, it calls the Safe contract to perform the authorized transaction, such as safe.execTransaction(recipient, value, data). This adds a critical security layer, as the Governor itself never holds funds directly. All code should be thoroughly audited, and consider using timelock contracts to introduce a mandatory delay between a vote passing and execution, giving the community time to react to malicious proposals.

For developers, here's a basic example of initializing an OpenZeppelin Governor contract for treasury control, assuming an ERC20Votes token named CommunityToken and a TimelockController:

solidityCopy
// Token must be ERC20Votes
CommunityToken token = CommunityToken(0x...);
// Timelock contract that will hold/execute treasury transactions
TimelockController timelock = TimelockController(0x...);

// Deploy Governor contract
GovernorContract governor = new GovernorContract(
    "Community DAO Governor",
    token,
    timelock,
    7200,  // Voting delay: 1 day in blocks
    50400, // Voting period: 1 week in blocks
    1000e18, // Proposal threshold: 1000 tokens
    4      // Quorum numerator: 4%
);
// Grant the Governor the 'PROPOSER_ROLE' on the Timelock
timelock.grantRole(timelock.PROPOSER_ROLE(), address(governor));

This setup ensures all treasury actions flow through the governed, timelocked process.

Finally, frontend integration is crucial for accessibility. Use libraries like Tally, Boardroom, or build a custom interface using the Governor's ABI. The UI should allow users to view active proposals, read transaction details, connect their wallet, cast votes (for, against, abstain), and delegate voting power. Transparently displaying treasury balances, proposal history, and voter turnout builds trust and encourages active community stewardship over the shared funds.

A vesting schedule is a critical tool for responsible treasury management. It locks allocated tokens and releases them linearly over a defined period (the cliff and duration). This prevents large, sudden sell pressure, aligns long-term incentives, and builds trust by demonstrating a commitment to gradual, predictable distribution. For a community treasury, vesting is essential for grants, team compensation, and contributor rewards, moving beyond manual, multi-sig controlled payments to an automated, on-chain system.

Sablier V2 is the leading protocol for real-time finance on Ethereum and other EVM chains. Its core innovation is the Lockup Linear contract, which creates a non-transferable NFT representing a stream of tokens. The stream starts after an optional cliff period and drips tokens to the recipient at a constant rate until the end date. This is superior to traditional periodic unlocks as it provides continuous liquidity and eliminates the "unlock cliff dump" phenomenon common in vesting schedules.

To implement a vesting schedule, you'll interact with Sablier's SablierV2LockupLinear contract. The key parameters you define are: the asset (the ERC-20 token address), sender (the treasury address funding the stream), recipient, the total amount, and the range which includes the start time, optional cliff timestamp, and end time. The contract calculates the drip rate automatically. You can fund streams directly from a Gnosis Safe or other treasury multi-sig wallet.

Here is a basic example using Ethers.js to create a stream that vests 1000 project tokens over one year to a contributor, with a 3-month cliff:

javascriptCopy
const { SablierV2LockupLinear } = require('@sablier/v2-core');
const provider = new ethers.providers.JsonRpcProvider(RPC_URL);
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

const sablierContract = new ethers.Contract(
  '0x...', // SablierV2LockupLinear address on your chain
  SablierV2LockupLinear.abi,
  wallet
);

const now = Math.floor(Date.now() / 1000);
const oneYear = 365 * 24 * 60 * 60;

const tx = await sablierContract.createWithRange({
  sender: treasuryAddress,
  recipient: contributorAddress,
  totalAmount: ethers.utils.parseUnits('1000', 18),
  asset: tokenAddress,
  cancelable: false, // Makes the stream irrevocable
  transferable: false, // NFT is non-transferable
  range: {
    start: now,
    cliff: now + (90 * 24 * 60 * 60), // 3-month cliff
    end: now + oneYear
  },
  broker: ethers.constants.AddressZero // No broker fee
});

For community governance, you can integrate this creation process into a proposal system. A typical flow is: 1) A governance proposal details the recipient, amount, and vesting terms. 2) Upon passing, an approved executor (like a Safe) calls the createWithRange function. 3) The recipient receives an NFT in their wallet, which they can use to withdraw their available tokens at any time or view on a dashboard like Sablier App. This creates a fully transparent, on-chain record of the commitment and its fulfillment.

Managing these streams is straightforward. The treasury, as the sender, can cancel a stream (if created as cancelable) to reclaim unvested funds, a useful safety mechanism. Recipients can withdraw their accrued tokens anytime. For reporting, you can query the Sablier subgraph to track all active streams, amounts vested, and remaining balances. This automated approach reduces administrative overhead, eliminates manual payment errors, and provides immutable proof of fair distribution, strengthening your community's trust in the treasury management process.

A functional governance system requires a secure and transparent workflow for creating, voting on, and executing proposals. The core logic is implemented in a Governor contract, which orchestrates the interaction between your VotingToken and Treasury. This contract defines the proposal lifecycle: proposal creation, a voting period, vote tallying, and finally proposal execution. Popular frameworks like OpenZeppelin's Governor provide a modular, audited foundation, reducing development time and security risks.

The proposal lifecycle begins when a token holder submits a transaction. This transaction data—target contract, function to call, and calldata—is stored on-chain. For treasury management, a typical proposal might call the Treasury.executeTransaction function with specific parameters to transfer funds or approve a budget. The proposal enters a voting delay, allowing the community to review it, followed by a fixed voting period where token holders cast their votes based on their token balance.

Voting power is typically calculated via token snapshots or checkpoints, often implemented using the ERC20Votes extension. This prevents manipulation through token transfers during the voting period. Once voting ends, the proposal state is determined by the voting rules (e.g., simple majority, quorum). If the proposal succeeds, it moves to a timelock period, a critical security feature that gives users time to react to a passed proposal before it can be executed.

The final step is execution. After the timelock expires, any address can trigger the execute function on the Governor contract. This will relay the stored transaction data to the target Treasury contract, carrying out the approved action. It's essential to implement robust access controls and event emission at each stage for full transparency. All state changes—proposal creation, votes cast, and execution—should emit events that can be indexed by frontends and analytics tools.

For development, you can extend OpenZeppelin's Governor contract. A basic implementation involves setting the voting token, voting parameters (delay, period, quorum), and the timelock address. The treasury should be owned by the timelock contract, ensuring only successfully governed proposals can access funds. Testing this workflow end-to-end with tools like Hardhat or Foundry is non-negotiable, simulating proposal creation, voting, and execution across multiple user addresses.

This complete workflow decentralizes financial control, moving from a multi-signature wallet model to a programmatic, community-driven process. It establishes clear accountability and an immutable record of all treasury decisions. For further reading, consult the OpenZeppelin Governor documentation and review governance implementations in protocols like Uniswap or Compound.