A Valid Signature Can Still Produce the Wrong Outcome: Ethereum Transaction Assertions Explained
Ethereum researchers are exploring native transaction assertions that inspect final state changes and revert execution when outcomes violate a signed rule.
3 分钟阅读
Signing an Ethereum transaction does not guarantee that its final outcome matches the user’s intent. A signature authorizes calls and parameters; the result still depends on contract code and onchain state at execution time.
On October 5, 2026, the Ethereum Foundation described research into native transaction assertions. Read-only rules would inspect the complete net state change after transaction actions run. If balances, approvals, code, or events violate the signed rule, the actions revert.
From “what did I sign?” to “what outcome must I receive?”
Wallet simulation can preview execution, but a compromised frontend, changing state, or complex contract path can still produce an unwanted result. An assertion could require a minimum amount received, cap spending, reject new approvals, preserve account control logic, or allow only a defined set of changes.
The rule is signed with the actions and compares starting and final state rather than one intermediate call. When it fails, the execution body reverts. The failed transaction remains in the block, and the gas payer still pays for consumed gas.
EIP-7906 is a proposal, not a live guarantee
EIP-7906 builds on EIP-8141 frame transactions by adding a read-only POST_TX phase. It proposes three opcodes—TXTRACE, TXDIFF, and EVENTDATACOPY—to inspect net state changes and events. EIP-8141 is scheduled for Hegotá, while EIP-7906 is only “Considered for Inclusion” and is not confirmed for the upgrade.
Wallets and protocols can participate in design and experimentation today, but they cannot present transaction assertions as an existing mainnet protection.
Why agents make this more important
Agent permissions usually describe which contracts may be called, maximum spending, and expiry. Assertions can also constrain the outcome: a minimum post-swap balance, return of unused tokens, or removal of temporary approvals.
The source of the rule is critical. A compromised frontend can create an assertion that permits its own attack. Reliable rules need independently approved user intent, a standing account policy, or protocol logic the compromised component cannot alter.
Limits and costs
- An assertion covers one transaction on one network, not an entire cross-chain route.
- Existing immutable contracts may be unable to require a particular assertion.
- Failed assertions still consume gas.
- An overly strict rule blocks legitimate activity; a loose rule provides little protection.
The promise of transaction assertions is a move from explaining a call to enforcing an outcome. As agents, solvers, and batch executors initiate more transactions, that may become a stronger final defense than another warning dialog.