SignorCrypto note · CRYPTO
Ethereum Transaction Assertions: How Outcome Checks Work
A builder’s guide to EIP-7906, post-execution checks, and the limits of a proposal still in draft.
An Ethereum transaction assertion is a rule evaluated against the state and events a transaction actually produces; it can reject an outcome even when the signed request was valid. Ethereum Foundation’s EIP-7906 proposes opcodes that would expose a transaction’s net state changes to a read-only POST_TX frame, so a wallet or protocol could enforce conditions such as a minimum amount received or a maximum spend. This differs from clear signing or simulation. As of 11 October 2026, EIP-7906 remains an unconfirmed proposal—not a live Ethereum feature—and depends on another draft, EIP-8141.
Why a valid signature may not guarantee the intended outcome
A signature authorizes a transaction request, including its target, value and calldata. It does not by itself guarantee the economic or technical result after execution. Ethereum applies the request to the code and state present when the transaction runs; ordering or changed state can affect what happens.
A simulation can estimate an outcome against a selected state, and a wallet can explain what the calldata asks to do. Neither necessarily enforces what the transaction ultimately produces. A transaction assertion would add a separate rule about the resulting state.
What EIP-7906 proposes
EIP-7906 is a draft Ethereum Improvement Proposal titled “Transaction Assertions via State Diff Opcode.” It depends on EIP-8141, a separate draft for frame transactions. In that model, a transaction can contain ordered frames, with a read-only POST_TX frame at the end checking the result of the earlier execution frames.
The proposal describes three opcodes:
TXTRACEenumerates net state changes and events produced by the transaction.TXDIFFlooks up the starting and final values for a selected address or storage slot.EVENTDATACOPYcopies event data into memory so assertion code can examine it.
An assertion could compare the final state with a rule—for example, that an account received at least a specified amount, spent no more than a limit, kept its control configuration unchanged, or did not create an unapproved token allowance. These are illustrative policies, not a guarantee that every contract or wallet supports them today.
If the check fails, the proposal would revert the transaction’s execution body. The transaction would still be included and the gas already consumed would still be charged. This makes the assertion an execution-time condition rather than a prediction displayed before signing.
The rule must be trusted—and must be required
The security value depends on where the assertion comes from. A compromised interface could attach a permissive rule that allows the very outcome the user wanted to prevent. The rule needs to come from independently approved intent, a wallet policy or protocol logic that the compromised transaction builder cannot rewrite.
EIP-7906 also does not require every transaction to include an assertion. A wallet would need to require the rule in the frame transactions it creates. A protocol that depends on a particular check would need to verify that the expected assertion is present and reject incompatible or ordinary transactions. Without those checks, an assertion is optional protection, not a universal Ethereum guarantee.
Assertions, clear signing and simulation are different controls
| Control | What it checks | Main limitation |
|---|---|---|
| Clear signing | Explains the requested action before approval | A readable request does not guarantee its eventual result |
| Simulation | Estimates effects against a selected chain state | State or signed payload can differ before inclusion |
| Transaction assertion (proposed) | Checks actual net changes and events during execution | Needs a trusted rule, compatible transaction flow and explicit enforcement |
Our ERC-7730 clear-signing guide covers the human-readable approval layer. For autonomous transactions, our AI agent least-privilege blueprint covers the separate question of which authority an agent should receive. An outcome assertion could complement those controls; it would not replace them.
What transaction assertions would not solve
An assertion cannot make a bad rule wise, identify a trustworthy interface on its own, or guarantee a multi-step process across several chains. The proposal focuses on the outcome of one transaction on one network. A cross-chain route or an off-chain workflow would need additional controls at its other stages.
It would also require changes to transaction formats, wallets, protocols and client software before users could rely on it. The current EIPs are proposals, not instructions for a live mainnet feature.
Current status as of 11 October 2026
The Ethereum Foundation’s 5 October overview presents EIP-7906 as one possible design for native transaction assertions. It says the companion EIP-8141 is scheduled for Hegotá, while EIP-7906 is only “Considered for Inclusion” and is not yet confirmed for that upgrade. The official EIP-7906 and EIP-8141 pages currently label both proposals as Draft. Treat the mechanism as research and protocol design—not a security feature already available to Ethereum users.
FAQ
Are Ethereum transaction assertions live on mainnet?
No. EIP-7906 and its EIP-8141 dependency are drafts. The Ethereum Foundation has not confirmed EIP-7906 for a network upgrade.
Could an assertion protect a token swap?
Potentially, in a compatible transaction flow, if a wallet or protocol supplies and enforces a trusted condition such as a minimum net amount received. It would not help if the rule were missing, permissive or derived from a compromised source.
Would assertions replace clear signing or simulation?
No. Clear signing helps a person understand the request; simulation estimates an outcome; a transaction assertion would check an execution result against a rule. They address different points in the transaction lifecycle.
Sources
- Ethereum Foundation: How native transaction assertions could enforce a transaction’s final outcome — overview published 5 October 2026.
- EIP-7906: Transaction Assertions via State Diff Opcode — draft specification.
- EIP-8141: Frame Transaction — draft frame-transaction dependency.
- Ethereum Foundation: Clear Signing announcement — background on the pre-signing control.
For wallet and protocol teams evaluating transaction-level outcome rules, contact SignorCrypto to map the wallet, contract and integration trade-offs before relying on a proposed standard.