Getting started
A governance proposal template that leads to execution
Good proposals read like specifications. Use the same structure every time so voters know where to look.
The structure
Title, one-line summary, motivation, specification, exact transaction (chain, target, calldata, value), risks, and execution parameters.
Write the transaction first
If you cannot encode the call, the proposal is not ready for a vote.
State the parameters explicitly
Quorum, threshold, timelock and required signatures belong in the proposal, not in tribal knowledge.
What every proposal should contain
A one paragraph summary anyone can read, the motivation, the exact change including target contract and encoded call, the expected impact, the risks, the reversal plan and the metric that will judge success. Anything missing becomes a question during voting, which costs turnout.
Put the payload near the top rather than in an appendix. The transaction is what is being approved, so hiding it below a thousand words of rationale inverts the priority.
Reviewing before publishing
Have one person who did not write the proposal decode the calldata and confirm it matches the summary. This single step catches both honest mistakes and deliberate substitution.
Keep a standing checklist and require it to be completed in the proposal itself. Checklists are unglamorous and they are the reason experienced organisations make fewer expensive errors.
Keep the execution path connected: this guide pairs well with defi governance, nft dao governance and rollup governance, which cover the neighbouring steps between an approved vote and a settled onchain transaction.
Key concepts explained
New to this topic? These are the core terms you will meet again and again in governance work. Understanding them makes every proposal easier to read.
- Executable payload section
- The part of a proposal containing the exact target, calldata and value. A proposal without it is a wish; a proposal with it is an instruction.
- Specification
- The plain-language description of what the payload does and why. It must match the calldata exactly - mismatches are how bad proposals slip through.
- Simulation
- A dry run of the payload against a forked chain state, proving the transaction does what the specification claims before anyone votes.
- Temperature check
- A lightweight offchain poll before drafting a full proposal. It saves authors from formalizing ideas the community will reject.
Frequently asked questions
- What should a governance proposal include?
- A plain summary, motivation, the exact onchain action with target and calldata, expected impact, risks, a reversal plan and the success metric.
- How long should a proposal be?
- Long enough to justify the change and no longer. A readable summary plus a precise specification beats a lengthy essay that hides the actual action.
- Who reviews proposals before a vote?
- Ideally a reviewer independent of the author, plus any risk or security group the organisation has appointed, so the payload is verified by someone who did not write it.