Ethereum Foundation makes the case for transaction assertions that revert when the outcome is wrong
Victoria Shinder2 min readThe Ethereum Foundation's Trillion Dollar Security initiative published on 5 October its case for native transaction assertions: rules, signed together with a transaction, that check the transaction's final outcome and revert it if the outcome is not what the user agreed to.
The problem. Ethereum executes exactly what is signed, and a signature commits to a request, not its result. The post separates two failures. In an intent mismatch, a compromised frontend presents one request while the user approves another, as in the Bybit and BadgerDAO incidents. In an outcome mismatch, the user approves the right request but the state it runs against produces a result they would not have accepted: in an Aave–CoW collateral swap, a user swapping about $50.4 million of aEthUSDT received tokens worth about $36,000 after confirming a 99.9% price-impact warning.
Why existing defences stop short. Clear Signing explains the request but depends on accurate decoding; simulation predicts effects against a chosen state that can change, and in the Radiant Capital case malware swapped the payload at signing time. Contract checks such as Uniswap's amountOutMinimum and Safe's checkAfterExecution guard work, but only on state chosen in advance; none can ask the EVM what else changed.
The proposal. EIP-7906 builds on the frame transactions of EIP-8141 and adds a read-only POST_TX frame at the end. Three new opcodes expose the outcome: TXTRACE enumerates net state changes and events, TXDIFF returns start and final values for given addresses and slots, and EVENTDATACOPY copies event data into memory. Changes are net: a slot written five times appears once, and a slot restored to its original value does not appear. If the assertion fails, the execution reverts but the transaction stays in the block as failed and the gas payer is charged, so attackers cannot make builders run failing transactions for free.
Limits the authors state. An assertion is only as good as its source; a compromised frontend can write one that permits the attack. EIP-7906 does not make assertions mandatory, and an already deployed immutable contract cannot require them. EIP-8141 is scheduled for the Hegotá upgrade; EIP-7906 is "Considered for Inclusion" but not confirmed.