Ethereum’s proposed safety checks could still let a bad trade through

A correctly signed Ethereum transaction can still deliver a financial result its user would never have accepted under a meaningful loss limit. Ethereum Foundation research published Oct. 5 examines how Ethereum transaction assertions could enforce rules over the outcome, widening the checks available to wallets and protocols.

The decisive question is who supplies those rules and whether the app or service assembling the transaction can weaken them. A check can measure what happened and reject a result below a minimum, yet offer little financial protection if the same transaction builder chooses a permissive minimum.

As of Oct. 9, EIP-7906 remains a draft. It was created Feb. 21, 2025, and depends on EIP-8141's frame transactions. The Hegotá upgrade record lists EIP-8141 as scheduled for inclusion and EIP-7906 as considered for inclusion.

Uniswap v3 has a concrete safeguard today. Its swap router rejects an exact-input swap when the amount received is below the minimum receipt, amountOutMinimum. For an exact-output swap, it rejects spending above the maximum input, amountInMaximum. These are execution-time conditions supplied in the call parameters.

The distinction between having a condition and choosing a sound value appears in Uniswap's own single-swap guide. Its simplified example sets the minimum output to zero, explicitly warns that doing so is risky in production, and points developers toward a software development kit, a price oracle or another data source for a safer value.

A minimum receipt is a token quantity, not a judgment about whether the trade is a good bargain. If a builder sets a floor that permits a very small receipt, an outcome just above that floor passes. Deriving the floor from an already poor quote would preserve that poor bargain while enforcing the limit correctly.

Other protections address different parts of the problem. Earlier this year, the Ethereum Working Group announced the Clear Signing standard on May 12, 2026. It provides structured descriptions that wallets can present to users, with independent reviews and attestations and wallet-selected trusted sources. It helps a signer understand the requested action. That description does not itself impose a minimum financial result.

Simulation predicts effects against a selected chain state. The state can change before the transaction reaches a block. Meanwhile, guards for Safe smart accounts can check parameters before execution and the Safe's final state afterward, blocking transactions under configured rules.

EIP-7906 proposes a broader view of the transaction's effects. It builds on EIP-8141's ordered frames, which separate validation and action steps, and adds read-only POST_TX frames at the end. Assertion code would inspect the resulting state and reject execution that violates its rule.

The proposed instructions divide that work into three operations: TXTRACE enumerates specified net changes and events, TXDIFF retrieves values by key, and EVENTDATACOPY makes event data available to the assertion. Their defined scope includes native ETH balances, storage changes, newly deployed contracts and code hashes. Token-balance checks would need to interpret the relevant contract storage and enforce the selected limit.

That could make policies possible beyond the minimum output of one swap. An account could require its control configuration to remain intact, or a policy could restrict approvals and check effects across contracts involved in a route.

The view is still a net result. Multiple writes to one storage slot collapse into its starting and final values; a slot restored to its original value disappears from the net-change enumeration.

The proposal does not require every transaction to contain an assertion. An account relying on one must configure its validation logic to require the specific POST_TX frame without a bypass.