What this prompt does
This prompt builds a DAO governance system that is both safe and usable. You set the [dao_purpose], [member_count], [treasury_value], and [governance_scope], and it implements a governance token with [vote_weight_model], a Governor contract on [governor_base] with configured [voting_delay], [voting_period], [proposal_threshold], and [quorum_requirement], a proposal lifecycle, a timelock, delegation, treasury management, and attack mitigations.
The structure works because governance has to defend itself while staying approachable. The timelock with [timelock_delay] (and [extended_delay] for [critical_operations]), vote checkpointing at proposal creation, and guardian veto are the guardrails that stop flash-loan voting and rushed malicious proposals. By also specifying [proposal_types] with calldata encoding, delegation including [split_delegation], treasury [spending_limits] without a full vote, and off-chain [offchain_tool] temperature checks, the prompt produces a system matched to a DAO's real scope. The [member_count] and [treasury_value] inputs calibrate the thresholds, since a small DAO and one controlling millions need very different quorum and proposal bars.
When to use it
- You are building DAO governance and need both safety guardrails and a usable flow
- You want an OpenZeppelin Governor configured to your real treasury and scope
- You need a timelock with extended delay for
[critical_operations] - You want delegation, including
[split_delegation], with vote checkpointing - You need treasury
[spending_limits]that avoid a full vote for small grants - You want a clear proposal lifecycle with on-chain calldata execution
- You want explicit mitigations for
[governance_attacks]like flash-loan voting
Example output
Expect a governance system design: a token with the ERC20Votes extension and [vote_weight_model], a Governor on [governor_base] with [voting_delay], [voting_period], [proposal_threshold], and [quorum_requirement] configured, a proposal lifecycle from create through execute supporting [proposal_types] with [metadata_standard] metadata, a timelock controller with [timelock_delay] and [extended_delay] for [critical_operations] plus proposer/executor/canceller roles, a delegation system with [split_delegation] and snapshot tracking, treasury operations through the timelock with [spending_limits], off-chain [offchain_tool] integration, and mitigations for [governance_attacks]. The role separation across proposer, executor, and canceller is spelled out so no single party can both queue and rush an execution.
Pro tips
- Match the Governor config to your real DAO —
[proposal_threshold]and[quorum_requirement]set too low invite capture, too high cause governance paralysis - Keep vote checkpointing at proposal creation; without it, flash-loan voting where attackers borrow tokens to swing a vote becomes possible
- Use
[extended_delay]for[critical_operations]like upgrades and large treasury transfers, so the community has time to react to anything dangerous - Define
[spending_limits]so routine small grants do not need a full vote, but anything large goes through the timelock and full process - Set
[voting_delay]long enough that holders can delegate before the snapshot, or late delegators are silently disenfranchised - Configure the guardian veto and
[critical_operations]list before launch, since a guardian role added after an attack starts is too late - Wire
[offchain_tool]temperature checks in front of on-chain proposals to filter noise before anything reaches a binding, gas-costing vote
