The Ethereum Foundation published research on October 5 for native transaction assertions, a protocol feature that would let on-chain code inspect every state change a transaction made and undo the whole thing if the result breaks rules the user set in advance. The work comes out of the foundation’s Trillion Dollar Security initiative and targets blind signing, the gap between what a wallet screen shows and what a smart contract actually does.
The problem is old and expensive. A user signs a transaction after reading a summary in a wallet interface. The signature authorizes whatever the underlying calldata specifies, not what the summary said. Attackers have built entire scams around this, dressing malicious approvals up as routine ones, and victims routinely discover the theft only after the funds are gone.
“Ethereum executes what you authorize. But does what you authorize correspond to what you expect? Not always,” the Ethereum Foundation wrote on X. “Today there is no generalized way for onchain code to check what a txn changed and revert it. Native transaction assertions could close this gap.”
How an assertion works
An assertion is read-only logic attached to the transaction itself and signed alongside its actions. After the transaction’s steps run, the assertion compares the starting and final state against a rule. The rule can cover net changes to balances, storage and contract code, plus newly deployed contracts and emitted events. If the comparison fails, the transaction’s execution reverts.
Practical examples from the foundation’s post: require a minimum amount of tokens to arrive in your wallet, cap total spending in one transaction, block any new token approvals, preserve an account’s control logic, or allow only a defined set of changes. An assertion could also confirm that a workflow ended in its intended state, with leftover tokens returned and unused approvals revoked.
The reference design is EIP-7906, which builds on the frame transaction format defined in EIP-8141. A frame transaction separates a transaction into validation and action steps. EIP-7906 adds a POST_TX frame at the end, running as a static call, meaning it can inspect state but not modify it. Three new opcodes give that frame its data: TXTRACE enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies event data into memory.
Storage reporting is net, not raw. A slot written five times in one transaction appears once, with its start and end values. A slot that ends where it started does not appear at all.
| Component | Role |
|---|---|
| EIP-8141 | Frame transaction format, scheduled for the Hegotá upgrade |
| EIP-7906 | Adds POST_TX assertion frame, at Considered for Inclusion stage |
| TXTRACE | Enumerates net state changes and events |
| TXDIFF | Reads start and end values for chosen addresses and slots |
| EVENTDATACOPY | Copies event data into memory for inspection |
The catch: someone has to require it
EIP-7906 does not force any transaction to include an assertion. Whoever builds the transaction can leave it out, which shifts the burden to wallets and protocols. For a user’s own transactions, the wallet has to guarantee every frame transaction it builds carries the required assertion, whether from a simulation it ran or a standing policy on the account.
Protocols can go further. A protected function can refuse any call that does not arrive inside a frame transaction with the exact expected assertion, rejecting ordinary transactions outright. That has limits. An already deployed immutable contract cannot add the check retroactively, and the guarantee holds only within a single transaction on a single chain, so a multi-chain route is not covered.
The foundation also flagged the rule’s source as a weak point. A compromised frontend can write an assertion that permits the attack. A useful rule has to come from independently approved user intent, a standing account policy, or protocol logic that the compromised component cannot change.
If an assertion fails, the transaction stays in the block with a failed status and the gas payer is charged for gas consumed. That detail matters. Without it, attackers could force builders to execute deliberately failing transactions for free, clogging blocks at no cost.
Where it stands
Nothing is live. EIP-7906 is at the Considered for Inclusion stage and has not been confirmed for any network upgrade. EIP-8141 is scheduled for Hegotá, the upgrade expected in 2027, so the frame infrastructure arrives first and the assertion layer may or may not ride along. Preliminary demonstrations have already run on a development network, so the mechanics work outside a whitepaper.
The foundation is collecting feedback from wallet and protocol teams through its Trillion Dollar Security contact and the EIP-7907 discussion thread. Open questions include gas costs, how assertions interact with existing contracts, and whether wallets would adopt the standard in practice.
The idea complements Clear Signing, another Trillion Dollar Security workstream that focuses on making transaction requests readable before approval. Assertions handle the other side of the moment: they check what actually happened after execution. One improves what you see, the other enforces what you get.
If it ships, the practical effect lands hardest on two groups. DeFi users executing complex multi-step swaps get a protocol-level guarantee that the route they approved is the route that ran. Institutions, which have stayed cautious about on-chain operations partly because risk controls are hard to audit when the last line of defense is a user interface, get a check that exists in the same place for everyone rather than varying by wallet vendor.