When the wallet pops up a signing window, users usually confirm what action they want to perform, but it is difficult to guarantee what the final result of the transaction will be. A research article by the Ethereum Foundation on October 5th referred to this discrepancy as the uncertainty of transaction outcomes and discussed a native transaction assertion: after the transaction is executed and the state is truly established, read-only rules on the blockchain are used to check the results; if the results violate independently set constraints beforehand, the execution will be rolled back. This solution is still in the design and discussion phase. EIP-7906 is just one of the possible approaches, and it has not been determined whether it will be implemented in the upgrade, let alone considered a new security feature already available on the main Ethereum network.

Why is this issue worth discussing? Signatures typically lock in the target address, amount, and call data, but not the entire contract code and on-chain state at the time of execution. Proxy contracts may change their implementation after a signature is made, and transaction sorting could alter pool prices, resulting in simulated outcomes that differ from those when the transactions are actually included in a block. Smart contracts faithfully execute the calls signed by users, but they do not assess whether the economic objectives have been achieved on behalf of the users. Examples cited by the foundation include cases where frontends induced users to sign authorizations that were different from what was expected, as well as situations where users signed correct orders but ended up with very poor exchange results. These issues fall under "mismatch between signing intent" and "mismatch between transaction results," respectively, and should not be confused.

Why are transparent signatures and simulations not enough?

Transparent signatures can translate complex calls into actions that humans can understand, reducing unauthorized authorization; however, they still rely on the front-end to decode them correctly and on users to notice any anomalies, and they mainly explain "what request is being made." Models can predict the results under a certain selected chain state, but they cannot guarantee that the state will remain unchanged later when the transaction is included in a block, nor can they prevent the signature process from having its content replaced by malware. Existing mechanisms such as the minimum output of contracts and wallet guards can indeed check for specific conditions during execution, but they require prior knowledge of which state to monitor, and may not be able to see all the net changes caused by a transaction. The new proposal aims to expand this range of observation, rather than declaring that the old defenses are worthless.

The foundation envisions a native assertion where a read-only rule is signed in together with the transaction action. After the action is executed, the assertion compares the net changes in balances, storage, code, and events before and after the transaction. If the amount received is below the minimum value, the expenditure exceeds the limit, unauthorized permissions are granted, or the wallet control logic is modified, the rule can trigger a rollback of the execution. The key here is not just "an additional judgment statement," but also that this judgment occurs after the actual execution results have been produced, allowing for the identification of state differences that are not easily accessible through ordinary contracts in the past. For automated transactions, entrusted agents, or complex routing, users can specify result limits that are more explicit than what is simply displayed on the front end.

The technical approach proposed by EIP-7906 is built upon the EIP-8141 framework for transactions. It adds a read-only POST_TX phase at the end, which uses new commands to enumerate changes in net state, read specific storage differences, and event data. Currently, it is only listed as a consideration for upgrades and has not been finalized yet. Even if it is adopted in the future, this proposal will not mandate that each transaction include assertions; wallets and protocols must request them voluntarily. If a malicious front-end has control over both the transaction structure and the assertion text, they could create a rule that allows attacks to occur, thereby compromising security. Truly reliable constraints should come from independently confirmed user intentions, long-term wallet policies, or mandatory requirements of the called protocols.

This also explains why “paying a fee even when a transaction fails” is not considered a design flaw. If an assertion fails, the execution action is rolled back, but the transaction still remains in the blockchain in a failed state, and the payer still has to bear the consumed Gas. Otherwise, attackers could cause block builders to repeatedly execute expensive and doomed-to-fail transactions for free. For users, this means that assertions reduce the risk of unwanted state changes, rather than making all failed attempts cost-free. For the protocol, if mandatory protection is to be implemented, it is also necessary to reject ordinary transactions without specified assertions; contracts that have already been deployed and are not upgradable may not be able to incorporate this level of checking.

Security returns depend on who writes the rules.

Transaction assertions are often mistakenly perceived as a universal “regret button.” They can only check the outcome of a single transaction or within a single network, and they cannot cover the entire settlement process across different chains, nor can they guarantee that the rules themselves are correct. For example, even if a user sets a minimum exchange amount, the transaction may still fail due to a thin market; even with a list of allowed contracts set, someone is needed to maintain that list and understand the risks associated with upgrades. The foundation points out that in certain proxy execution scenarios, it is possible to first limit what a proxy can call and how much it can spend, and then use assertions to restrict the final state; these two layers of constraints complement each other. If a user has no idea of the price range they are willing to accept, the on-chain rules cannot make economic decisions on their behalf.

The foundation is currently inviting wallet and protocol teams to participate in the design. The article discusses how to fill the gaps in risk control, rather than an official activation announcement. For readers, short-term practical measures still include reviewing the content of signatures, setting reasonable slippage and limits, being wary of unauthorized actions, and remembering that simulations are merely snapshots of the current state. In the long run, if native assertions can lead to compatible wallets, contracts, and standards, transaction protection may extend from “understanding requests” to “ensuring that results do not exceed boundaries.” However, before the proposal is confirmed, implementation is audited, and it is actually deployed, it remains a research direction, not insurance that has already been installed for all Ethereum users.

This research also poses a more difficult question for wallet products than the new directives: how to enable ordinary people to understand the “range of outcomes” they are authorizing. If the interface only displays a long list of contract addresses and storage slots, users cannot independently confirm whether the rules are correct; if the interface simplifies the rules too much, it may overlook key exceptions. A truly usable solution needs to align what users can understand about budgets, minimum amounts to be received, and allowed operations with the strict state checks that machines can enforce, and it must also be able to explain reasons for failures. Whether security mechanisms can be integrated into mainstream wallets ultimately depends on the credibility of this translation, rather than the proposal number itself.