The Ethereum Foundation is exploring transaction assertions that would let users attach enforceable conditions to a transaction’s final outcome, rather than relying only on approval of the requested action. The research, part of its Trillion Dollar Security initiative, targets a gap in transaction safety: a valid signature does not guarantee that the resulting balances, permissions or account controls match what the signer intended.
Key Takeaways
- The proposed checks would evaluate transaction results during execution and reverse actions that breach a signed rule.
- Protection depends on rules approved independently of a potentially compromised transaction builder.
- The research could support wallet safety policies, delegated agents and solver workflows, but it is not an announced deployment.
Table of Contents
- Why approving a transaction can still produce a loss
- How transaction assertions would check the result
- What the proposed implementation would expose
- Where wallets and protocols would need to change
- What agents and solver workflows could gain
- Conclusion
Why approving a transaction can still produce a loss
Ethereum executes the request a user authorizes against the code and state available when it runs. Those conditions can differ from what the user inspected. A proxy implementation can change before execution, for example, while transaction ordering can alter the price a swap encounters.
The foundation distinguishes misleading requests from unwanted results. In the Bybit and BadgerDAO attacks, compromised frontends presented signing requests that differed from what users believed they were approving. By contrast, an accurately displayed request can still permit an economically damaging outcome.
Its example is an Aave and CoW collateral swap involving about $50.4 million of aEthUSDT. Thin AAVE liquidity and CoW’s gas ceiling left a verified quote of roughly 329 aEthAAVE. Despite a displayed 99.9 percent price-impact warning and confirmation that the entire value could be lost, the user signed and received tokens worth about $36,000.
That distinction explains why better transaction descriptions are not the whole answer. Clear Signing helps users understand the requested action. Simulation estimates effects against a selected chain state. Neither alone imposes an independent condition on the result that actually occurs.
| Item | Details |
|---|---|
| TXTRACE | Enumerates the transaction’s net state changes and emitted events. |
| TXDIFF | Retrieves starting and final values for specified addresses and storage slots. |
| EVENTDATACOPY | Copies an event’s data into memory for inspection. |
| Deployment information | The proposed state-change data includes newly deployed contracts and their code hashes. |
How transaction assertions would check the result
An assertion would compare a transaction’s starting and final state using read-only logic after its actions have run. The condition would be included in the transaction and signed with the actions. Failure would cause those actions to revert.
Possible rules include a minimum amount received, a spending ceiling, restrictions on new token approvals or preservation of an account’s control logic. The proposed inspection capability extends beyond balances to storage, code, newly deployed contracts and emitted events.
Existing contract checks already protect selected outcomes. Uniswap can reject swaps below a specified minimum output, and a Safe guard can inspect account state after execution. The limitation is visibility: such checks must anticipate what to examine and generally depend on the interfaces other contracts expose. A proxy, for instance, need not provide a function revealing its implementation address.
Native assertions would make the transaction’s complete net effects available for checking, including changes an ordinary guard might not know to look for. But broader visibility is useful only if the rule is trustworthy. A malicious frontend could supply a condition that permits its own attack, so the policy must come from independently approved intent, account policy or protected protocol logic.
What the proposed implementation would expose
The foundation’s announcement on native transaction assertions describes EIP-7906 as a possible implementation, not a settled design. It builds on the frame transactions in EIP-8141, which arrange validation and action steps in an ordered sequence. EIP-8141 is scheduled for Hegotá; EIP-7906 has reached Considered for Inclusion but is not confirmed for that upgrade.
Under this approach, a read-only POST_TX frame would inspect results at the end of execution. The proposed data-access instructions would operate only within that frame, rather than throughout the EVM.
The information would describe net effects, not a history of every intermediate write. A storage slot changed repeatedly would appear with its starting and final values; a slot restored to its original value would not appear. This makes the distinction between final-state enforcement and monitoring every execution step important.
If a check failed, the execution body would revert, but the transaction would remain in the block as failed. The gas payer would still pay for gas consumed, preventing deliberately failing transactions from imposing free execution work on builders.
Where wallets and protocols would need to change
The proposal supplies a checking mechanism, not an automatic requirement to use it. For a user’s transactions, the wallet would have to make its safety policy part of transaction construction instead of leaving the builder free to omit it. That policy could derive from the wallet’s own simulation or apply as a standing account rule.
For protocols, protection would have to be built into the conditions for accessing a protected function. Supplying an assertion-capable transaction would not be enough: the call would need to carry the particular check the protocol demands. This would change integration requirements for callers, while already deployed immutable contracts could not retrofit that admission check.
These dependencies separate a potentially powerful EVM capability from a user-facing guarantee. Effective protection would require both a sound condition and software that consistently makes that condition unavoidable.
What agents and solver workflows could gain
Delegated agents could be constrained by results as well as permissions. Limits on which contracts an agent may use or how much it may spend could be supplemented with requirements governing what each transaction leaves behind.
For solver-based execution, a protocol could specify an acceptable outcome while allowing the solver to choose the route. The guarantee would be confined to a transaction on a single network, not a route spanning multiple chains.
Assertions could also check workflow cleanup, such as returning unused tokens and revoking remaining approvals. The foundation is seeking input from wallet and protocol teams as the design continues, making these potential applications research directions rather than announced product features.
Conclusion
Native transaction assertions would shift part of Ethereum transaction safety from interpreting a request to enforcing its result. Their practical value would depend on trustworthy policies and adoption by the wallets and protocols responsible for applying them.
Read More News
Disclaimer
This FinanceVelix article provides general information, not personalized financial, investment, legal, or tax advice. Crypto prices can change quickly, and you could lose all invested funds. Facts reflect the material available when published and may change. Check important information independently and consult a qualified professional when needed. Mentioning an asset, company, or service is not an endorsement.
