Problem Statement: A Governance System Spanning Discussion, Voting, and Binding Execution
Frames a DAO governance platform as four coupled planes: deliberation, voting, execution, and treasury custody.
Problem statement
Design a governance platform where token holders propose protocol changes or treasury spending, discuss them on a governance forum, vote through gasless off-chain signaling or on-chain weighted ballots, and — when a proposal passes — move real assets or upgrade contracts through a timelocked, vetoable execution path. The system must support delegation of voting power, quorum and threshold logic, and multi-signature execution for treasury operations.
This is not a polling website. A passed proposal can transfer millions of dollars from a treasury or upgrade the contract that mints the token. Therefore the design separates four planes that fail differently: the deliberation plane (forum threads, comments, temperature checks), the voting plane (signature ballots, on-chain ballots, voting-power snapshots, tallies), the execution plane (timelock, guardians, executors, Safe multisigs), and the custody plane (treasury accounts, allowances, module permissions). A forum outage must never block an already-queued execution; an indexer lag must never change a finalized tally; a compromised relayer must never fabricate a vote.
Real systems prove the shape. Compound's Governor Bravo runs a 3-day vote requiring at least 400,000 COMP in favor, then queues the result in a Timelock executable 2 days later. MakerDAO splits signaling polls from executive votes that lock MKR in a Chief contract and deploy timed "spell" bundles. Snapshot stores every space, proposal, and vote on IPFS so gasless voting stays publicly auditable. Our platform generalizes these patterns into one multi-tenant service that hosts many DAO spaces while keeping each space's rules — quorum fraction, voting period, threshold, executor set — as versioned configuration.
Why the problem is distinctive
Three properties separate governance from ordinary web systems. First, voting power is historical: a ballot must be weighted by the balance at the proposal's snapshot block, not at vote time, or flash loans and last-minute transfers decide outcomes. Second, the write path is cryptographic: votes arrive as EIP-712 signatures or chain transactions, so verification, replay protection, and wallet-type handling (EOA versus ERC-1271 contract wallets) are core API concerns. Third, the output is irreversible money movement, so execution needs delays, vetoes, simulation, and multisig custody rather than a direct side effect.
Public baseline versus design assumptions
Cited figures above are published protocol parameters, not our targets. For capacity planning this answer explicitly assumes a mature multi-tenant platform: 300,000 token-holder addresses across hosted spaces, 45,000 addresses holding delegated voting power, 8,000 monthly active voters, 60 new proposals per month, and a deadline-correlated vote spike. Every uncited number in this answer is a stated assumption, budget, or target.
Key Highlights
- •Four planes with different failure modes: deliberation, voting, execution, custody.
- •Voting power is read at a historical snapshot block, never at vote submission time.
- •Votes are signatures or chain transactions; verification and replay protection are API-core.
- •Compound Bravo parameters are real: 3-day vote, 400,000 COMP quorum, 2-day timelock.
- •Passed proposals move real treasury assets, so execution is delayed, vetoable, and simulated.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate discussion, voting, execution, and custody before choosing any technology."
- "The defining constraint is that a passed proposal moves real assets, so execution must be delayed and vetoable."