Ethereum’s Draft Transaction Checks Cannot Guarantee Safe Trades
EIP-7906 would inspect balance, storage, code and event changes after execution, but protection would depend on rules that the transaction builder cannot omit or alter.

A draft Ethereum proposal would let wallets and protocols inspect a transaction’s final balance, storage, code and event changes, but it would not guarantee economically safe trades unless the rules are protected from the transaction builder’s ability to omit or alter them.
EIP-7906 proposes three Ethereum Virtual Machine instructions — TXTRACE (0xb6), TXDIFF (0xb7) and EVENTDATACOPY (0xb8) — for examining changes made during a transaction. The instructions would operate inside a read-only POST_TX frame placed at the end of a frame transaction.
The design would allow an assertion to evaluate the completed execution and reject an outcome that violates a specified condition. If the assertion fails, the transaction’s execution body would be reverted, while the transaction itself would remain valid and included in the block.
Gas consumed before the failure would still be charged. The validation prefix, including gas payment and possible account creation, would remain committed.
The proposal does not require every transaction to contain a POST_TX assertion. Smart-account validation logic would instead need to require specific checks and reject transactions that omit them or use incorrect rules.
A check is only as reliable as the policy used to define it. A transaction can contain a valid numerical limit while still allowing an economically harmful trade if the person assembling the transaction can remove the check or change its terms.
EIP-7906 recommends that assertion targets be immutable and non-upgradeable. It also warns that execution could modify an oracle, registry, proxy or other reference before the assertion runs, potentially steering the check toward an unsafe result.
Comparison values could be fixed when the transaction is signed or taken from the start of the transaction. Transaction-start oracle values could still be manipulated by earlier transactions in the same block.
The design extends the idea behind existing swap protections. A swap can specify the minimum amount received for an exact-input trade or the maximum amount paid for an exact-output trade. Setting the minimum output to zero satisfies the mechanics of a check but offers little economic protection and is risky in production.
EIP-7906 would broaden post-transaction checks beyond a single swap parameter. Assertions could compare net changes across multiple contracts, restrict approvals, preserve account-control settings or cap spending.
The main risk is a false sense of security. A check can correctly reject an outcome below a stated threshold, but it cannot determine whether that threshold reflects the user’s actual intent unless the value is independently approved and protected from the party assembling the transaction.
The proposal was created Feb. 21, 2025, and remains marked “Draft.” It requires EIP-8141, which is scheduled for the Hegotá upgrade, while EIP-7906 has not been confirmed for inclusion.
EIP-7906 has no announced implementation date or deployment timeline and is not active on Ethereum mainnet.