Governance research: follow a proposal into execution
A governance proposal matters to research only after its actual state is established. Discussion, voting, approval, queueing, execution, and implementation are different events. Trace the proposal through those stages before saying that a protocol changed its rules. A successful vote may still leave execution conditions unmet.
OpenZeppelin’s governance reference describes governance contracts and state transitions. It provides a vocabulary for investigation, not proof that a particular protocol uses every component. Read the deployed configuration and proposal-specific records rather than assuming the library’s possible behavior is the project’s actual behavior.
Turn the headline into a state machine
Begin with the proposal identifier and its authoritative venue. A forum discussion may summarize an idea without constituting a binding proposal. Save the proposal text, version, linked code or transaction payload, voting period, and the rule that determines success. If the text changes, record which version voters actually considered.
Then inspect how voting power is measured. Distinguish the balance observation point, delegation, participation, and approval threshold. A large percentage of votes cast in favor is not the same denominator as a large percentage of all eligible voting power. State both quantities when available instead of allowing a favorable percentage to imply broad participation.
| Stage | Verification question |
|---|---|
| Discussion | Is there a formal proposal or only an idea? |
| Voting | Which identifier, snapshot, and eligibility rules apply? |
| Approved | Were all required conditions satisfied? |
| Queued | What delay or remaining condition applies? |
| Executed | Which successful transaction applied the payload? |
| Effective | Does the relevant deployed state reflect the change? |
Do not invent universal delays or thresholds. Those are deployment-specific parameters that require direct evidence.
Hypothetical approved but unchanged proposal
Assume a fictional protocol votes to change a treasury spending limit from 100 units to 80 units. The vote passes under the applicable rules, but execution requires a separate queued action. At the research cutoff, the queue transaction exists and the execution transaction does not. The accurate statement is that the change was approved and queued, while the effective limit remains unverified or unchanged according to the observed state.
Now suppose execution occurs later, but the payload modifies a different contract than the headline suggests. Inspect the target address and relevant state before concluding that the intended treasury limit changed. A successful transaction receipt proves execution succeeded at a technical level; the economic meaning still depends on the payload and target.
This hypothetical example is not a governance recommendation. It illustrates why a research note should retain both the human description and the machine-action details, with separate evidence for each.
Match intention with actual permissions
Read who can execute, cancel, veto, pause, or upgrade the relevant component. A token vote may coexist with other administrative authority. Map those powers explicitly rather than describing the entire system as controlled by one voting process. When permissions are unclear, mark the boundary of the analysis.
Compare the final payload with the proposal language. Identify changed parameters, recipients, affected networks, and any prerequisite transaction. For a multi-action proposal, confirm each material action rather than checking only one favorable component. Preserve the effective block so that a later researcher can reproduce the state.
Write the result as a timeline with an evidence link for each transition. A later cancellation or replacement belongs in that timeline. Historical approval is still a fact, but it should not be reported as the current policy after a different action supersedes it.
Limits and common mistakes
Some governance occurs offchain or relies on discretionary implementation. In those cases, a formal vote may be evidence of preference rather than an automatically enforceable change. The method cannot establish broader community legitimacy, beneficial ownership of voting power, or future voter behavior. Keep these questions separate from the execution trace.
Common mistakes include equating forum support with approval, quoting a vote percentage without its denominator, treating approval as execution, and assuming every successful payload implemented the headline intention. The final note should identify the last verified state and the exact event needed to move beyond it.
FAQ
Can a passed vote be described as a protocol change?
Only if the applicable process makes it effective or subsequent evidence confirms implementation. Otherwise identify the approved, queued, or pending state.
Is an execution transaction the end of the investigation?
It is a critical step. Also confirm the target, payload, and resulting state relevant to the research claim, especially for proposals containing multiple actions.