Ethereum wallets have spent years trying to help users understand what they are signing.
The Ethereum Foundation now wants to go one step further:
make the chain enforce whether the result matches what the user meant to achieve.
On October 5, the Ethereum Foundations Access Cluster published a research proposal around native transaction assertions as part of its Trillion Dollar Security initiative.
The problem is subtle.
A cryptographic signature proves that a user authorized a transaction request.
It does not guarantee that the transaction will produce the economic or security outcome the user expected.
Code can change.
State can change.
A frontend can be compromised.
Liquidity can disappear.
A solver can choose a route that is technically valid but economically disastrous.
Native transaction assertions would add a separate rule over the transactions final state. If the transaction produces an outcome that violates that rule, execution would revert.
That is a meaningful shift from understanding the request to constraining the result.
A Valid Signature Can Still Produce the Wrong Outcome
The Ethereum Foundation divides failures into two broad classes.
The first is an intent mismatch.
The user believes they are approving one action, but the payload they sign does something else.
The Foundation cites incidents such as Bybit and BadgerDAO, where compromised interfaces led users or signers to authorize dangerous permissions or implementation changes.
The second is an outcome mismatch.
The transaction really is what the user intended to request, but the final economic result is unacceptable.
The Foundation points to a roughly $50.4 million Aave/CoW collateral swap in which a user ultimately received only around $36,000 worth of the target asset after an extreme price-impact scenario.
The interface displayed a 99.9% price-impact warning.
The user signed anyway.
From the EVMs perspective, nothing was necessarily wrong.
The transaction executed what was authorized.
From the users economic perspective, the outcome was catastrophic.
That gap is what transaction assertions target.
Clear Signing and Simulation Are Necessary but Incomplete
Clear signing tries to translate calldata into something understandable.
Simulation tries to predict what a transaction will do against a particular chain state.
Both help.
Neither can guarantee the final result.
Simulation can become stale before inclusion.
Transaction ordering can change pool prices.
A proxy implementation can change.
Malware can substitute a different payload at signing time.
A wallet can also simulate the wrong transaction if the signing environment itself is compromised.
Assertions add another layer:
regardless of how we got here, did the final state satisfy an independently defined rule？
That is a stronger security property.
What an Assertion Could Enforce
The Foundation describes rules that could inspect the net state changes produced by a transaction.
Examples include:
- receive at least a minimum amount;
- spend no more than a fixed amount;
- create no new token approvals;
- preserve a Safes implementation or control logic;
- allow only a specific set of storage changes;
- require unused tokens to return to the user;
- ensure temporary approvals are revoked.
The rule can examine final balances, storage changes, deployed code and emitted events.
If the assertion fails, the transaction actions revert.
The transaction can still consume gas.
That prevents attackers from forcing block builders to execute deliberately failing logic for free.
EIP-7906 Is One Possible Implementation
The Foundation emphasizes that the design is still under discussion.
EIP-7906 is one proposed mechanism.
It builds on EIP-8141 frame transactions.
A frame transaction contains ordered validation and action steps.
EIP-7906 adds a read-only POST_TX frame after the actions have executed.
That frame can inspect what changed.
The proposal defines new EVM instructions including TXTRACE, TXDIFF and EVENTDATACOPY for accessing state changes and events.
EIP-8141 is scheduled for Ethereums Hegotá upgrade.
EIP-7906 has advanced to “Considered for Inclusion,” but it has not been confirmed.
That means transaction assertions should be treated as active protocol research, not a feature users can rely on today.
The Rule Source Is the Critical Security Assumption
Assertions are not magic.
A compromised frontend can also provide a compromised assertion.
If the same malicious system chooses both the transaction and the safety rule, it can simply write a rule that permits the attack.
The assertion must therefore come from an independent source of intent.
That can be:
- a wallet policy;
- a user-approved rule;
- a protocol-enforced condition;
- an account-level spending policy.
This may be the most important design insight in the proposal.
Security improves only when the outcome constraint is independent from the component that might be compromised.
Wallets and Protocols Must Actually Require Assertions
EIP-7906 would not automatically protect every Ethereum transaction.
A wallet must insist on including the appropriate assertion.
A protocol that wants to protect callers must reject transactions that do not contain the required rule.
Existing immutable contracts cannot simply gain a new assertion requirement without a compatible upgrade path.
This means adoption becomes a coordination problem.
The EVM can expose the mechanism.
Wallets, smart accounts, protocols and solver systems still need to use it.
Why It Matters
Crypto has traditionally treated the signature as the ultimate expression of consent.
That model is increasingly weak for complex onchain finance.
Users sign through:
- smart accounts;
- multisigs;
- solver networks;
- AI agents;
- automation;
- delegated permissions.
The person signing may no longer understand every execution detail.
A better security model is to separate what can be called from what result is allowed.
That is especially important for agentic finance.
An AI agent may be allowed to trade on a users behalf, but the user can still demand:
- maximum daily spend;
- approved protocols only;
- minimum received value;
- no permanent approvals;
- no change to account ownership.
Assertions can convert those policies into execution constraints.
Risks and Counterarguments
The proposal is not finalized.
Assertions add transaction complexity and gas cost.
Poorly designed rules can block legitimate transactions.
Overly broad rules provide little protection.
The independent-policy layer can itself be compromised.
Cross-chain workflows are not fully solved because a single Ethereum transaction assertion only sees one transaction on one network.
And protocol adoption can be slow.
The concept improves security only when the entire transaction path respects the rule.
What to Watch Next
Watch whether EIP-7906 is formally included in Hegotá or a later upgrade.
Also watch:
- smart-wallet support;
- Safe integration;
- solver protocols;
- AI-agent wallets;
- standard libraries for common assertions;
- independent policy engines.
The strongest sign of adoption will be wallets offering default outcome protections that users can understand without writing custom code.
FAQ
What is a transaction assertion？
A rule attached to a transaction that checks its final state and reverts the actions if the result violates the rule.
How is that different from transaction simulation？
Simulation predicts an outcome before execution. An assertion checks the actual outcome during execution.
Is EIP-7906 live？
No. It is a proposal under consideration, not a deployed mainnet feature.
Could a compromised frontend bypass the protection？
It could if the frontend also controls the assertion. The rule must come from an independent trusted policy source.
Why is this useful for AI agents？
It can restrict not only what an agent is allowed to call but also the final result its transactions are allowed to produce.
