The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as critical user experience risks facing the network. As part of ongoing efforts to secure the ecosystem, researchers are exploring native transaction assertions as a next step to enforce a transaction’s final outcome, working alongside previously introduced measures like Clear Signing.
This development addresses a fundamental challenge in blockchain security: why a valid signature does not always guarantee the specific transaction result a user intended. By examining how native transaction assertions could protect users where today’s defenses stop, the Ethereum community is evaluating various design choices, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a prominent potential approach.
Two Ways a Signed Transaction Can Go Wrong
The security problem fundamentally stems from how Ethereum executes instructions. The network executes exactly what is authorized, without evaluating whether the net result aligns with what the user actually wanted. While a signature serves as a formal commitment to a request, its ultimate outcome depends entirely on the code and state it encounters during execution. Throughout the history of the network, users have lost large sums of digital assets either because they approved something radically different from what they believed they were approving, or because the request they intended still produced an unwanted economic result.
The first major failure category is an intent mismatch, a phenomenon clearly demonstrated in high-profile incidents such as the Bybit security event and the BadgerDAO attack. In both of these security breaches, a compromised frontend supplied a signing request that differed significantly from what users believed they were authorizing. Specifically, Bybit signers unwittingly authorized replacing the Safe’s implementation contract, while BadgerDAO users inadvertently granted an attacker sweeping permissions to spend their tokens.
The second category involves an outcome mismatch. In this scenario, the signer accurately approves the exact request shown to them, but its built-in limits or the underlying blockchain state it runs against still permit a result that directly conflicts with their economic goals or standing safety policies. A prominent example occurred during an Aave and CoW collateral swap, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because liquidity for AAVE was far too thin to support a trade of that magnitude, and because CoW’s gas ceiling mechanism rejected more complex quotes during verification, only a single verified quote of roughly 329 aEthAAVE remained.
Although the user interface displayed a striking 99.9 percent price impact warning and explicitly required the user to confirm that the entire value of the trade could be lost, the user signed the transaction anyway, ultimately receiving tokens worth a mere $36,000.
Across all three of these distinct cases, a common element was missing: a trusted rule governing the resulting state, defined entirely independently of the transaction builder and strictly enforced during execution. In the Bybit incident, an effective rule would have mandated that the approved Safe implementation remain completely unchanged. For a Badger user, a protective rule would have restricted new token approvals exclusively to published and verified Badger contracts. In the Aave scenario, a robust user-defined rule would have established a mandatory minimum acceptable output, calculated independently of the quotes displayed by the interface. In this solver-based flow, the signed order or CoW settlement protocol would likewise have had to require the assertion. Currently, however, Ethereum lacks a general mechanism enabling onchain code to inspect the full set of net state changes and events produced by a single transaction.
What a Signature Does Not Control
When a user signs a transaction, their signature commits strictly to the requested action, encompassing the target contract, value, and calldata. However, the Ethereum Virtual Machine (EVM) executes this call against the specific contract code and state present at the exact moment the transaction runs. This state may have shifted dramatically since the moment the user signed. Consequently, the resulting net balance changes, storage modifications, and emitted events can deviate substantially from initial expectations.
The target contract, or another contract it invokes during execution, may rely on a proxy pattern whose implementation changes before the transaction is finalized. As a result, the actual code that executes can differ entirely from what the user inspected beforehand. Furthermore, transaction ordering plays a critical role in altering the state encountered by a call. For instance, a classic sandwich attack can manipulate a liquidity pool’s price immediately before a swap executes, all without altering the content of the user’s signed transaction.
Where Today’s Defenses Stop
Several defensive measures are already deployed across the Ethereum ecosystem to mitigate these risks. One primary defense is Clear Signing, which aims to provide human-readable explanations of the actions requested by transaction calldata. However, Clear Signing relies heavily on accurate decoding and assumes the signer will successfully recognize when a displayed action differs from their original intent.
Another common defense is simulation, which attempts to predict a transaction’s effects using a selected chain state. Because the underlying chain state can change before inclusion, and because the transaction ultimately signed can sometimes differ from the one simulated, vulnerabilities remain. In the case of Radiant Capital, for example, both the wallet interface and the simulation accurately displayed the intended transaction, but malware operating locally on the signers’ machines covertly substituted a malicious payload at the exact moment of signing.
Contract checks and wallet guards also enforce specific rules during EVM execution. For example, Uniswap automatically reverts a swap if its output falls below a designated amountOutMinimum parameter. Similarly, Safe’s checkAfterExecution hook allows a guard to inspect an account’s state after execution concludes and revert any transaction that violates established rules governing owners or configuration.
Nevertheless, both of these approaches require developers to choose which specific state variables to check in advance. To read another contract’s storage, they depend entirely on the functions that the contract explicitly exposes. While a token’s balanceOf function makes standard balance checks straightforward, a proxy contract is not required to expose its implementation address through a public function. Without such a dedicated interface, a security guard cannot read the implementation slot directly.
Crucially, these existing checks are fundamentally incapable of inspecting a transaction’s full set of net state changes. While a guard can verify that a particular balance remains unchanged, it cannot ask the EVM what else shifted during the transaction’s lifecycle, leaving unexpected side effects unnoticed.
How Native Transaction Assertions Work
Native transaction assertions would fundamentally change this dynamic by allowing onchain code to inspect the full spectrum of net state changes after all of a transaction’s primary actions have finished running. An assertion utilizes read-only logic to compare starting and final values against a predefined rule. If the rule fails to hold, the transaction’s actions automatically revert.
This protective rule is included directly within the transaction payload and is cryptographically signed alongside its actions. It can encompass net changes to native balances, storage slots, and contract code, as well as newly deployed contracts and emitted events. Such rules could mandate a minimum received amount, cap spending, block unexpected new token approvals, preserve an account’s control logic, or permit only a strictly specified set of state modifications.
Importantly, the source of the rule matters just as much as the integrity of the check itself. If a compromised frontend were allowed to write an assertion, it could easily craft a rule that explicitly permits the attack. Therefore, a useful security rule must originate from an independently approved user intent, a standing account-level policy, or protocol logic that a compromised interface component cannot manipulate or override.
Three Design Choices
Designing native transaction assertions requires navigating core architectural decisions regarding what information the EVM exposes, how assertion code accesses that data, and where the corresponding opcodes are permitted to run. Potential design choices include deciding whether to expose state changes, events, or both. Access options range from enumerating individual entries and looking up specific values to copying the complete set of net changes directly into memory. Furthermore, foundational opcodes could be restricted exclusively to specific transaction types or execution phases, or they could be made available anywhere within the EVM execution environment.
EIP-7906 as a Possible Solution
One prominent approach currently under discussion is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. A frame transaction contains an ordered sequence of validation and action steps. EIP-7906 introduces a read-only POST_TX frame situated at the very end of the sequence specifically to check the transaction’s final outcome. While EIP-8141 is scheduled for the Hegotá upgrade, EIP-7906 has advanced to being "Considered for Inclusion," though it is not yet officially confirmed for that upcoming network upgrade.
The proposed design exposes both state changes and events. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. For instance, a storage slot written multiple times during a transaction’s execution appears as a single entry reflecting its initial starting value and its final ending value. If a storage slot concludes its execution with its original value intact, it does not appear in the trace at all.
Three new opcodes would provide access to this critical information: TXTRACE to enumerate net state changes and events, TXDIFF to retrieve starting and final values for specific addresses and storage slots, and EVENTDATACOPY to copy an event’s data into memory.
These opcodes operate exclusively within a POST_TX frame, which executes at the conclusion of the transaction as a static call. This ensures the assertion can inspect the final outcome without altering state. If the specified rule is violated, the entire execution body reverts, but the transaction nevertheless remains recorded in the block with a failed status, and the gas payer is charged for all gas consumed. This economic charge prevents malicious actors from forcing block builders to execute deliberately failing transactions for free.
The Assertion Has to Be Required
Because EIP-7906 does not mandate that every transaction include an assertion by default, the entity constructing the transaction retains the technical ability to omit it.
For everyday user transactions, wallet software would be responsible for ensuring that every frame transaction it builds incorporates the necessary assertion. The underlying rule could be derived automatically from a simulation run by the wallet or enforced via a standing security policy applicable to all outgoing transactions.
Meanwhile, a decentralized protocol seeking to protect its functions would need to verify that incoming calls originate from a frame transaction containing the exact required assertion. The protocol must reject ordinary transactions as well as frame transactions with a missing or incorrect assertion. Consequently, callers and integrations would need to adopt compatible frame transactions, and an already deployed immutable contract would be unable to retroactively add this verification check.
Where Transaction Assertions Could Help
Beyond enhancing security for individual users and protocols, native transaction assertions could support a variety of advanced use cases. For example, they could significantly strengthen delegation models. When delegating authority to an agent to act on one’s behalf, users could limit which contracts the agent interacts with, how much capital it spends, and how long its permissions remain active. Assertions could introduce strict rules governing the precise economic outcome of each transaction, constraining both the actions an agent may take and the results those actions produce.
Protocols could similarly define native rules requiring uniform safety checks for every caller utilizing a frame transaction. In solver-based execution flows, a protocol could specify the required final outcome while leaving the solver free to determine the optimal execution route. However, this guarantee would apply strictly within the boundaries of a single transaction on a single network, meaning it would not inherently cover routes spanning multiple blockchain networks. Additionally, assertions could verify that complex workflows reach their intended final state, ensuring any unused tokens are correctly returned to the user and remaining token approvals are successfully revoked.
Help Shape the Design
Solutions for native transaction assertions remain under active development as part of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback from wallet developers and protocol teams who would ultimately implement these tools. Interested contributors can connect via email to explore use cases and help shape the ongoing research, or participate directly in the EIP-7906 discussion thread on the Ethereum Magicians forum.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
