As the Ethereum ecosystem continues to scale and secure increasingly vast amounts of economic value, core developers and researchers are confronting deep-seated architectural challenges related to user intent and transaction finality. Under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, researchers have identified blind signing and transaction uncertainty as critical user experience and security risks. To address these vulnerabilities, the foundation is actively exploring native transaction assertions as a foundational next step to enforce a transaction’s final outcome, working in tandem with the recently announced Clear Signing initiatives.
The ongoing research tackles a fundamental structural reality of how the Ethereum Virtual Machine operates: a valid signature does not inherently guarantee the transaction result that a user intended. By investigating native transaction assertions, developers hope to protect users in scenarios where today’s defensive mechanisms fall short. This exploration involves deep design choices, with EIP-7906, which proposes transaction assertions via a state difference opcode, emerging as one prominent and heavily discussed approach within the community.
Two Ways a Signed Transaction Can Go Wrong
The core problem stems from the deterministic yet unfeeling nature of Ethereum. The EVM executes instructions precisely as authorized, without judging whether the resulting state aligns with what the user actually wanted. While a cryptographic signature commits a user to a specific request, the ultimate outcome depends entirely on the code and the state conditions the transaction encounters during execution. Over the history of the network, users have suffered massive financial losses either because they approved something entirely different from what they believed they were signing, or because an intended request still produced an undesirable economic result.
The first major failure mode is an intent mismatch, a phenomenon vividly illustrated by security incidents such as the Bybit compromise and the BadgerDAO attack. In both instances, a compromised frontend or malicious actor supplied a signing request that differed fundamentally from what the users thought they were approving. During the Bybit incident, affected signers authorized the replacement of a Safe multi-sig implementation contract, while BadgerDAO users unknowingly granted attackers broad permissions to spend their underlying tokens.
The second major vulnerability is an outcome mismatch. In these scenarios, the signer approves the exact request presented to them, but execution limits or shifting state conditions allow a final outcome that conflicts directly with their economic goals or institutional safety policies. A prominent example occurred during the Aave and CoW collateral swap event. A user initiated a request to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, AAVE liquidity proved far too thin to support a trade of that magnitude efficiently. CoW’s gas ceiling also rejected complex quotes during verification, leaving a single verified quote of roughly 329 aEthAAVE.
Although the user interface displayed a severe 99.9 percent price impact warning and required explicit confirmation that the entire transaction value could be lost, the user signed the transaction anyway and ultimately received tokens worth roughly $36,000. In all three of these historical cases, a crucial element was missing: a trusted, independent rule governing the resulting state that was defined separately from the transaction builder and strictly enforced during execution.
For Bybit, an effective rule would have mandated that the approved Safe implementation contract remain entirely unchanged. For BadgerDAO users, a protective rule would have restricted new token approvals exclusively to officially published and verified Badger contracts. For the Aave swap, a hard rule would have enforced a minimum acceptable output calculated independently of the quotes displayed by the interface. Currently, however, Ethereum lacks a generalized mechanism for on-chain code to inspect the complete set of net state changes and emitted events produced by a transaction in real-time.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is necessary to examine the precise limitations of an Ethereum signature. When a user signs a transaction, they are committing strictly to a requested action, which includes the target address, value, and specific calldata payload. The EVM then executes this call against the contract code and state present at the exact moment the transaction is processed on-chain. Because network conditions fluctuate, the state may have changed significantly since the moment the user signed. Consequently, the resulting net balance changes, storage alterations, and emitted events can deviate drastically from initial expectations.
The target contract specified in a transaction, or any other contract it interacts with, may utilize a proxy whose implementation contract changes prior to execution. As a result, the code that actually runs can be entirely different from the code inspected by the user during the signing phase. Furthermore, transaction ordering within a block introduces profound unpredictability. A classic sandwich attack, for instance, can manipulate a liquidity pool’s price immediately before a swap executes without altering a single byte of the user’s signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several important defensive measures over the years, but each comes with inherent limitations. One primary defense is Clear Signing, which aims to decode and clearly explain the actions requested by calldata. While helpful, Clear Signing relies entirely on accurate decoding protocols and assumes that the human signer can reliably recognize when a displayed action differs from their underlying intent.
Another common safeguard is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. However, chain state can and does change before a transaction is officially included in a block, and a malicious actor can substitute a completely different payload at the moment of signing. In the case of Radiant Capital, both the wallet interface and the simulation successfully displayed the intended transaction, while local malware on the victim’s machine substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a token swap if the final output falls below a pre-set parameter known as amountOutMinimum. Similarly, Safe accounts utilize a checkAfterExecution hook that allows a security guard to inspect account state after execution and revert transactions that violate established rules for owners or configurations.
Despite their utility, these approaches require developers to choose which specific state variables to check in advance. To read another contract’s storage, they remain entirely dependent on the functions that contract chooses to expose publicly. While a token contract’s balanceOf function makes straightforward balance checks easy, an arbitrary proxy contract is not obligated to expose its implementation address via a standard function call. Without a dedicated interface, a security guard cannot read the implementation slot directly, leaving broader, unanticipated net state changes entirely unchecked.
How Native Transaction Assertions Work
Native transaction assertions propose a paradigm shift by allowing on-chain code to inspect the complete set of net state changes after all transaction actions have finished executing. An assertion utilizes specialized read-only logic to compare starting and final values against a predefined rule. If the rule fails to hold true, the entire transaction reverts.
Crucially, this rule is packaged directly into the transaction and signed alongside its primary actions. It can encompass net changes to native balances, storage slots, newly deployed contracts, and emitted events. Rules can be configured to require a minimum received amount, cap maximum spending, block unauthorized token approvals, preserve an account’s core control logic, or restrict execution to a strictly specified set of state modifications.
However, the source of the assertion rule is just as critical as the verification mechanism itself. If a compromised frontend interface is allowed to write the assertion rule, it can simply write a rule that permits the malicious attack. Therefore, a genuinely useful assertion rule must originate from an independently verified user intent, a standing and immutable account policy, or core protocol logic that a compromised component cannot manipulate.
Three Design Choices
Designing native transaction assertions at the protocol level requires resolving complex architectural questions regarding what information the EVM exposes, how assertion code accesses that data, and where the associated opcodes are permitted to run. Core developers must decide whether the exposed information should include state changes, emitted events, or both.
Access options under consideration include enumerating individual entries, looking up specific values directly, or copying the full set of state changes into working memory. Additionally, developers must determine whether the new opcodes should be restricted to specific transaction types and specialized execution phases, or made universally accessible throughout the EVM.
EIP-7906 as a Possible Solution
One prominent approach actively being evaluated by researchers is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. Under this framework, a frame transaction consists of an ordered sequence of validation and action steps. EIP-7906 proposes adding a read-only POST_TX frame at the very end of the sequence specifically to check the transaction’s final outcome. While EIP-8141 has been scheduled for the upcoming Hegot upgrade, EIP-7906 has advanced to "Considered for Inclusion status," though it is not yet officially confirmed for the upgrade.
The proposed design exposes both comprehensive state changes and event logs. State changes are reported as net differences in native ETH balances and storage allocations, along with newly deployed contracts and their corresponding code hashes. Under this system, a storage slot that is written to multiple times during a transaction appears as a single entry reflecting only its starting and final values. If a storage slot ends up with its original value intact, it is omitted entirely, minimizing computational overhead.
Three new opcodes would provide smart contracts and wallets with access to this transactional data. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies an event’s underlying data directly into memory.
These opcodes are designed to function exclusively inside a POST_TX frame, which executes at the conclusion of the transaction as a static call. This ensures that the assertion can inspect the outcome without altering the state further. If the established rule is violated, the entire execution body reverts, but the transaction remains permanently recorded in the block with a failed status, ensuring that the gas payer is charged for the computational resources consumed. This economic penalty prevents malicious actors from forcing block builders to execute deliberately failing transactions for free.
The Assertion Has to Be Required
A major challenge with proposals like EIP-7906 is that they do not inherently mandate that transactions include an assertion, meaning that whoever constructs the transaction could technically omit it. To solve this for user transactions, wallets must ensure that every frame transaction they build automatically incorporates the required assertion, derived either from a pre-execution simulation or a standing user-defined security policy.
For protocols seeking to protect their users, protected functions must be coded to verify that incoming calls originate from a frame transaction containing the exact required assertion. These smart contracts must systematically reject ordinary legacy transactions as well as frame transactions that feature missing or incorrect assertions. Consequently, callers and ecosystem integrations would be required to adopt compatible frame transactions, meaning already deployed immutable contracts cannot retroactively add this specific check without proxy upgrades.
Where Transaction Assertions Could Help
Beyond baseline security enhancements for individual users and DeFi protocols, native transaction assertions unlock new capabilities across the Ethereum landscape. For instance, they could significantly strengthen delegation models. When a user authorizes an automated agent or smart contract to act on their behalf, assertions can enforce strict limits on which contracts the agent can interact with, how much capital it can expend, and what the final economic outcome of its actions must look like.
Protocols could also leverage assertions to enforce standardized safety checks for every incoming call via frame transactions. In solver-based execution architectures, a protocol could specify the required final outcome while leaving solvers completely free to determine the optimal execution route. Furthermore, assertions could verify that complex multi-step workflows successfully reach their intended final state, ensuring that unused tokens are properly returned to the user and that any temporary token approvals are cleanly revoked before the transaction concludes.
Help Shape the Design
Solutions for native transaction assertions remain under active research and development as part of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback from wallet developers, security auditors, and protocol teams who would ultimately rely on these mechanisms. Stakeholders are encouraged to connect via email or participate in ongoing community discussions on the Ethereum Magicians forum regarding EIP-7906 to help refine the architecture and ensure robust protection for the broader ecosystem.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
