Executable Proposal

An executable proposal contains the bytecode or calldata required to call a specific function on a target smart contract. Upon successful vote, the transaction is executed autonomously, changing the protocol's state. This is distinct from off-chain signaling, which requires manual intervention by a privileged admin or multisig.

• Example: A proposal to update a liquidation threshold on a lending protocol would include the exact function call to setLiquidationThreshold(address asset, uint256 threshold).

Most executable proposals are routed through a timelock contract, a critical security mechanism. After a vote passes, the approved transaction is queued in the timelock for a mandatory delay period (e.g., 48 hours). This creates a grace period for users to review the final action and, if necessary, for emergency measures to be enacted before the change takes effect.

This is the most common use case for executable proposals. They enable decentralized control over a protocol's adjustable parameters without requiring a full redeployment. Typical actions include:

• Adjusting fee percentages or reward rates.
• Adding or removing collateral assets from a money market.
• Updating the address of an oracle or keeper network.
• Modifying quorum or voting delay settings for the governance system itself.

Executable proposals enable transparent, community-controlled treasury operations. They can authorize specific transactions from the protocol's treasury, such as:

• Funding grants to developers or projects.
• Executing token buybacks and burns.
• Transferring funds to pay for audits, insurance, or other operational expenses.

Each action is publicly visible on-chain before and after execution.

For protocols using upgradeable proxy patterns (like Transparent or UUPS proxies), executable proposals can initiate a full contract upgrade. This involves a proposal to change the implementation address that the proxy points to, allowing the protocol to deploy new logic while preserving its state and address. This is a high-risk operation that typically requires a security council or extended timelock.

While powerful, executable proposals introduce unique risks:

• Malicious Payloads: A proposal could contain hidden, harmful code.
• Voter Fatigue: Complex bytecode is difficult for the average token holder to audit.
• Timelock Bypass: Bugs in the governance or timelock contracts could allow premature execution.

Mitigations include professional auditing, delegate-based voting where experts analyze proposals, and multisig fallback mechanisms.

An executable proposal is a smart contract transaction submitted to a governance system. Its payload contains the encoded function calls and parameters for a specific on-chain action. Upon successful voting, the proposal is queued and automatically executed by the protocol, removing the need for manual intervention by a privileged admin.

• Payload: Contains the target contract address, function signature, and calldata.
• Queue & Timelock: Approved proposals often enter a queue with a mandatory delay (timelock) before execution, allowing for a final review period.
• Execution Trigger: A permissionless call to an execute function finalizes the state change.

Executable proposals are the primary tool for decentralized parameter management and treasury operations.

• Parameter Updates: Adjusting protocol constants like interest rates, fee percentages, or collateral factors.
• Treasury Management: Authorizing payments, grants, or token swaps from the community treasury.
• Contract Upgrades: Deploying new logic contracts and updating proxy pointers for upgradeable systems.
• Integrations & Listings: Adding new collateral assets to a lending market or new pools to a DEX.

The lifecycle of an executable proposal involves multiple stages designed for security and community oversight.

• Creation & Submission: A proposer, often requiring a minimum token stake, creates and submits the proposal.
• Voting Period: Token holders vote (e.g., For, Against, Abstain) within a defined timeframe.
• Quorum & Threshold: The vote must meet a minimum participation (quorum) and approval threshold to pass.
• Timelock & Execution: A passed proposal may be subject to a timelock delay for security, after which it can be executed by any address.

From a developer's perspective, an executable proposal is a data structure pointing to on-chain logic.

• Targets & Calldata: The proposal specifies an array of target contract addresses and the corresponding calldata for each.
• Values: Can specify the amount of native currency (e.g., ETH) to send with the call for payments.
• Governance Modules: Implemented via systems like OpenZeppelin Governor, Compound's Governor Bravo, or DAO-specific frameworks.
• Simulation: Proposals should be simulated on a forked network (using tools like Tenderly) to verify effects before a live vote.

While powerful, executable proposals introduce specific risks that governance participants must assess.

• Code Vulnerability: The embedded calldata could exploit a bug in the target contract.
• Parameter Tyranny: Malicious or poorly calibrated parameter changes can destabilize the system.
• Timelock Bypass: Proposals that upgrade governance contracts themselves can potentially remove future timelocks or thresholds.
• Voter Apathy & Plutocracy: Low participation can allow a small, wealthy cohort to control execution.

The core risk is embedding malicious code within the proposal's calldata. This code executes with the full permissions of the governance contract, potentially allowing:

• Fund Drainage: Transferring treasury assets to an attacker-controlled address.
• Privilege Escalation: Updating contract owners or admins.
• Logic Corruption: Permanently disabling critical protocol functions or setting malicious parameters.

The time window between proposal creation and execution creates attack vectors.

• Time-Delay Exploits: Attackers can front-run or sandwich the execution transaction to profit from anticipated state changes.
• Reentrancy: If the target contract has vulnerabilities, the proposal's execution could trigger a reentrant call, allowing an attacker to drain funds mid-execution before state updates.

Complex proposals can hide malicious intent through obfuscation, challenging voter due diligence.

• Encoded Arguments: Malicious parameters may be buried within densely packed ABI-encoded calldata.
• Proxy Patterns: Calls through proxy contracts or delegatecall can mask the final execution target and logic.
• External Calls: Proposals that make calls to unknown or mutable external contracts introduce uncontrolled risk.

Executable proposals are a target for broader governance attacks.

• Vote Manipulation: Attackers may acquire voting power (via flash loans or token borrowing) specifically to pass a malicious proposal.
• Timelock Circumvention: If a timelock is poorly implemented, proposals might execute before adequate review.
• Fatigue Attacks: Submitting many complex, benign proposals to fatigue voters, then slipping a malicious one through.

Protocols implement several defenses to manage these risks.

• Timelocks: A mandatory delay between vote conclusion and execution, allowing for emergency cancellation if malice is detected.
• Multisig Guardians: A fallback committee with the power to veto or pause malicious executions.
• Code & Parameter Audits: Requiring professional audits and Etherscan-like verification of proposal calldata before voting.
• Execution Separation: Using a separate, limited-permission Executor contract to isolate proposal execution power.