Transaction Proposal

A proposal to change delegation rules or the distribution of voting power within the governance system itself.

• Example: A proposal to implement vote delegation features or adjust quorum thresholds.
• Example: Minting new governance tokens for a contributor grant, which increases total supply and voting power.
• Meta-Governance: These proposals govern the governance process.

A time-sensitive proposal to mitigate a security vulnerability, exploit, or critical failure. These often bypass standard timelocks via a guardian or emergency multisig.

• Example: Pausing all borrowing/lending markets on a money market protocol after a vulnerability is discovered.
• Example: Freezing funds in a compromised bridge contract.
• Trade-off: Balances speed of response against decentralization principles.

A proposal whose execution requires an action on a different blockchain, facilitated by cross-chain messaging protocols like LayerZero or Wormhole.

• Example: A DAO on Ethereum voting to deploy liquidity or adjust parameters on an Arbitrum or Optimism deployment.
• Execution Path: Vote is finalized on mainnet, a message is relayed, and a relayer or executor performs the action on the destination chain.

Many DeFi protocols and Layer 1/Layer 2 networks use transaction proposals to modify system parameters. Examples include:

• Adjusting interest rates or collateral factors in a lending market.
• Changing validator rewards or gas fees on a blockchain.
• Updating the whitelist for a decentralized exchange. These proposals are critical for the adaptive, community-led management of live protocols.

For protocols using upgradeable proxy patterns, a transaction proposal is the primary method to deploy and switch to a new implementation contract. This process is highly sensitive, as it can change the core logic of the system. Proposals typically include the new contract's address and require extensive testing, audits, and a high approval quorum before execution to mitigate risk.

The lifecycle of a transaction proposal follows a standard pattern:

1. Drafting & Simulation: The proposer defines the target, calldata, and value, often simulating it on a testnet.
2. Submission: The proposal is posted on-chain or to an off-chain service like Snapshot.
3. Discussion & Voting: A defined voting period begins, allowing stakeholders to debate and cast votes.
4. Queueing & Execution: If approved, the proposal is queued (often with a timelock delay) and finally executed by a privileged address or automated executor.

Transaction proposals introduce specific attack vectors that must be mitigated. Key security models include:

• Timelocks: A mandatory delay between proposal approval and execution, allowing users to exit if a malicious proposal passes.
• Multisig Thresholds: Requiring a minimum number of independent signers prevents a single point of failure.
• Proposal Sponsorship: Some systems require a deposit to submit a proposal, which is slashed if the proposal is deemed spam or malicious, protecting against governance attacks.

A proposal can contain hidden malicious code or unintended side effects. Key risks include:

• Reentrancy attacks where a contract call allows an attacker to re-enter and drain funds.
• Unchecked external calls that transfer control to an untrusted contract.
• Signature replay attacks where a signed proposal is submitted multiple times on different chains or contracts. Always decode and simulate the proposal's full effects before signing.

Proposals must be validated against the signer's permissions. Critical checks involve:

• Spending limits: Does the proposal exceed approved token allowances or wallet balances?
• Role-based access: In multi-signature wallets or DAOs, does the proposer have the correct role (e.g., treasurer) for this action?
• Delegate calls: Proposals using delegatecall can modify the state of the calling contract, a high-risk operation requiring explicit scrutiny.

Transaction proposals are visible in the public mempool before execution, creating exploitation vectors:

• Sandwich attacks: A malicious actor places orders before and after a victim's trade to profit from price impact.
• Time-bandit attacks: Validators can reorder or censor transactions for maximal extractable value (MEV). Mitigations include using private transaction relays, commit-reveal schemes, or submitting proposals directly to trusted validators.

Failing to properly simulate a proposal can lead to irreversible loss. Essential practices are:

• Dry-run execution: Use an eth_call RPC to simulate the transaction on a forked network state without broadcasting.
• Accurate gas estimation: Underestimating gas can cause the transaction to revert, wasting fees; overestimating wastes funds. Tools like Tenderly and OpenZeppelin Defender provide simulation environments.
• State validation: Confirm the simulation uses the exact same state (block number, storage) as the live network.

The interface presenting the proposal is a critical attack surface. Common threats include:

• Spoofed domains: Fake wallet interfaces that mimic legitimate sites to steal signatures.
• Malicious transaction decoders: Browser extensions or wallet plugins that intentionally misrepresent proposal data.
• Blind signing: Signing proposals where the data is encoded or unreadable, hiding its true intent. Always verify the requesting domain and use wallets that display human-readable transaction summaries.

For proposals in decentralized organizations or treasuries, additional procedural security is required:

• Timelocks: A mandatory delay between proposal approval and execution, allowing time to review and potentially cancel malicious actions.
• Quorum requirements: A minimum threshold of participation must be met for a proposal to be valid, preventing minority attacks.
• Execution separation: The roles of proposing, voting, and executing a transaction should be divided among different parties or contracts where possible to limit single points of failure.

A User Operation is a standardized data structure used in Account Abstraction (ERC-4337) to represent a user's intent. It is the core object bundled and relayed to a blockchain, containing the transaction details, signature, and gas payment preferences. Unlike a raw transaction, it is not signed with an EOA's private key but is validated by a smart contract wallet.

• Key fields: sender, nonce, initCode, callData, signature.
• Lifecycle: Created by a dApp, signed by the user, relayed by a Bundler, and executed on-chain.

A cryptographic signature is proof of authorization for a transaction or message, generated using a user's private key. In the context of a transaction proposal, the user signs a hash of the proposal data. For smart contract wallets (ERC-4337), signatures can be flexible, supporting:

• Traditional ECDSA: Standard Ethereum signatures.
• Multi-sig Schemes: Requiring multiple approvals.
• Session Keys: Time or scope-limited permissions. The signature is included in the User Operation and validated by the wallet's verification logic.

A Bundler is a network participant in the ERC-4337 (Account Abstraction) ecosystem that packages multiple User Operations into a single blockchain transaction. It acts as a transaction relay, assuming gas costs and earning fees.

• Primary Role: Accepts signed User Ops, bundles them, and submits them to a Paymaster for sponsorship or payment.
• Economic Incentive: Earns a priority fee from each bundled operation.
• Key Component: Enables gas abstraction and improves user experience by handling transaction execution complexity.

A Paymaster is a smart contract in the ERC-4337 standard that can sponsor gas fees for users' transactions. It allows dApps or wallet providers to abstract away gas costs, enabling gasless transactions or payment in ERC-20 tokens.

• Sponsorship: The Paymaster contract pays the network fees for a User Operation.
• Validation: It verifies conditions (e.g., user has a specific NFT) before agreeing to sponsor.
• Post-Op: Can execute logic after the user's transaction, such as deducting an ERC-20 token balance.

The EntryPoint is a singleton, audited smart contract that serves as the central orchestrator and security anchor for ERC-4337 account abstraction. All User Operations must pass through this contract for execution.

• Core Functions: Validates each operation's signature and paymaster sponsorship, executes the bundled calls, and handles gas accounting.
• Security Model: Ensures atomic execution—if any operation in a bundle fails, the entire bundle reverts, preventing partial failures.
• Standardization: Provides a uniform interface for Bundlers to interact with all smart contract wallets.

Call Data is the encoded function call information within a transaction or User Operation. It specifies what the transaction should do by identifying the target smart contract and the function to execute with its arguments.

• Structure: A hexadecimal string starting with a 4-byte function selector, followed by encoded parameters.
• In a Proposal: This is the core payload a dApp constructs, detailing the contract interaction (e.g., transfer(0xabc..., 100)).
• Verification: Users should review this data in their wallet interface before signing, as it defines the transaction's on-chain effect.