Ethereum’s proposed transaction assertions now have a documentation trap for wallet developers. The Ethereum Foundation’s October 5 explainer describes three new instructions and a POST_TX frame. The live EIP-7906 draft instead specifies two instructions and a trailing ASSERT frame mode. Both describe checking a transaction’s effects, but they are not interchangeable implementation references.
The Foundation presents assertions as research into enforcing an intended result, alongside Clear Signing. EIP-7906 remains labelled Draft. This document comparison reports neither a deployed wallet feature nor a SekaiTech security test.
Clear Signing explains a requested action; simulation predicts effects against a selected state. The Foundation proposes checking the actual result during execution as an additional safeguard.
Consider a rule that a transaction must not grant a new token approval. Showing the intended transfer clearly does not itself enforce that separate rule. An assertion would inspect the resulting changes and reject actions that violate its policy. The policy still needs an independent basis: if the same compromised transaction builder chooses a permissive rule, adding a check supplies little protection.
What the live draft actually specifies
The differences are concrete enough to affect code, not merely terminology:
- The October 5 article names
TXTRACE,TXDIFFandEVENTDATACOPY. The current draft definesTXTRACEandEVENTDATACOPY, with selector parameters onTXTRACEfor accessing the reported information. - The article describes a read-only
POST_TXframe. The draft adds anASSERTmode to EIP-8141 frame transactions and requires assertion frames to form a contiguous suffix after the other frames. - The draft explicitly distinguishes the execution body from the validation prefix. A failed assertion rolls back the execution body, while validation-prefix changes remain committed and consumed gas remains chargeable.
That last distinction prevents an overly broad reading of the word revert. An assertion failure is not a promise to restore every aspect of the chain to its pre-transaction state. The specification preserves the payment machinery that makes executing the transaction possible. Its security discussion also warns against putting untrusted actions in that validation prefix, where an assertion cannot undo them.
The information being checked has limits of its own. TXTRACE reports net changes to balances, storage, code and nonces, plus emitted events. Repeated writes to one storage slot collapse into its starting and final values; intermediate writes are not separately visible. Events are not proof that the state they describe changed. A contract can emit a misleading event, which is why the draft treats storage and balance changes as the source of truth.
For integration work, the more consequential question is who makes a particular assertion compulsory. The draft does not require every transaction to include one. Its security section says smart-account validation must require the specific expected assertion frame, and warns that the assertion target should be immutable. Merely finding an assertion somewhere in a transaction would not establish that the account’s intended policy was enforced.
Reference values need similar care. The draft warns that a transaction can manipulate state later used as a threshold, including an oracle value or registry entry. It discusses values fixed at signing time and starting-state values as alternatives, while noting that the starting state can itself change before inclusion. Reading the real final state does not make an attacker-controlled comparison value trustworthy.
This proposal also does not turn a bridge journey into one atomic operation: its checks constrain the transaction carrying them on one chain. Later transactions, earlier approvals and effects on another network remain outside that transaction’s assertion. That scope is separate from the testnet-upgrade scheduling covered in our Glamsterdam article.
The useful role of the Foundation article is explaining the problem. For exact frame ordering, instructions and failure semantics, an implementation discussion needs the live draft and a recorded revision. Keeping those two document roles separate avoids designing against an approachable explanation that no longer matches the specification being evaluated.