The Ethereum Foundation’s Trillion Dollar Security initiative has flagged blind signing and transaction uncertainty as major vulnerabilities impacting user experience and safety across the ecosystem. As a primary next step to combat these risks, researchers are actively exploring native transaction assertions designed to enforce a transaction’s final outcome. This mechanism is intended to work alongside Clear Signing initiatives to protect users against unexpected execution results.
The core issue stems from how the Ethereum Virtual Machine operates. A valid signature commits a user to a specific request, but the EVM executes instructions based on the prevailing code and state at the exact moment the transaction is processed. Because these underlying conditions can shift unpredictably between signing and execution, valid signatures do not always guarantee the intended result. Users have historically suffered severe financial losses either by inadvertently approving malicious instructions or by watching intended transactions yield unfavorable economic outcomes.
Two Ways a Signed Transaction Can Go Wrong
Security incidents across the decentralized finance ecosystem generally fall into two distinct categories: intent mismatches and outcome mismatches. An intent mismatch occurs when a user believes they are signing one specific action, but a compromised frontend or malicious actor supplies an entirely different payload. High-profile examples include the Bybit security incident and the BadgerDAO attack. In the Bybit event, signers authorized the replacement of a Safe implementation contract due to a compromised interface, while BadgerDAO users unknowingly granted attackers broad permission to spend their personal tokens.
An outcome mismatch represents a different class of risk. In these scenarios, the signer successfully authorizes the exact request presented to them, but environmental limits or prevailing network states produce results that directly conflict with their economic goals or standing safety policies. A prominent example involves an Aave and CoW collateral swap, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was insufficient to absorb a trade of that magnitude, and CoW’s gas ceiling rejected complex quotes during verification, only a single verified quote returning roughly 329 aEthAAVE remained. Although the user interface displayed a 99.9 percent price impact warning, the user proceeded to sign the transaction, ultimately receiving tokens valued at around $36,000.
In each of these situations, the missing element was a trusted, independently defined rule governing the resulting state, enforced directly during execution. For Bybit, a proper rule would have mandated that the approved Safe implementation contract remain unchanged. For BadgerDAO users, a protective policy would have restricted new token approvals exclusively to verified, published contracts. For the Aave user, an enforced rule would have dictated a minimum acceptable output calculated independently of the interface quote. Currently, however, Ethereum lacks a generalized mechanism for on-chain code to inspect the full scope of net state changes and emitted events produced by a single transaction.
What a Signature Does Not Control
When a user signs a transaction, their signature commits to specific parameters, including the target contract, value, and calldata. However, the EVM executes the call against the state and contract code present at the time of inclusion, which may have diverged significantly from the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can deviate sharply from expectations.
Target contracts or downstream dependencies frequently utilize proxy architectures where implementation logic can be upgraded before execution, altering the code that ultimately runs. Furthermore, transaction ordering introduces severe front-running and sandwich attack vectors, allowing malicious actors to manipulate pool prices or internal states before a legitimate user transaction clears, all without invalidating the original signature.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several vital defenses to mitigate these risks, but each possesses inherent limitations. Clear Signing provides users with human-readable transaction summaries, yet it relies entirely on accurate decoding and the user’s ability to spot discrepancies. Transaction simulation attempts to predict outcomes using a selected chain state, but conditions can shift before inclusion, and sophisticated malware can swap out payloads locally on a user’s machine after simulation takes place, as demonstrated in the Radiant Capital post-mortem.
Contract checks and wallet guards offer additional runtime security, such as Uniswap reverting trades that fall below specified minimum output amounts, or Safe’s checkAfterExecution hook inspecting account states. These safeguards, however, require developers to anticipate which state variables to monitor and depend heavily on explicit functions exposed by targeted contracts. They remain incapable of examining a transaction’s complete set of net state changes, meaning unforeseen side effects can easily slip past detection.
How Native Transaction Assertions Work
Native transaction assertions would empower on-chain code to evaluate the full aggregate of net state changes after all transaction actions have concluded. Utilizing read-only logic, an assertion compares starting values against final outcomes according to a predefined rule. If the rule is violated, the transaction reverts entirely.
The governing rule travels alongside the transaction, signed directly with its actions. It can regulate net changes across balances, storage slots, newly deployed contracts, and events. By implementing assertions, users can enforce maximum spending caps, block unauthorized token approvals, preserve account control logic, or establish strict minimum thresholds for outputs. Crucially, the origin of the rule is paramount; a compromised frontend could theoretically draft an assertion that permits an attack, meaning valid rules must originate from independently verified user intent, trusted account policies, or immutable protocol logic.
Three Design Choices and EIP-7906
Implementing native transaction assertions requires navigating core architectural decisions regarding EVM exposure, access methods, and execution scope. Developers must determine whether information should encompass state changes, events, or both, and how assertion code should access this data—whether through enumeration, direct lookups, or copying full state diffs into memory.
As a leading candidate addressing these challenges, EIP-7906 builds upon the frame transactions outlined in EIP-8141. While EIP-8141 introduces an ordered sequence of validation and action steps, EIP-7906 proposes appending a read-only POST_TX frame at the conclusion of the transaction to evaluate the final outcome. While EIP-8141 has been scheduled for the Hegot upgrade, EIP-7906 currently holds a "Considered for Inclusion" status.
Under EIP-7906, state changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contract code hashes. Storage slots modified multiple times are reported as single net transitions, and unmodified slots are omitted entirely. Access is granted via three proposed opcodes: TXTRACE for enumerating net changes and events, TXDIFF for retrieving starting and final values for specific addresses or storage slots, and EVENTDATACOPY for copying event data into memory.
These opcodes operate exclusively within the POST_TX frame as static calls, allowing assertions to inspect outcomes without altering state. If a rule violation occurs, the execution body reverts, but the transaction remains logged on-chain with a failed status, ensuring the gas payer is charged for consumed resources to prevent denial-of-service spam attacks against block builders.
The Assertion Has to Be Required
Because EIP-7906 does not mandate assertions for every transaction, transaction builders retain the technical ability to omit them. To protect personal transactions, user wallets must independently ensure that every built frame transaction incorporates the necessary assertion derived from local simulations or standing user policies.
Similarly, protocol-level protection requires smart contracts to verify that incoming calls originate from frame transactions carrying exact, required assertions, rejecting standard transactions or improperly asserted calls. Consequently, integrations must adapt to support frame transactions, as legacy immutable contracts cannot retroactively enforce these checks.
Where Transaction Assertions Could Help
Beyond direct user security, native transaction assertions offer wide-ranging utility across the Web3 landscape. They significantly enhance account delegation and agentic workflows, enabling users to place strict constraints on what automated agents can do and what economic outcomes their actions must achieve.
Protocols can leverage assertions to standardize safety guarantees for users interacting via solver networks, ensuring specified outcomes are met regardless of the execution path chosen by third-party fillers, within the boundaries of a single network transaction. Furthermore, assertions can verify that complex multi-step workflows successfully conclude by ensuring residual tokens are returned and redundant approvals are revoked.
Help Shape the Design
Research surrounding native transaction assertions remains ongoing under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Developers, wallet providers, and protocol engineers interested in exploring these use cases are encouraged to reach out via email to [email protected] or participate directly in the ongoing EIP-7906 discussion threads on the Ethereum Magicians forum to help guide the future of transaction safety on Ethereum.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
