How to Review Governance Execution Safety

On-chain governance is a powerful mechanism for decentralized protocols, allowing token holders to vote on upgrades and parameter changes. However, the execution of a passed proposal introduces significant risk. A malicious or poorly coded proposal can drain treasuries, brick core contracts, or create permanent security vulnerabilities. This guide provides a framework for reviewing the execution safety of a proposal, focusing on the technical implementation of the payload contract that will be called by the governance system.

The review process begins with understanding the proposal's context. Identify the target contracts, which are typically the protocol's core logic or configuration modules. Determine the privileges required for execution—does the proposal need TimelockController access, a specific ROLE, or direct ownership? Review the governance system's own security model, such as Compound's Governor Bravo or OpenZeppelin's Governor, to understand the proposal lifecycle from queuing to execution.

Next, perform a line-by-line audit of the proposal's payload contract. This is the smart contract containing the execute() or propose() function that will be called. Scrutinize every external call using tools like static analyzers (Slither, MythX) and manual review. Key red flags include: arbitrary delegatecall operations, unchecked low-level calls (call, delegatecall), external calls to untrusted or user-supplied addresses, and state changes that bypass access controls.

A critical step is simulating the proposal's execution in a forked environment. Use frameworks like Foundry or Hardhat to fork the mainnet state at a recent block. Deploy the payload contract and call its execute function, monitoring for unexpected reverts, gas consumption spikes, and—most importantly—changes to the protocol's critical state variables. Verify that the proposal's effects match its described intent and that no storage collisions occur with existing contract layouts.

Finally, assess the proposal's impact on the broader system. Even a technically sound proposal can be dangerous if it changes economic incentives or security parameters. Evaluate the new logic for potential economic attacks like flash loan manipulations, oracle manipulation surfaces, or changes to liquidation thresholds. Document all findings, create a risk matrix (Critical/High/Medium/Low), and provide clear recommendations for mitigation before the proposal moves to a vote.

Governance execution safety is the process of verifying that a proposal's on-chain actions will perform as intended without unintended side effects. This review is distinct from evaluating the proposal's social consensus or economic impact; it focuses on the technical correctness of the encoded transactions. The primary goal is to prevent scenarios where a proposal passes a vote but executes malicious code, drains funds, or bricks a protocol due to a bug. This requires a methodical analysis of the target smart contract, the proposed calldata, and the state changes they will induce.

To conduct this review, you need access to several key pieces of information. First, obtain the exact target address and the raw calldata (the encoded function call) from the proposal. Second, you must have the Application Binary Interface (ABI) for the target contract to decode the calldata into human-readable function calls and arguments. Tools like Etherscan, Tenderly, or the project's official GitHub repository are essential for this. Finally, you need to understand the current state of the protocol—its storage variables, access controls, and dependencies—to model the execution's outcome.

The core skill is the ability to read and reason about smart contract code. You should be comfortable with Solidity (or the relevant language, like Vyper) and understand common patterns like access control modifiers (onlyOwner, onlyGovernance), reentrancy guards, and state variable dependencies. Familiarity with development frameworks like Hardhat or Foundry is beneficial for setting up a local fork to simulate the proposal's execution in a safe environment. This allows you to test the calldata against the exact contract state at the time of proposal submission.

A critical part of the review is mapping the permission landscape. You must verify that the governance executor (e.g., a Timelock contract) actually has the authority to call the proposed function. Check for and understand any intermediate contracts, like proxies or routers, that the call may pass through. Review the proposal for multi-step operations or delegate calls, which can drastically escalate risk by allowing execution of arbitrary code. Always ask: what is the maximum possible damage if this calldata is malicious or contains an error?

Finally, establish a consistent checklist for your reviews. This should include: verifying calldata decoding matches the proposal description, checking function visibility and modifiers, confirming the recipient addresses for any fund transfers, validating input parameters against allowed ranges, and identifying external contract calls. Documenting your findings clearly, often in the form of a structured report on forums like Commonwealth or the project's Discord, contributes to the collective security of the decentralized ecosystem.

Effective governance is the backbone of decentralized protocols, but its power is matched by its risk. A malicious or flawed proposal can drain treasuries, brick core contracts, or permanently alter protocol incentives. Governance execution safety is the practice of rigorously auditing a proposal's on-chain actions to prevent these outcomes. This framework provides a structured methodology for reviewers, moving beyond surface-level sentiment to analyze the concrete, low-level changes a proposal will enact on-chain.

The review process begins with context and intent analysis. First, verify the proposal's alignment with the community's stated goals by reading the associated forum discussion. Then, meticulously map the proposal's narrative to its technical implementation. A common failure mode is a mismatch between the described intent and the actual code—for example, a proposal to "adjust parameters" might silently grant excessive permissions. Scrutinize the proposal source, whether it's a Solidity contract, a set of calldata, or configuration changes, and confirm it originates from a verified, reputable address.

The core of the review is transaction simulation and state impact analysis. Using a forked mainnet environment with tools like Tenderly, Foundry's cast, or Hardhat, execute the proposal transactions against a recent block. This is non-negotiable. You must examine: the differential state change (what storage slots are modified), access control checks (is the msg.sender authorized for every action?), and external calls (which contracts are interacted with and are they trusted?). Pay special attention to any call that transfers assets or changes ownership.

For complex proposals involving new contract deployments, a smart contract security review is required. This extends beyond the proposal's calls to the logic of any new code being introduced. Key checks include: reentrancy guards, proper use of delegatecall, inheritance and initialization issues, and centralization risks like admin key ownership. Even if the code is audited, verify that the deployed bytecode matches the audited source. Tools like Slither or Mythril can provide automated analysis to complement manual review.

Finally, synthesize findings into a risk assessment report. Categorize issues by severity (Critical, High, Medium) and likelihood. A Critical finding might be a direct path to fund loss, while a Medium finding could be a scenario requiring specific, unlikely conditions. The report should provide a clear, actionable summary for token holders: what the proposal does, the verified risks, and any recommended mitigation steps or voting recommendations. This transforms technical analysis into accessible governance intelligence.

This framework is iterative and should be integrated into a protocol's governance lifecycle. Implementing a mandatory review period where proposals are publicly analyzed, and even establishing a qualified reviewer role or security guild, can significantly elevate a DAO's resilience. The goal is not to create friction but to ensure that the immense power of on-chain governance is exercised with the same rigor as the protocol's initial code deployment.

Governance execution safety refers to the assurance that a protocol's on-chain governance system will correctly and securely execute the intent of a passed proposal. The primary goal of this phase is to map the attack surface and understand the trust model. You must answer foundational questions: What smart contracts are governed? What actions can a proposal perform? What are the system's administrative privileges and upgrade mechanisms? This analysis forms the bedrock for all subsequent technical review.

Begin by cataloging the system's components. Identify the core governance contract (e.g., OpenZeppelin's Governor, Compound's Governor Bravo), the token contract used for voting, and any timelock controller. Crucially, trace the permissions: which contracts are owned by the governance executor or timelock? Use tools like Etherscan's "Read Contract" tab or cast from Foundry (cast storage) to inspect owner() or timelock() addresses. Create a diagram mapping the flow of authority from token holders to final contract state changes.

Next, analyze the proposal lifecycle and execution context. Review the governance parameters: votingDelay, votingPeriod, proposalThreshold, and quorum. Scrutinize the execute function—what are its calldata constraints? Can it call any contract, or only a whitelisted Timelock? A critical failure mode is proposals that execute code outside a timelock, allowing for instant, irreversible changes. Examine historical proposals on Tally or Snapshot to understand typical payloads and identify any privileged patterns.

Finally, assess the scope of executable actions. The most powerful—and dangerous—proposal type is one that can upgrade core protocol logic. Determine if the governance controls a proxy admin or UUPS upgradeable implementation contract. Other high-risk actions include: changing fee parameters, minting/burning tokens, modifying reward distributions, or updating oracle addresses. Document each privileged function and its potential impact. This contextual map is essential for Phase 2, where you will analyze the code that implements these capabilities.

The core of governance execution safety is the execute or propose function. Start by mapping the proposal lifecycle: where proposals are stored, how they are queued, and the exact conditions for execution. Key checks include verifying that the proposal's state (e.g., ProposalState.Succeeded) is validated before any actions are performed and that the timelock or grace period has fully elapsed. A critical failure mode is allowing execution of a proposal that failed or is still active, which could lead to unauthorized state changes.

Next, scrutinize the target contract calls. Governance proposals typically execute via call or delegatecall to other contracts. You must verify that the target addresses and calldata are immutable once the proposal is created to prevent bait-and-switch attacks. Review the contract for any logic that allows the proposal's actions to be altered between creation and execution. Furthermore, ensure the governance contract itself cannot be upgraded or have its critical functions (like execute) modified without going through a separate, stringent governance process.

Pay close attention to reentrancy guards and gas limits. The execute function often performs multiple external calls in a loop. Each call must be protected against reentrancy, not just for the governance contract but considering the state of the target contracts. Additionally, unbounded loops over dynamic arrays of actions can run out of gas, causing a proposal to fail mid-execution and potentially leaving the system in an inconsistent state. Implement gas stipends or batch limits for safety.

Finally, analyze failure modes and contingency paths. What happens if an external call reverts? Does the entire proposal fail, or does execution continue? A safe pattern is to allow partial execution (continuing on revert) but this requires careful design to avoid leaving the system in a broken state. Conversely, atomic execution (all-or-nothing) is simpler but can be blocked by a failing, non-critical action. Document these behaviors clearly for governance participants, as they directly impact proposal design and risk assessment.

Dynamic simulation is a critical phase for testing governance proposals in a controlled, forked environment that mirrors the live network state. Unlike static analysis, which reviews code in isolation, dynamic simulation executes the proposal's transactions against a real-time fork of the blockchain. This process, often called a "dry-run" or "governance sandbox," allows you to observe the exact state changes, gas usage, and potential side effects of a proposal without risking real funds. Tools like Tenderly's Forking feature, Foundry's forge with the --fork-url flag, or Hardhat's network forking are commonly used to set up these simulations.

To begin a safety review, you must first replicate the exact conditions under which the proposal will execute. This involves forking the mainnet at the block height just before the proposal's estimated execution time. You then need to seed the fork with the necessary state, such as token balances of key contracts, delegate voting power, and any other relevant on-chain data. The goal is to create a high-fidelity simulation where the proposal's transactions are replayed verbatim. This step reveals issues that static analysis misses, such as reentrancy under specific conditions, unexpected interactions with other protocols, or incorrect assumptions about contract state.

During execution, monitor key failure points. Use tracing to inspect every call and storage change. Look for: - State corruption: Unintended modifications to core contract variables. - Gas explosions: Transactions nearing or exceeding the block gas limit. - Economic attacks: Flash loan feasibility, manipulation of oracle prices, or changes to fee parameters. - Access control violations: Whether the proposal correctly uses onlyOwner or similar modifiers. Tools like OpenZeppelin's Test Helpers or custom scripts can assert expected post-execution state, ensuring invariants hold.

A thorough review also includes integration testing with dependent protocols. If a proposal interacts with Uniswap pools, Aave lending markets, or Chainlink oracles, you must simulate those interactions on the fork. Check for broken integrations, deprecated function calls, or newly introduced risks like sandwich attacks on DEX swaps. Document any discrepancies between the simulated outcome and the proposal's stated intent. This phase often uncovers edge cases related to block timing, transaction ordering, and miner extractable value (MEV).

Finally, compile the simulation results into an actionable report. The report should detail the proposal's on-chain behavior, list all state changes with before/after values, flag any security vulnerabilities or inefficiencies, and provide a clear risk assessment. This evidence-based analysis is crucial for governance participants to make informed voting decisions. By rigorously testing execution safety, you move beyond theoretical audits to practical verification, significantly reducing the risk of catastrophic governance failures.

The Risk Synthesis and Reporting phase transforms the granular technical analysis from previous phases into a cohesive narrative. The goal is to produce a final report that clearly communicates the execution safety of the proposed governance action. This involves synthesizing findings from contract audits, parameter analysis, and dependency checks into a unified risk profile. The report must be accessible to both technical and non-technical stakeholders, such as token holders and DAO members, who will ultimately vote on the proposal. It serves as the definitive document for informed decision-making.

A comprehensive governance risk report should follow a standardized structure. Key sections include an Executive Summary highlighting critical findings, a detailed Technical Analysis of the target contracts and parameters, a Dependency & Integration Review covering external protocols, and a Simulation & Impact Assessment based on fork testing. Each identified risk must be categorized by severity (e.g., Critical, High, Medium, Low) and include a clear description, the potential impact on users or protocol treasury, and the specific code location or condition that triggers it. This structured approach ensures no finding is overlooked.

Beyond listing vulnerabilities, effective reporting provides actionable recommendations. For each risk, the report should suggest concrete mitigations. For a high-severity reentrancy risk, a recommendation might be: "Apply the checks-effects-interactions pattern and add a reentrancy guard modifier from OpenZeppelin's ReentrancyGuard.sol." For a parameter change, it could advise: "Implement the new fee increase over three epochs using a timelock-controller, allowing a governance veto if unintended consequences arise in live data." These recommendations bridge the gap between identification and resolution.

The final report must also include a residual risk statement and monitoring guidance. After applying all recommended mitigations, what risks remain? These could be systemic risks inherent to the blockchain (e.g., MEV) or accepted trade-offs. The report should then outline post-execution monitoring steps, such as watching specific contract events or health metrics like TVL and slippage on associated pools for 48 hours after the upgrade. Tools like Tenderly's real-time alerting or custom Chainscore monitoring dashboards can be configured for this purpose.

Publishing and communicating the report is the final step. The analysis should be shared on the project's governance forum (e.g., Commonwealth, Discourse) with ample time for community review before a snapshot vote. Transparency is critical: link to all verification scripts on GitHub, share the fork simulation environment (like a Foundry project or Tenderly fork URL), and make the audit report publicly accessible. This process not only safeguards the current proposal but also builds long-term trust in the protocol's governance process by demonstrating rigorous, reproducible safety checks.