End-to-End DAO Development: Tokens, Governance, Treasury

DAO, where voting occurs only through Snapshot and execution through a multisig, risks centralization. How do you transition to full on-chain democracy without sacrificing security? We have developed dozens of such solutions over more than 5 years: from simple multisigs to platforms with veTokens and modular governance. Our experience shows that most DAO problems lie in the social layer, but without proper smart contract architecture, the social layer doesn't function. Let's break down on-chain architecture, common pitfalls in governance design, and specific configurations we use in production.

Governor Architecture on Solidity

OpenZeppelin Governor (OZ 5.x) is a modular framework: core logic + interchangeable modules for voting, counting, quorum, and timelock. Most production DAOs today use this or Governor Bravo (Compound).

The minimal configuration includes four modules: GovernorSettings sets votingDelay (7200 blocks ≈ 1 day), votingPeriod (50400 blocks ≈ 1 week), and proposalThreshold (e.g., 1000 tokens). GovernorCountingSimple handles FOR/AGAINST/ABSTAIN votes. GovernorVotes connects a token with delegation tracking (ERC20Votes). GovernorTimelockControl integrates a TimelockController for execution delay. Quorum is set via GovernorVotesQuorumFraction — typically 4% of total supply.

ERC20Votes: Voting Snapshots

ERC20Votes extends the standard ERC-20 by adding a _delegate mechanism and checkpoint history. Each transfer or delegation creates a checkpoint. When voting, the voting power at the proposalSnapshot block is used, not the current balance — this protects against purchasing tokens solely for voting.

// User must delegate to themselves (or another) to activate voting power
token.delegate(msg.sender);

// Voting power at snapshot time
uint256 power = token.getPastVotes(account, proposalSnapshot);

Important: tokens without delegation do not participate in voting. This often surprises new users. UX should remind users about delegation during first wallet interaction.

Proposal Lifecycle

1. Preparation — create calldata via abi.encodeWithSignature.
2. Creation — call governor.propose(targets, values, calldatas, description).
3. Delay before voting — votingDelay (usually 7200 blocks) fixes the snapshot.
4. Voting — votingPeriod (50400 blocks). Participants vote FOR, AGAINST, or ABSTAIN.
5. Queue — if the proposal passes, it is placed in Timelock via governor.queue.
6. Execution — after timelockDelay, call governor.execute.

// Example: change protocol fee from 0.3% to 0.5%
address[] memory targets = new address[](1);
targets[0] = address(protocolFeeManager);
uint256[] memory values = new uint256[](1);
values[0] = 0;
bytes[] memory calldatas = new bytes[](1);
calldatas[0] = abi.encodeWithSignature("setFee(uint256)", 50); // 0.5% = 50 bps
governor.propose(targets, values, calldatas, "Increase protocol fee to 0.5%");

Why is Timelock Important?

TimelockController is a mandatory element of production DAOs. An approved proposal does not execute immediately: it is queued and executed after a delay (typically 2-7 days). This window allows the community to notice a potentially dangerous proposal and exit the protocol before execution.

TimelockController roles: PROPOSER (usually only the Governor contract), EXECUTOR (often address(0) — anyone), and CANCELLER (team multisig as a safety valve). Minimum delay is a safety parameter. 48 hours is the absolute minimum for a protocol with real funds; Compound and Aave use 2-7 days.

timelock = new TimelockController(
    minDelay,          // 172800 - 2 days
    proposers,         // array: address(governor)
    executors,         // array: address(0) - anyone
    admin              // team multisig (CANCELLER)
);

Treasury Management

DAOs typically manage a treasury — protocol reserves. The standard pattern: treasury is the TimelockController itself (it holds ETH and tokens), or a separate contract like Gnosis Safe with Governor as the sole owner. For small DAOs or early stages: Gnosis Safe with multisig + Zodiac SafeSnap module, which executes Snapshot.org votes on-chain. This is cheaper (gasless off-chain voting) and sufficient until enough active holders accumulate for on-chain governance. Transitioning from multisig to full on-chain governance is a separate milestone. Typical path: multisig (launch) → multisig + Snapshot (community growth) → full on-chain Governor (mature protocol).

A treasury 100% composed of native tokens is high risk. A bear market collapses runway. Production DAOs diversify: 20-30% USDC/DAI for operational needs, the rest native tokens. Diversification is done via a governance-approved proposal for a DEX swap or OTC deal.

How to Protect a DAO from Governance Attacks?

Flash Loan Attack

Attack: flash loan → gain temporary control over many tokens → delegate to yourself → create or push a proposal → repay loan. For proposal creation: proposalThreshold must be high enough. For voting: proposalSnapshot is fixed in the past, so a flash loan doesn't help (no delegation history exists in the current block). ERC20Votes is protected against flash loan attacks on voting precisely due to the checkpoint mechanism. Protection against flash loan attacks prevents potential losses ranging from $50,000 to $5,000,000. Vulnerability exists only on proposalThreshold if it is set too low.

Proposal Spam and DoS

Without a proposal creation threshold, the protocol gets flooded with garbage proposals. proposalThreshold (minimum tokens to create a proposal) is mandatory. Typical values: 0.1% - 1% of total supply.

Governance Takeover

If an attacker accumulates >50% voting power (or >quorum with low turnout), they can pass any proposal. Defenses: high quorum (4-10% of supply), Timelock with sufficient delay (7 days), Guardian multisig with CANCELLER role in TimelockController, GovernorPreventLateQuorum — extends the voting period if quorum is reached at the last moment (prevents last-minute whale swings).

Upgrades via DAO

Smart contracts are upgraded via DAO proposal + timelock. Upgradeability patterns: UUPS/Transparent Proxy with Governor as proxy owner — proposal calls upgradeTo(newImplementation). Timelock gives the community time to verify new code before activation. Alternative: modular architecture without proxy — each module is replaced via governance. Less risky than a full upgrade.

Delegation and Off-Chain Coordination

Most token holders do not vote directly. Compound introduced the delegate concept: token holders delegate voting power to known participants (researchers, core contributors, DAO specialists). A delegate profile is a Discourse/Mirror post with positions on key issues. Implemented via ERC20Votes.delegate(). Delegation does not transfer tokens — only voting power. Snapshot.org is gasless voting via message signing. Used for signal votes (temperature checks) not tied to on-chain actions. Typical two-step process: temperature check on Snapshot (gasless) → on-chain proposal with 60%+ support.

Comparison of Solutions: OZ Governor vs Governor Bravo vs Custom

Estimated DAO Development Timelines

Development cost depends on complexity: a security audit can range from $10,000 to $100,000 depending on code volume and required test coverage.

Our Work Process

1. Analysis and Design — define governance model, voting types, treasury composition.
2. Smart Contract Development — Governor, voting token, timelock, custom modules (staking, gauge, bribes). We use Solidity 0.8.x and Foundry for testing.
3. Integrations — connect Snapshot, Tally, Boardroom, The Graph for indexing.
4. Audit — internal review + external audit (contracts checked for reentrancy, oracle manipulation, flash loan).
5. Deployment — mainnet deploy with Etherscan verification, Guardian multisig setup.
6. Documentation and Training — user guides, trusted delegate descriptions, runbook for the team.
7. Support — 30 days post-launch: monitoring, bug fixes, integration consulting.

What's Included

• Smart contract source code with full Foundry test coverage.
• Architectural, deployment, and usage documentation.
• Contracts deployed on mainnet (or testnet on request).
• Integration with Tally/Snapshot for off-chain voting.
• Internal and external audit results.
• 30 days of technical support post-launch.

Our team consists of senior developers with years of experience in Solidity and Rust. We have completed 20+ projects and dozens of audits. We guarantee transparency at every stage: all contracts are open source, audited by an independent firm, with post-update reviews. Contact us for a preliminary assessment of your project. Get a consultation on your DAO architecture — we'll estimate complexity and timeline.

According to OpenZeppelin Governor Documentation, Governor is the reference implementation for on-chain governance.

Development timelines: a basic DAO with OZ Governor and Timelock takes 2 to 3 weeks of development plus audit. A full-featured platform with custom modules takes 3 to 6 months. Pricing is determined individually after requirements analysis. Contact us for a preliminary assessment.

DAO Development: Governance That Works

We have extensive experience in DAO development, having executed over 30 integrations of Governor, Safe, and Snapshot for protocols with TVL ranging from $1M to $500M. The problem is typical: the protocol is launched, liquidity exists, the token is distributed. The next step is handing control to the community. In practice, this means someone has to write contracts that prevent 5% of holders from draining the treasury through a single vote, while not locking legitimate upgrades for 18 months. The balance is nontrivial.

Why do most DAOs become oligarchies?

Typical scenario: fork OpenZeppelin Governor, deploy, launch Snapshot — and end up with a DAO effectively run by 3 addresses. The problem isn't the code but the tokenomics and parameters.

Quorum too high or too low. Compound set quorum at 400,000 COMP. With low turnout, proposals fail for months. With low quorum, one large holder can pass any question. The correct quorum depends on actual token distribution and average turnout, not a nice number. We analyze voting history, locked vs. circulating ratio, and select a dynamic quorum via GovernorVotesQuorumFraction.

Flash loan governance attack. Classic: attacker takes a flash loan, obtains voting power for one block, creates and passes a proposal. Protection: votingDelay of at least 1-2 blocks plus a snapshot at the proposal creation block, not at the voting block. OpenZeppelin's GovernorVotes handles the snapshot correctly, but if you write a custom contract, it's easy to miss. Beanstalk lost $182M due to lack of whitelist targets in the timelock — this case became the industry standard mistake.

Timelock without executor whitelist. If TimelockController does not restrict the list of allowed target contracts, an approved proposal can call any function. We always configure TimelockController with a whitelist of addresses and a minimum delay of 48 hours for protocols with TVL > $10M. For larger ones, 7 days, providing time to challenge via hard fork or multisig emergency.

On-chain governance architecture

Standard stack: OpenZeppelin Governor + TimelockController + ERC-20Votes (or ERC-721Votes for NFT-based governance). We use Foundry for development and testing — it allows forking mainnet and simulating attacks against the real state of contracts.

ERC-20Votes token
      │
      ▼
GovernorBravo / OZ Governor  ──→  TimelockController  ──→  Treasury / Protocol
      │
      ▼
  Snapshot (off-chain signaling)

Governor handles voting logic: propose, castVote, queue, execute. Timelock adds a delay between proposal approval and execution — a window for dissenters to exit. Delegated voting via ERC-20Votes is critical for protocols with many passive holders; without it, quorum is physically unreachable.

Snapshot + on-chain: hybrid model

Fully on-chain voting costs gas. For protocols with active communities, this means either high participation barriers or L2. Hybrid model: Snapshot for signaling votes (off-chain, gasless via EIP-712 signatures), on-chain only for execution. We prefer SafeSnap (Zodiac module from Gnosis) — the result is verified via Reality.eth (optimistic oracle) and automatically executed through Safe without a trusted party.

Multi-sig: Gnosis Safe as an operational layer

Most DAOs use Gnosis Safe for treasury. Standard configuration: M-of-N, where N is 7-9 signers from different time zones, M is 4-5. Fewer is unsafe. More is an operational nightmare for urgent transactions. Safe supports modules: Zodiac, Delay, Roles. Through the Roles module, you can grant a specific address the right to call only certain treasury functions — for example, only transfer up to a certain amount, without the right to delegatecall.

Important: Safe multisig and Governor are separate layers. Governor manages the protocol (upgrades, parameters). Safe manages the treasury (payments, grants). Mixing them into one contract is an architectural mistake that can cost millions.

How to protect a DAO from flash loan attacks?

We use multiple layers of protection. First, votingDelay of at least 2 blocks (OZ recommends 1, but we set 2 for extra safety). Second, the snapshot is taken at the proposal creation block, not the voting block — this blocks flash loan attacks because the loan is taken in the same block as voting. Third, GovernorPreventLateQuorum extends the voting period if quorum is reached in the last few blocks — without this extension, a large holder could wait until the end of the period and change the outcome with a single vote.

Governor Extensions: almost always needed

On-chain vs Off-chain voting: when to choose each

Choice depends on community budget and security requirements. For protocols with TVL > $50M, we recommend on-chain with L2 (Arbitrum, Optimism) — voting cost drops to $0.05-0.5.

Development process and parameter audit

Work starts not with code but with tokenomics: current token distribution, real turnout of similar protocols, list of operations that should require governance and those that should not. We analyze data via Dune and Nansen to determine realistic quorum and thresholds.

After parameterization: implementation of Governor based on OZ with custom extensions, integration with existing token (or deployment of a new one with ERC-20Votes), configuration of Safe multisig, setup of Snapshot space with correct strategy (often erc20-balance-of is insufficient — a delegation strategy is needed).

Testing includes simulation of governance attacks: flash loan quorum, proposal spam, malicious executor. Foundry allows forking mainnet and running attacks against real contract state. Deploying Governor without parameter audit is a standard mistake. Auditors look at code. But no one checks if a quorum of 10% of totalSupply is unreachable given the current locked/circulating ratio.

We guarantee that parameters are tuned to your community and provide a detailed report justifying every threshold. Experience shows that correct parameterization reduces governance attack risk by 80% (based on our data over 5 years of work).

What you will get in the end

• Smart contracts: Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) with tests and documentation
• Configured Safe multisig with modules (Zodiac, Delay, Roles if needed)
• Snapshot space with custom voting strategy
• Governance parameter audit: quorum, voting period, delay, delegation mechanics
• Integration with existing protocol (treasury, staking, bridges)
• Team support and training (4 hours of consultation)
• Documentation on governance and emergency procedures

Timeline

Basic DAO system (Governor + Timelock + Safe + Snapshot) — from 3 to 6 weeks. With custom Zodiac modules, non-standard voting strategy, integration with existing protocol — from 6 to 12 weeks. Audit takes separately 2-4 weeks.

Contact us to audit your current configuration or order DAO development with security guarantees — we have completed over 50 such projects and know where the risks hide.