Build a DAO that makes decisions, not just holds votes.

Most DAOs fail not because of voter apathy — but because governance was an afterthought to the token launch.

DAO governance that controls nothing meaningful gets ignored. DAO governance with no quorum requirements gets captured by a small group of motivated actors. DAO governance with no timelock gets front-run by insiders who know what proposals will pass. DAO governance where the founding team still holds enough tokens to pass any proposal unilaterally is not decentralised — it is a liability shield. PROPELOO designs DAO systems where governance power is proportional to long-term commitment, where meaningful decisions are subject to community control, where proposals cannot be executed instantaneously even after they pass, and where the governance process is transparent enough that any token holder can participate without a law degree.

The full DAO engineering stack.

A production DAO is a governance token, a voting mechanism, a treasury system, a proposal execution engine and a participation layer.

System Layers

• Governance Token Layer: Token with voting power, delegation, snapshot and checkpointing
• Proposal & Voting Layer: Proposal creation, voting period, quorum, threshold, vote counting
• Timelock & Execution Layer: Proposal execution delay, multi-sig override, cancellation mechanism
• Treasury Layer: On-chain treasury, spending limits, multi-sig, grant distribution
• Participation Layer: Delegation UI, Snapshot integration, Tally interface, notification system

Core Technical Capabilities

• Governor Contract

  OpenZeppelin Governor with configurable voting delay, voting period, quorum numerator, proposal threshold, timelock delay and vote counting strategy (simple, bravo, or fractional).

• Governance Token

  ERC-20Votes token with checkpointed balance history for snapshot-based voting, delegation (delegate voting power without transferring tokens), and nonces for permit-based gasless delegation.

• Treasury Management

  Timelock-controlled on-chain treasury, spending limit governance, grant distribution contracts, multi-sig backup for emergency decisions, and budget allocation by workstream.

• Delegation System

  Liquid delegation allowing token holders to delegate voting power to representatives. Meta-delegation (re-delegation). Delegation tracking and public delegate profiles. Gasless delegation via EIP-712 signatures.

• Snapshot Integration

  Off-chain Snapshot.org voting for lower-stakes decisions, temperature checks and signal polls. On-chain execution for decisions that require treasury access or protocol parameter changes.

• Governance Analytics

  The Graph subgraph for proposal history, voting participation, delegation network and treasury transactions. Tally, Boardroom or custom governance dashboard integration.

How we think about DAO design.

A DAO is a political system encoded as smart contracts. The same failure modes that affect political systems — voter apathy, plutocracy, capture by motivated minorities — apply to DAOs. Design for the failure modes.

• Governance must control something valuable

  Token holders participate in governance when their votes affect outcomes they care about: treasury allocation, protocol fee parameters, emission schedules, integration decisions, hiring. Governance over a protocol with $0 treasury and no fees does not motivate participation. Design governance scope around the decisions that actually matter to stakeholders.

  Axiom:

• Timelock is a security feature, not bureaucracy

  A 48-hour timelock between proposal passage and execution gives the community time to detect and respond to malicious proposals — ones that passed because the attacker had enough voting power or because quorum was low. Flash loan governance attacks work without timelocks. Emergency pause mechanisms can still respond in minutes; the timelock applies to parameter changes and treasury spending, not emergency functions.

  Axiom:

• Low quorum creates capture risk

  A governance system with 5% quorum can be captured by any actor holding 3% of the token supply who is willing to vote when others are not. Quorum should be calibrated to the actual participation rate — if 10% of tokens regularly vote, set quorum at 5-8%. If participation is lower, consider delegation-first models where token holders delegate to active representatives rather than voting directly.

  Axiom:

• Progressive decentralisation is honest

  Launching a protocol with a founding team multi-sig and calling it a DAO is a credibility risk. Progressive decentralisation — explicit, documented milestones for transferring control from founding team to community governance — is more honest and more achievable. Define the decentralisation milestones before launch: when will the treasury transfer to Governor control? When will the protocol owner role transfer to the timelock?

  Axiom:

The governance design decisions that matter.

These choices define who has power in your DAO and how that power can be used.

• On-chain voting vs Snapshot?

  Impact: Hybrid model is the production standard: Snapshot for community signal and temperature checks (gasless), on-chain Governor for binding decisions that trigger treasury or parameter changes. Full on-chain voting creates a participation barrier when gas is expensive.

  • Full on-chain — trustless, gas expensive for voters, binding execution
  • Snapshot only — gasless, off-chain, requires multisig to execute results
  • Hybrid (Snapshot signal + on-chain execution) — gasless voting, trustless execution
  • Optimistic governance — proposals pass unless challenged within a window

• Governor framework?

  Impact: OpenZeppelin Governor is the correct default — it is audited, modular (swap out vote counting, quorum logic), integrates with standard ERC-20Votes tokens and has the largest ecosystem of tooling (Tally, Boardroom). Custom governance adds audit risk without proportional benefit for most use cases.

  • OpenZeppelin Governor — audited, modular, widely used, requires timelock
  • Compound Governor Bravo — battle-tested, less flexible than OZ
  • Aragon OSx — full framework, opinionated, plugin architecture
  • Custom governance — maximum flexibility, full audit responsibility

• Voting period and timelock?

  Impact: 5-day voting + 48h timelock is the market standard for protocol governance. Shorter timelines reduce community review time. Tiered timelines by decision size are more sophisticated and increasingly common for mature protocols.

  • 3-day voting + 24h timelock — fast, minimal protection
  • 5-day voting + 48h timelock — standard, minimum for significant treasury decisions
  • 7-day voting + 72h timelock — conservative, appropriate for protocol-critical changes
  • Tiered by proposal type — fast track for minor, standard for major, long for critical

• Quorum and proposal threshold?

  Impact: Calibrate quorum to realistic participation rates. If 5% of tokens vote regularly, 4% quorum is achievable. If 1% votes regularly, 4% quorum means nothing ever passes without whale coordination. Adaptive quorum is the most honest approach.

  • 1% quorum, 0.1% threshold — very accessible, high capture risk
  • 4% quorum, 1% threshold — standard for protocols with broad distribution
  • 10% quorum, 2% threshold — conservative, may have participation problems
  • Adaptive quorum (adjusts based on participation history) — sophisticated, most accurate

• Treasury structure?

  Impact: Pure Governor control for a treasury with operational expenses means constant proposal overhead. Workstream budgets with quarterly governance review is the practical model for DAOs with regular operational spend.

  • Full Governor control — maximum decentralisation, every spend requires proposal
  • Governor + multi-sig with spending limits — governance for large allocations, multi-sig for operations
  • Workstream budgets — quarterly budget proposals per workstream, operational autonomy within budget
  • Foundation + DAO hybrid — legal foundation for operational liability, DAO for protocol governance

• Delegation model?

  Impact: Liquid delegation dramatically improves governance participation — most token holders will not vote directly but will delegate to representatives they trust. Building a delegate ecosystem (delegate profiles, voting history visibility) is as important as the delegation contract.

  • No delegation — every holder votes directly, low participation
  • Liquid delegation — delegate to any address, revocable at any time
  • Representative delegation — delegate to approved delegate list
  • Meta-governance — protocol votes as a block in other governance systems

What PROPELOO builds.

• Protocol DAO

  Full governance system for a DeFi protocol — Governor contract, governance token with delegation, timelock, treasury management and Tally/Snapshot integration.

• Investment DAO

  DAO for collective investment decisions — proposal and voting for investments, multi-sig treasury, member management, profit distribution and capital call mechanics.

• Grant DAO

  Grants committee DAO — proposal submission, committee voting, milestone-based disbursement, grantee reporting and treasury allocation governance.

• NFT Collector DAO

  Fractional NFT ownership via DAO — collective bidding and purchasing, fractional ownership tokens, voting on acquisition and disposal decisions.

• Contributor DAO

  Contributor coordination DAO — workstream structure, contributor NFT/token for membership, compensation proposals, reputation system and governance participation tracking.

• Governance Upgrade

  Migrate from multi-sig to full DAO governance — progressive decentralisation roadmap, timelock setup, Governor deployment, token delegation bootstrapping and community onboarding.

The DAO engineering stack.

Governance contracts, treasury management and participation tooling each require specific components.

• Governance Contracts

  Stack: OpenZeppelin Governor, Compound Governor Bravo, ERC-20Votes, TimelockController, Gnosis Safe

• Frameworks

  Stack: Aragon OSx, Colony, Moloch v3 (Baal), Orca Protocol

• Off-chain Voting

  Stack: Snapshot.org, Discourse (forum), Commonwealth, Boardroom

• Frontend & Analytics

  Stack: Tally, Boardroom, The Graph (governance subgraph), Dune Analytics

• Treasury

  Stack: Gnosis Safe, Llama (treasury management), Coordinape (contributor rewards), Superfluid (streaming payments)

• Dev Tools

  Stack: Foundry, OpenZeppelin Defender, Hardhat, Slither

DAO security protects the protocol and its treasury.

Governance systems introduce attack vectors specific to on-chain voting and treasury management.

• Governance Capture

  An attacker with sufficient voting power can pass malicious proposals. Mitigations: quorum requirements that prevent minority capture, timelock delays giving community time to respond, proposal threshold that requires meaningful stake to submit proposals, and snapshot-based voting power that prevents flash loan attacks.

• Flash Loan Governance Attacks

  Without snapshot-based voting, an attacker can borrow tokens to pass a proposal in the same block. ERC-20Votes checkpointing measures voting power at the block before the proposal was created, making flash loan attacks on governance impossible.

• Timelock Bypass

  The timelock controller must only be callable by the Governor for queued proposals. Direct calls to the timelock executor must be access-controlled. The timelock delay must be enforced for all proposal types — there must be no fast-path execution for "urgent" proposals outside the governance process.

• Treasury Draining Proposals

  Malicious proposals that transfer all treasury funds to an attacker-controlled address. Detection: governance dashboards that alert on unusual treasury movement proposals, community monitoring, minimum proposal review period and off-chain social consensus before on-chain execution for large treasury decisions.

• Delegation Phishing

  Attackers create delegate profiles to accumulate delegated voting power, then vote against community interests or submit malicious proposals when they have enough power. Delegate voting history visibility, revocable delegation and minimum reputation requirements for delegate listing are mitigation mechanisms.

• Proposal Spam

  Low proposal threshold enables spam proposals that waste governance attention and potentially hide malicious proposals in noise. Proposal threshold calibrated to 0.5-2% of circulating supply, proposal deposit with refund on passing, and Snapshot temperature check before on-chain proposal submission are standard filters.

From token launch to functional DAO.

1. 01. Governance Design

   Define governance scope, voting parameters, quorum, timelock, delegation model and progressive decentralisation milestones.

2. 02. Token & Voting Infrastructure

   ERC-20Votes token deployment, delegation setup, voting power checkpointing and gasless delegation.

3. 03. Governor & Timelock

   OpenZeppelin Governor deployment with configured parameters, TimelockController and multi-sig backup for emergency.

4. 04. Treasury Setup

   Treasury transfer to timelock control, spending limit configuration, workstream budget structure and multi-sig for operations.

5. 05. Off-chain Layer

   Snapshot.org space setup, Discourse forum, governance process documentation and proposal template.

6. 06. Tooling Integration

   Tally or Boardroom integration, The Graph governance subgraph, delegation leaderboard and participation analytics.

7. 07. Community Bootstrapping

   Delegate onboarding, first governance proposals, community education and ongoing governance process support.

Frequently Asked Questions