State-Changing Proposal

A state-changing proposal is a formal, on-chain transaction or message that, if approved by a protocol's governance system, will alter the protocol's state. This state encompasses the fundamental rules and data stored by the protocol, such as smart contract code, fee parameters, treasury allocations, or validator sets. Unlike informal suggestions or signaling votes, a state-changing proposal contains executable code or specific parameter updates that are automatically implemented upon successful passage, making it the primary vehicle for decentralized upgrade and maintenance.

The lifecycle of a state-changing proposal typically follows a multi-stage governance process. It begins with a discussion period on forums, followed by the submission of the proposal on-chain, often requiring a deposit. A voting period then commences, where token holders or delegated representatives cast votes weighted by their stake. If the proposal meets predefined quorum and approval threshold requirements, it moves to a timelock period—a security delay allowing users to react—before the encoded changes are finally executed on-chain, irrevocably updating the protocol.

These proposals are categorized by their impact. Parameter change proposals adjust existing system variables (e.g., interest rates, block rewards). Spending proposals authorize transfers from the community treasury. The most critical type is the code upgrade proposal, which deploys new smart contract logic, requiring extreme caution due to its potential for introducing bugs or vulnerabilities. This hierarchy ensures different levels of scrutiny are applied based on the proposal's risk profile.

Examples of state-changing proposals include a DAO voting to increase the stability fee in a lending protocol like MakerDAO, a decentralized exchange governance approving a new fee structure, or a blockchain network like Cosmos voting to adopt a new software upgrade module. Each action directly modifies the live, economic rules governing user interactions with the protocol.

The security of this process relies on robust governance frameworks and ancillary mechanisms. Multisig execution may be required for high-risk changes, and constitutional models can restrict the scope of what proposals are allowable. The goal is to balance decentralized coordination with safeguards against malicious proposals or voter apathy, ensuring the protocol can evolve without centralized control while protecting user funds and system integrity.

A state-changing proposal is a formal governance mechanism that, when executed, modifies the on-chain state of a protocol. This is distinct from a signaling proposal, which merely gauges community sentiment. The 'state' refers to the stored data that defines the protocol's current configuration, such as smart contract code, treasury funds, fee parameters, or validator requirements. Executing such a proposal directly alters this data, changing how the system operates. This process is fundamental to the decentralized autonomous organization (DAO) model, where stakeholders collectively steer the protocol's evolution without relying on a central authority.

The lifecycle of a state-changing proposal typically follows a multi-stage process defined in the protocol's governance smart contracts. It begins with proposal submission, where a user deposits a required stake to prevent spam and submits the executable code or parameter change. This triggers a voting period, during which token holders cast votes weighted by their stake or voting power. Many systems employ delegate voting, where users can entrust their voting power to representatives. For a proposal to pass, it must usually meet dual thresholds: a minimum quorum (percentage of total voting power participating) and a majority or supermajority approval from those votes.

Upon successful approval, the proposal does not execute automatically unless the system is designed for on-chain execution. In many frameworks, a timelock period is enforced between approval and execution. This critical security feature provides a final buffer, allowing users to review the passed code and, in some systems, exit if they disagree with the change. After the timelock expires, any user can trigger the execution transaction, which calls the predefined function to update the protocol's state. This entire workflow—submission, voting, timelock, execution—is often managed autonomously by smart contracts, ensuring transparency and censorship resistance.

Examples of state-changing proposals are diverse and impactful. They include upgrading a protocol's smart contract to a new version (e.g., Uniswap's move from V2 to V3), adjusting fee parameters in a lending protocol like Aave, allocating funds from a community treasury to a grant, or modifying the collateral factors in a decentralized stablecoin system like MakerDAO. Each action permanently alters the live economic rules of the network. Failed proposals simply expire, with the submitter's stake often being slashed or returned depending on the system's design, ensuring accountability for proposal quality.

A state-changing proposal is a formal on-chain transaction that, when executed, permanently alters the data stored within a smart contract or the blockchain's state. This is the most common and consequential type of proposal, as it directly modifies the rules, parameters, or assets governed by a protocol. Examples include upgrading a contract's logic, adjusting fee parameters, transferring treasury funds, or adding new functionality. The execution of such a proposal results in a new, immutable state root, and its effects are visible to all network participants.

The execution mechanism for a state-changing proposal is fundamentally a function call to a smart contract. The proposal's payload contains encoded data specifying the target contract address, the function to invoke (e.g., executeProposal or upgradeTo), and the necessary arguments. This transaction is typically submitted by a privileged address, such as a governor or multisig wallet, only after the proposal has successfully passed all required governance stages (e.g., a snapshot vote followed by a timelock delay). The gas cost and potential for reversion are key technical considerations during execution.

Crucially, these proposals are distinguished from non-state-changing or view proposals, which only read data from the blockchain without making persistent changes. State-changing execution carries inherent risk, which is why mechanisms like timelocks and multisig confirmations are employed. A timelock enforces a mandatory delay between a proposal's approval and its execution, providing a final window for community review or emergency intervention if a malicious proposal is discovered.

From a developer's perspective, the execution function must be carefully audited, as it acts with the full authority of the governance system. Common security patterns include access control modifiers (e.g., onlyGovernance), checks for the proposal's current state (ProposalState.Queued or ProposalState.Succeeded), and validation of the payload data. Failed execution, due to insufficient gas or a revert in the target contract, leaves the blockchain state unchanged but may require a new proposal to retry the action.

In practice, the lifecycle of a state-changing proposal involves multiple smart contracts: a governance contract (like OpenZeppelin's Governor) holds the proposal logic and voting, a timelock contract (like TimelockController) queues and executes calls, and the target protocol contract receives the final call. This modular separation of concerns enhances security and auditability, ensuring that the power to change the system's state is exercised through a transparent and deliberate process.