Even a properly signed Ethereum transaction can yield a financial outcome that a user would reject if measured against a meaningful loss limit. Research published by the Ethereum Foundation on Oct. 5 explores how transaction assertions could enforce outcome rules, expanding the verification tools available to protocols and wallets.
The core issue involves the origin of these rules and whether the application or service constructing the transaction can dilute them. While a check can evaluate what transpired and decline results falling below a specific minimum, it offers minimal financial defense if the transaction builder configures a permissive minimum threshold.
As of Oct. 9, EIP-7906 exists as a draft. Formulated on Feb. 21, 2025, it relies on frame transactions introduced in EIP-8141. The Hegotá upgrade schedule notes EIP-8141 as slated for inclusion, with EIP-7906 listed under consideration.
Ethereum already enforces some financial limits
Uniswap v3 incorporates an active safeguard today. Its swap router automatically rejects exact-input swaps when the output falls short of amountOutMinimum. For exact-output trades, it blocks spending that exceeds amountInMaximum. These operational conditions are provided directly within the call parameters.
The difference between possessing a condition and selecting a reliable value is highlighted in Uniswap’s single-swap documentation. Its example sets a zero-minimum output while cautioning against using this setting in production, directing developers to price oracles, software development kits, or alternative data feeds for safer figures.
A minimum receipt represents a token amount rather than an assessment of whether a trade constitutes a favorable deal. If a builder establishes a low floor, any result clearing that minimal bar will be accepted. Deriving that floor from an uncompetitive quote merely enforces the limit while preserving a bad trade.
Alternative protections target different facets of the issue. Earlier this year on May 12, 2026, the Ethereum Working Group introduced the Clear Signing standard. This framework supplies structured details for wallets to display to users, backed by independent reviews, attestations, and wallet-approved sources to help signers comprehend requested actions. However, this descriptive layer does not independently enforce minimum financial thresholds.
While simulation predicts outcomes based on a chosen chain state, that state can shift before the transaction lands in a block. Additionally, Safe smart account guards can evaluate parameters beforehand and review post-execution states to halt transactions that violate preset rules.
What Ethereum transaction assertions would add
EIP-7906 proposes a comprehensive evaluation of transaction impacts. It builds upon the ordered frames of EIP-8141—which separate action phases from validation—and appends read-only POST_TX frames to the conclusion. Assertion code evaluates the resulting state and terminates executions that breach defined rules.
The draft divides this functionality into three specific operations: TXTRACE tracks designated events and net adjustments, TXDIFF extracts values via keys, and EVENTDATACOPY supplies event data to the assertion logic. Their scope encompasses native ETH transfers, code hashes, storage updates, and newly created contracts. Verifying token balances requires parsing relevant contract storage to enforce chosen limits.
This mechanism could enable policies that extend beyond simple swap minimums. Accounts could mandate that control configurations remain unchanged, or policies could restrict approvals and verify cross-contract impacts within a routing path.
Evaluations focus strictly on net results. Multiple modifications to a single storage slot condense into initial and final values, while slots restored to their original states are omitted from net-change logs.
Who must require and protect the check
The proposal does not mandate assertions for every transaction. Accounts depending on them must configure validation logic to strictly require the POST_TX frame without allowing bypasses.
Protocols face a corresponding duty. Protected functions must enforce exact required assertions, declining standard transactions or frame setups that omit or alter checks. In settlement mechanisms where solvers dictate execution routes, safeguarding user outcomes requires settlement protocols or signed orders to bind solvers to specific policies. Proposed solver guarantees apply to single transactions on specific networks.
Policies must also withstand the very actions they evaluate. Security recommendations under EIP-7906 advise using immutable, non-upgradeable assertion targets to prevent transactions from altering enforcement contracts between validation and final checks. Guidance also dictates that target validation must precede state modifications.
Even static assertion code can interact with compromised references. Specifications warn against relying on proxies, registries, prices, or external states that execution bodies can manipulate prior to assertion execution. If a trade alters the pricing metric used to judge its own viability, evaluating the ultimate state fails to rectify the comparison.
To counter this, EIP-7906 suggests utilizing reference values that are fixed at the time of signing or captured from state origins when transactions begin. Both strategies prevent execution layers from rewriting references, though standard oracle vulnerabilities persist since prior transactions within the same block can alter initial states.
A rejected outcome would still cost gas
Under this framework, a failed POST_TX check reverts the execution phase while keeping the transaction inside the block. Gas payers remain responsible for consumed fees, and modifications completed during initial validation phases—known as validation prefixes—remain finalized. These can involve actions like account generation or payment approvals.
Operations requiring protection must be placed within segments that assertions can successfully roll back. Placing untrusted execution inside committed validation prefixes leaves those actions unprotected.
Checks must also receive adequate gas allowances to complete. EIP-7906 cautions that tracking events and changes can deplete gas allocations, mandating that out-of-gas interruptions be treated as failed assertions.
The Ethereum Foundation highlights potential use cases involving solver settlements and delegated agents. CryptoSlate previously explored deterministic limits and required assertions in its September coverage of AI wallet permissions.
An effective implementation requires establishing and clarifying mandatory limits and reference points prior to authorization, while blocking builders from altering either. Consequently, Ethereum could execute safety conditions flawlessly while still enforcing unfavorable financial terms.