इथेरियम के प्रस्तावित सुरक्षा चेक अभी भी एक खराब ट्रेड को पास होने दे सकते हैं

Even an Ethereum transaction carrying a proper signature can yield a financial outcome that its user would reject if measured against a significant loss threshold. Research released by the Ethereum Foundation on Oct. 5 explores how transaction assertions could enforce rules regarding final results, thereby expanding the safeguard options available to protocols and wallets.

The core dilemma centers on who provides these rules and whether the application or service putting the transaction together can dilute them. While a check can evaluate what took place and decline a result falling below a minimum, it offers minimal monetary protection if that same transaction builder opts for a lax minimum.

As of Oct. 9, EIP-7906 exists as a draft. Formulated on Feb. 21, 2025, it relies on the frame transactions introduced by EIP-8141. The Hegotá upgrade schedule lists EIP-8141 for potential inclusion, while EIP-7906 is under consideration.

Ethereum already enforces some financial limits

Uniswap v3 features an active safeguard today. Its swap router turns down an exact-input swap if the received amount falls short of the minimum receipt, designated as amountOutMinimum. For exact-output swaps, it halts spending that exceeds the maximum input, amountInMaximum. These represent execution-time requirements supplied inside the call parameters.

Uniswap’s own single-swap documentation highlights the difference between establishing a condition and picking a reliable figure. Its basic example sets the minimum output at zero, explicitly cautions that doing so creates production risks, and directs developers to use a price oracle, a software development kit, or another data feed to find a safer number.

A minimum receipt represents a token quantity rather than a judgment on whether a trade constitutes a favorable deal. If a builder establishes a floor permitting a meager receipt, any outcome just above that floor will succeed. Deriving that floor from an already unfavorable quote simply locks in that poor trade while correctly enforcing the limit.

Alternative safeguards target different facets of the issue. Earlier in the year, the Ethereum Working Group introduced the Clear Signing standard on May 12, 2026. This framework supplies structured descriptions that wallets can display to users, supported by independent reviews, attestations, and trusted sources chosen by the wallet. It assists a signer in grasping the requested operation, though the description itself does not mandate a minimum financial outcome.

Simulation evaluates projected effects against a chosen chain state, though that state can shift before the transaction lands in a block. Meanwhile, guards designed for Safe smart accounts can inspect parameters prior to execution and evaluate the Safe’s final state afterward, halting transactions that violate predefined configurations.

What Ethereum transaction assertions would add

EIP-7906 advocates for a broader perspective on the consequences of a transaction. It builds upon the ordered frames defined in EIP-8141—which separate action steps from validation—and appends read-only POST_TX frames at the conclusion. Assertion code would then evaluate the resulting state and block any execution violating its directives.

The proposed instructions divide this responsibility across three distinct operations: TXTRACE lists specific net changes and events, TXDIFF pulls values via keys, and EVENTDATACOPY feeds event data directly into the assertion. Their designated scope encompasses native ETH balances, storage modifications, newly deployed contracts, and code hashes. Checking token balances would require interpreting relevant contract storage and enforcing the chosen limit.

This capability could unlock policies extending beyond the minimum output of a single swap. An account could mandate that its control settings remain unaltered, or a policy could restrict approvals and monitor effects spanning multiple contracts involved in a routing path.

This perspective remains focused on net outcomes. Multiple writes directed at a single storage slot collapse into its initial and final values, while any slot restored to its original state vanishes from the net-change log entirely.

Who must require and protect the check

The proposal does not make assertions mandatory for every transaction. Any account depending on one must configure its validation rules to demand the specific POST_TX frame without allowing bypasses.

Protocols face a corresponding duty. Their protected functions must enforce the precise required assertion, turning down standard transactions as well as frame transactions that lack or misconfigure the checks. In settlement mechanisms where a solver determines the trade execution path, safeguarding a user’s outcome necessitates that the signed order or settlement framework binds the solver to that policy. The proposed solver guarantee functions for a single transaction on a single network.

Policies must also endure the actions they are meant to oversee. Security guidance under EIP-7906 advises using immutable, non-upgradeable assertion targets. Without this restriction, a transaction could modify the enforcement contract after validation concludes but before the final check executes. Furthermore, the guidance specifies that validating the intended target depends on conducting checks prior to any state alterations.

Even unchanged assertion code can ingest a compromised reference point. The specification highlights risks surrounding prices, registries, proxies, and other state data that the execution body can manipulate before the assertion runs. If a trade alters the price used to evaluate whether its outcome is acceptable, reading the actual final state fails to salvage the comparison.

To counter this, EIP-7906 recommends utilizing reference values that are locked in at the time of signing or retrieved from the state at the transaction’s onset. Both strategies prevent the execution body from rewriting the reference, though standard oracle risks persist because prior transactions within the same block can alter that starting state.

A rejected outcome would still cost gas

Under this framework, a failing POST_TX check will revert the execution body, though the transaction stays inside the block. The gas payer continues to incur charges for the consumed gas, and modifications occurring during the initial validation steps—known as the validation prefix—remain committed. These can involve actions like payment approvals or account creation.

Operations intended for protection must reside within the segment that the assertion can roll back. Placing untrusted execution inside the committed validation prefix leaves those actions entirely unprotected.

Additionally, checks require an adequate gas allocation to finish executing. EIP-7906 cautions that enumerating changes and events can deplete its budget, specifying that any incomplete execution resulting from out-of-gas conditions must be treated as an assertion failure.

The Foundation outlines potential use cases involving delegated agents and solver settlements. Previous coverage by CryptoSlate in September concerning AI wallet permissions similarly explored deterministic limits and required assertions.

A meaningful implementation requires clarifying the mandated limit and its reference source prior to authorization, followed by measures preventing builders from weakening either element. Consequently, Ethereum could execute a safety condition flawlessly while still enforcing an unfavorable financial bargain.

?अक्सर पूछे जाने वाले प्रश्न

01What is EIP-7906?

EIP-7906 is a draft proposal that introduces transaction assertions to Ethereum, allowing wallets and protocols to enforce rules over the outcome of a transaction using read-only POST_TX frames.

02Do transaction assertions completely prevent bad trades?

No. While assertions can enforce specific rules or minimum limits, they cannot stop a bad trade if the transaction builder or user sets a permissive or unfavorable minimum threshold.

03Will failed assertions refund gas fees?

No. If a POST_TX check fails and reverts the execution body, the transaction remains in the block, and the gas payer is still charged for the consumed gas.

04What is EIP-8141?

EIP-8141 introduces ordered frames that separate validation and action steps in Ethereum transactions, providing the foundational structure that EIP-7906 builds upon.