Ethereum Proposal Could Block Bad Trades-If Limits Are Sound

Ethereum Foundation research published Oct. 5 examined EIP-7906, a draft proposal for checking the financial results of Ethereum transactions. The checks could reject a transaction when its result falls below a predefined limit. A wallet, app or transaction builder could reduce that protection by setting the limit too low.

EIP-7906 remained a draft as of Oct. 9. Created Feb. 21, 2025, it depends on EIP-8141, which introduces frame transactions that separate transaction validation from transaction actions. EIP-8141 is listed for inclusion in the Hegotá upgrade, while EIP-7906 is listed for consideration.

The proposal would add read-only POST_TX frames at the end of a transaction. These frames would inspect the resulting state and revert the transaction’s execution body when a stated rule was not met. Proposed TXTRACE, TXDIFF and EVENTDATACOPY operations would provide information about balance changes, storage updates and event data.

The checks could cover native ETH balances, storage changes, newly deployed contracts and code hashes. Token-balance checks would require the assertion to interpret storage used by the relevant token contract. A policy could therefore check account settings, approvals and effects across several contracts in a transaction route.

EIP-7906 would not require every transaction to include an assertion. An account using one would need validation logic that requires the specific POST_TX frame and blocks a bypass. Protocols would need to reject transactions that omit the required check or include an incorrect one.

When a solver selects a transaction’s execution route, the user’s signed order or the settlement protocol would need to bind the solver to the stated policy. The proposed solver guarantee would apply to one transaction on one network.

The research separates enforcement from the choice of the limit. A check can reject a swap that returns less than a specified amount, but it cannot determine whether that amount represents a fair trade. An unfavorable result would pass if it exceeded a low minimum chosen by the transaction builder.

Uniswap v3 already uses similar execution-time conditions. Its router rejects an exact-input swap when the received amount falls below amountOutMinimum. It rejects an exact-output swap when spending exceeds amountInMaximum. Uniswap’s development guide gives a simplified example with a zero minimum output and warns that the setting is unsafe for production use.

EIP-7906 would require the assertion target to be immutable or otherwise protected from changes. The transaction body must not be able to alter the contract enforcing the rule before the final check. The reference used for comparison must receive similar protection. For example, a transaction could change a price, registry or other data source before the assertion reads it.

The proposal recommends fixing reference values when the transaction is signed or reading them from the state at the transaction’s start. Earlier transactions in the same block could still change that state before execution.

A failed POST_TX check would revert the execution body, but the transaction would remain in the block and the gas payer would be charged for gas used. Changes made during the validation prefix, including payment approvals or account creation, could remain committed. Actions requiring protection would need to occur in the part of the transaction that the assertion can roll back.

The assertion would need enough gas to inspect changes and events. If it runs out of gas before completing, EIP-7906 treats the check as failed. The Ethereum Working Group’s Clear Signing standard, announced May 12, 2026, could help wallets describe requested actions to users, but it would not impose a minimum financial result.