Ethereum developers are considering a proposal called EIP-7906 that would let accounts inspect what a transaction actually did before accepting the final result. The idea is to give users and smart accounts a network-level way to reject harmful or unexpected outcomes after execution has occurred, rather than relying only on what was shown before signing.
The proposal, also described as “transaction assertions,” is aimed at a long-standing weakness sometimes called de facto blind signing. Today, Ethereum validates the signed transaction data itself, but not whether the eventual on-chain effects match what a wallet interface or simulator suggested would happen.
Why the proposal exists
Under Ethereum’s current model, a signature authorizes execution of the submitted calldata, not the transaction outcome. That means a wallet, interface, or simulation tool can present incomplete or incorrect expectations, yet the network will still process the transaction if the signed input is valid.
EIP-7906 is intended to narrow that gap. Instead of leaving users dependent on previews alone, it would introduce a built-in mechanism for checking the final effects of a transaction and refusing them if they differ from what the account expected.
How transaction assertions would work
The proposal adds a verification mode built around a POST_TX frame placed at the end of a frames list. This frame would run as a static call after the rest of the transaction execution, when the actual consequences of that execution can be inspected.
Inside that POST_TX frame, three new opcodes are proposed: TXTRACE, TXDIFF, and EVENTDATACOPY. These opcodes would only be available there and would expose information about what happened during the transaction, including balance changes, storage changes, and emitted event data.
If those observed outcomes failed to match the transaction’s assertions, the execution frames could be reverted. In effect, the account would gain an on-chain veto over the final result, based on what truly happened rather than on a pre-transaction estimate.
Potential uses and limits
The article points to several practical uses for the feature. A swap could be constrained so it only succeeds if it executes as intended, and an account interacting with an NFT mint could reject an approval drainer if the post-transaction checks reveal suspicious behavior.
Because the checks would use the real transaction trace and diffs, they would not depend entirely on potentially flawed wallet displays or simulation outputs. Even so, the proposal is not presented as a complete fix for every Ethereum security problem. Its value would be in reducing a broad class of losses tied to unexpected on-chain behavior.
Status and possible timeline
EIP-7906 has already been demonstrated on a Devnet and is being proposed for inclusion in Ethereum’s Hegotá upgrade. That places it in the category of an active protocol design under discussion rather than a finalized mainnet feature.
According to the source article, the proposal could be scheduled for a future Ethereum upgrade, with 2027 described as a possible earliest mainnet deployment. For now, the next confirmed step is continued consideration in the upgrade process and further work around its inclusion.
Source: www.bankless.com