A risk team wants to lower a collateral limit after volatility rises, while users warn that a rushed change could trigger liquidations. The proposer must define the problem, quantify tradeoffs, encode the exact parameter change, and specify how the result will be monitored. A protocol proposal turns a desired change into a decision that people and software can evaluate; the visible vote is only one stage between discovery and verified implementation.
Strong proposal processes reduce ambiguity before power is exercised. They identify the problem, evidence, alternatives, affected stakeholders, implementation owner, measurable outcomes, risks, rollback options, and exact authority requested. Process should scale with consequence: a small community event does not need the same review as an irreversible treasury transfer or upgrade controlling user assets.
What you will learn
- Map a proposal lifecycle from informal discussion to post-execution review
- Distinguish policy intent, technical specification, and executable payload
- Assess proposal quality using evidence, ownership, risk, and measurable outcomes
Discovery defines the problem before the solution
Early forum discussion should establish what problem exists, who experiences it, and which evidence supports intervention. Temperature checks can reveal whether the issue deserves further work without treating an informal poll as final authorization. This stage should invite competing explanations and alternatives, because proposers often arrive with a preferred mechanism before validating the underlying need.
Agenda access shapes results. Submission thresholds, required templates, moderation, language, and meeting schedules can exclude participants even when voting is open. Healthy processes publish requirements, provide reasonable feedback, and distinguish rejection for incompleteness from disagreement on policy. They also prevent endless resubmission or spam from consuming all reviewer and voter attention.
Review should be independent and proportional
Risk reviewers examine technical safety, economic incentives, treasury exposure, operational capacity, and legal uncertainty where relevant. A proposer should answer criticism, but reviewers need independence from the team seeking funds or authority. Material conflicts should be disclosed. For complex changes, separate reviewers can cover code, mechanism design, market effects, and implementation readiness rather than expecting one delegate to master every domain.
Process gates should match downside. Routine bounded grants may use committee review and a short delay, while upgrades or large transfers may need audits, simulations, supermajority approval, and longer notice. Excessive ceremony can privilege insiders who navigate it professionally. The aim is evidence proportionate to consequence, with expedited paths defined in advance for genuine emergencies.
Execution begins a new evidence cycle
After passage, a proposal may be queued in a timelock, executed by any caller, or implemented by signers and contributors. Monitoring should confirm that the intended transaction occurred, systems remained healthy, and recipients delivered agreed work. Dashboards and status updates should link the approved proposal to transaction hashes, releases, payments, and outcome metrics.
A retrospective asks whether assumptions held and what the process should learn. It should not redefine success after results are known. Failed experiments can still be informative when scope was bounded and reporting candid; apparently successful activity can conceal poor cost effectiveness. Governance improves when completed proposals create structured evidence for future decisions instead of disappearing after the vote.
Common misconceptions
“Posting an idea in a governance forum changes the protocol.”
Discussion can shape consensus, but formal authorization, executable details, and implementation are separate stages with their own requirements.
“Once a proposal passes, governance work is complete.”
Execution, transaction verification, delivery monitoring, outcome measurement, and retrospective analysis determine whether the approved intervention actually worked.
Risks and limitations
- Vague specifications can grant broad discretion to implementers that voters did not knowingly authorize.
- Bundled proposals can force voters to accept a harmful action to obtain a popular or necessary change.
- A process with high deposits and technical complexity can exclude challengers while appearing formally open.
- Missing post-execution review allows failed grants, unsafe parameters, and inaccurate assumptions to persist without learning.
Key takeaways
- Define the problem and evidence before selecting a governance intervention.
- Align forum text, technical specification, and executable transaction exactly.
- Scale review, delay, and approval thresholds to consequence and reversibility.
- Name implementation owners, dependencies, milestones, and rollback constraints.
- Link final execution and measured outcomes back to the approved proposal.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.