How native transaction assertions could enforce a transaction's final outcome

The Ethereum Foundation's Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as a user experience risk, and is exploring native transaction assertions as a next step to enforce a transaction’s final outcome, alongside Clear Signing.

This post covers why a valid signature doesn't always guarantee the transaction result you wanted, how native transaction assertions could protect users where today's defenses stop, and the design choices behind them, with EIP-7906 (Transaction Assertions via State Diff Opcode) as one possible approach.

Two ways a signed transaction can go wrong

The problem starts with how Ethereum works. It executes exactly what you authorize, without judging whether the result is what you wanted. A signature commits to a request, but its outcome depends on the code and state it encounters during execution. Users have lost large sums either because they approved something different from what they believed they were approving, or because the request they intended still produced a result they didn’t want.

The first case is an intent mismatch, as seen in the Bybit incident and the BadgerDAO attack. In both attacks, a compromised frontend supplied a signing request that differed from what users believed they were approving. Bybit’s signers authorized replacing the Safe’s implementation contract, while Badger users granted the attacker permission to spend their tokens.