Ethereum Foundation proposes native transaction assertions to prevent signing failures
The Ethereum Foundation’s Trillion Dollar Security initiative has published a design for native transaction assertions, a mechanism to let users sign rules that verify a transaction’s final state before execution and revert it if the outcome violates those rules. The proposal addresses two categories of losses: intent mismatches, where a user signs a request they did not intend to make, and outcome mismatches, where a signed transaction produces a result that conflicts with the signer’s economic goal.
- Native transaction assertions let onchain code inspect the full set of net state changes after execution completes.
- EIP-7906 proposes three new EVM opcodes: TXTRACE, TXDIFF and EVENTDATACOPY to enumerate and retrieve state and event data.
- The mechanism does not require every transaction to include an assertion, leaving the decision to wallets and protocol builders.
The Ethereum Foundation’s blog post on transaction assertions identifies blind signing and transaction uncertainty as user experience risks and explores how native assertions could enforce a transaction’s intended outcome. The post cites three real losses: the Bybit incident and BadgerDAO attack, both intent mismatches where compromised frontends supplied signing requests different from what users believed they were approving, and an Aave collateral swap where a user signed a transaction with 99.9 percent price impact and received tokens worth roughly $36,000 of a $50.4 million intended swap.
How Ethereum’s Execution Model Creates the Risk
Ethereum executes exactly what a transaction authorizes without judging whether the result matches the signer’s intent. A signature commits to a request, a target address, value and calldata, but its outcome depends on the code and state the transaction encounters during execution.
If either the code or state changes between the time a user signs and the transaction is included, the result can diverge from what the signer expected.
Contract code can change via proxy implementations, and state can shift via transaction ordering or sandwich attacks. Existing defenses, Clear Signing, simulation, contract checks and wallet guards, all have gaps. Clear Signing depends on accurate decoding and user recognition of mismatch.
Simulation predicts effects using a selected chain state, which can change before inclusion. Contract checks and wallet guards can verify specific balances or configuration, but they “cannot inspect the transaction’s full set of net state changes,” according to the post, leaving unmonitored effects unnoticed.
The Proposed Mechanism and Design
Native transaction assertions would let onchain code inspect the full set of net state changes after a transaction runs and revert execution if the changes violate a signed rule. The rule is included in the transaction, signed alongside its actions, and can cover net changes to balances, storage, code, newly deployed contracts and emitted events.
The rule’s source is critical: a compromised frontend can write an assertion that permits an attack, so useful rules must come from independently approved user intent or standing account policy.
EIP-7906 adds a read-only POST_TX frame at the end to check the transaction’s outcome. The design exposes both state changes and events. State changes are reported as net differences in native ETH balances and storage, alongside newly deployed contracts and their code hashes.
Implementation Path and Open Questions
The Foundation proposes EIP-7906, which builds on frame transactions defined in EIP-8141. EIP-8141 is scheduled for the Hegotá upgrade, while EIP-7906 has reached “Considered for Inclusion” status but is not yet confirmed for any upgrade. The three new opcodes, TXTRACE, TXDIFF and EVENTDATACOPY, work only inside a POST_TX frame, which runs as a static call so assertions cannot change state.
If a rule is violated, the entire execution body reverts, but the transaction remains in the block with failed status and the gas payer is charged. EIP-7906 does not require transactions to include an assertion. For the user’s own transactions, the wallet must ensure that every frame transaction it builds includes the required assertion.
A protocol’s protected function must verify that the call comes from a frame transaction containing the required assertion and reject ordinary transactions or frame transactions with a missing or incorrect assertion.
What Changes in Practice
For users, native assertions shift the burden of outcome verification from post-execution remediation to pre-execution prevention. A wallet must ensure every frame transaction it builds includes the required assertion, drawing the rule from simulation or standing policy.
For protocols, a protected function can require frame transactions with a specific assertion, rejecting ordinary transactions or assertions that are missing or incorrect. Already-deployed immutable contracts cannot add such checks retroactively.
The mechanism opens use cases beyond immediate security: constraining agent delegation, specifying protocol-defined outcomes while leaving solvers free to choose execution routes, and checking that workflows reach intended final states with unused tokens returned and approvals revoked.
The CCS read. The proposal addresses a real gap in Ethereum’s user protection: existing defenses stop at contract checks and simulation, neither of which can see the full picture of what a transaction changed. Native assertions give users a signed rule to verify outcomes, but success depends entirely on wallets enforcing them by default and protocols adopting compatible frame transactions. If assertions remain optional, their security benefit applies only to users and protocols sophisticated enough to use them.
EIP-8141 is scheduled for the Hegotá upgrade; EIP-7906 status remains “Considered for Inclusion” with no confirmed activation date. The Foundation is soliciting input from wallet and protocol teams at trilliondollarsecurity@ethereum.org.