Ethereum already enforces some financial limits
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.
What Ethereum transaction assertions would add
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.
Who must require and protect the check
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.
A protocol has a related obligation. Its protected function would need to enforce the exact required assertion, rejecting ordinary transactions and frame transactions with missing or incorrect checks. In settlement flows where a solver chooses the trade’s execution route, protecting a user’s outcome requires the signed order or settlement protocol to bind the solver to the policy. The proposed solver guarantee applies to one transaction on one network.
The policy must also survive the actions it is supposed to judge. EIP-7906’s security guidance calls for immutable, non-upgradeable assertion targets. Otherwise, a transaction could alter the enforcement contract after validation and before the final check. The guidance also makes clear that validating the intended target depends on validation occurring before state changes.
Even unchanged assertion code can read a compromised reference. The specification warns about prices, registries, proxies and other state that the execution body can modify before the assertion runs. If a trade shifts the price used to decide whether its own result is acceptable, reading the real final state does not rescue the comparison.
EIP-7906 recommends reference values fixed at signing or drawn from the state at the transaction’s start. Both approaches keep the execution body from rewriting the reference. The usual oracle risks remain because earlier transactions in the same block can move that starting state.
A rejected outcome would still cost gas
Under the proposal, a failing POST_TX check would revert the execution body. The transaction would remain in the block. The gas payer would remain charged for consumed gas, and changes in the initial validation steps, known as the validation prefix, would remain committed. These can include payment approval or account creation.
Actions meant to be protected must sit in the part that the assertion can roll back. Putting untrusted execution in the committed validation prefix would leave it outside that protection.
The check also needs enough gas to finish. EIP-7906 warns that enumerating changes and events can exhaust its budget and requires an incomplete out-of-gas check to be treated as assertion failure.
The Foundation describes potential applications in delegated agents and solver settlement. CryptoSlate’s September coverage of AI wallet permissions already discussed deterministic limits and required assertions.
A meaningful implementation would make the required limit and its reference clear before authorization, then prevent the builder from weakening either. Ethereum could enforce a safety condition perfectly while still enforcing the wrong financial bargain.
