Full article
Authorization and acceptable results answer different questions
The Ethereum Foundation discussed transaction assertions on October 5, 2026. The motivating distinction is between approving a request and accepting its consequences. A signature establishes authorization; it does not express every economic expectation a person had while looking at an application. Think of an instruction to a contractor: permission to begin work and the conditions for accepting delivery are separate parts of the agreement. This distinction matters when software executes against circumstances that may differ from the preview presented before authorization.
Turn expectations into testable conditions
The research explores checking execution outcomes and rejecting those that violate specified conditions. EIP-7906 describes a candidate mechanism for inspecting state differences and remains a draft. A useful condition must identify what is measured and how it is compared. “Do not lose money” is ambiguous: it could mean token quantity, value at a reference price, or future purchasing power. A numerical balance test can address the first meaning without settling the others. The design therefore needs precise expressions of intent rather than a general promise that the trade will be good.
A minimum receipt is only one boundary
Consider a hypothetical exchange of 100 units of token A with a requirement to receive at least 95 units of token B. Receiving 94 should fail that condition; receiving 96 should satisfy it. Now suppose the operation also creates an unwanted continuing permission. The receipt condition alone says nothing about that additional effect. This example separates three possible concerns: maximum spending, minimum receipt, and changes to permissions. A protection rule covers the things it actually specifies. Passing one test cannot be treated as evidence that every consequence matches the user’s expectations.
The origin of a condition matters
Imagine a malicious interface silently changing that minimum receipt to zero. Perfect execution of the resulting rule would still provide poor protection. The wallet therefore needs a reliable way to obtain the intended condition and show it meaningfully to the person approving it. Strictness also has a practical cost. Very tight limits may reject otherwise acceptable operations during ordinary price movement; repeated failures may encourage a user to weaken them. Our analysis is that expressing the condition and maintaining its integrity are as important as evaluating it correctly after execution.
A proposal is not a universal wallet feature
The source describes a research direction, not a protection already available in every Ethereum wallet. Even a deployed implementation would not become a general refund service or undo unrelated transactions completed earlier. The useful advance is a vocabulary for acceptable outcomes that supplements authorization. The remaining product questions include who creates the rules, whether they are mandatory, and what users experience when execution is rejected. Costs and failure behavior must be checked against the actual specification and implementation, rather than inferred from the attractive idea of an outcome guarantee.