The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as major structural user experience risks within the ecosystem. As a result, developers and researchers are exploring native transaction assertions as a crucial next step to strictly enforce a transaction’s final outcome, working alongside complementary security frameworks like Clear Signing.
The core issue revolves around why a cryptographically valid signature does not always guarantee the specific transaction result a user intended. By introducing native transaction assertions, the Ethereum network could potentially protect users where today’s security defenses fall short. Current discussions are evaluating various design choices, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as one prominent and heavily analyzed approach to solving this systemic challenge.
Two ways a signed transaction can go wrong
The underlying problem begins with how the Ethereum network fundamentally operates. The Ethereum Virtual Machine (EVM) executes transactions exactly as they are authorized, strictly following code logic without evaluating whether the resulting economic or state change matches what the user actually wanted. A standard cryptographic signature commits to a specific request, but its actual outcome depends entirely on the prevailing contract code and blockchain state it encounters during execution. Over the history of the network, users have lost substantial sums either because they approved a request that differed significantly from their beliefs, or because an intended request still produced an unwanted outcome due to shifting blockchain conditions.
The first major failure mode is an intent mismatch, a phenomenon vividly illustrated by security breaches such as the Bybit incident and the BadgerDAO attack. In both of these high-profile attacks, a compromised frontend or malicious actor supplied a signing request that differed fundamentally from what the users believed they were approving. During the Bybit incident, affected signers inadvertently authorized replacing the Safe’s implementation contract. Meanwhile, users caught in the BadgerDAO attack inadvertently granted malicious actors broad permissions to spend and drain their native tokens.
The second major failure mode is an outcome mismatch. In these scenarios, the signer legitimately approves the exact request shown to them by their interface, but execution limits or the underlying blockchain state allow a final result that sharply conflicts with their economic goals or standing safety policies. A clear example occurred during the Aave and CoW collateral swap event. A user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Unfortunately, the available liquidity for AAVE was far too thin to support a trade of that unprecedented magnitude.
At the same time, CoW’s gas ceiling mechanism rejected more complex quotes during the verification phase, leaving a single verified quote valued at roughly 329 aEthAAVE. Although the user interface displayed a severe 99.9 percent price impact warning and explicitly required the user to confirm that the entire transaction value could be lost, the user signed the transaction anyway and ultimately received tokens worth only about $36,000.
Across all three of these historical cases, the common denominator was a total absence of a trusted rule governing the resulting state—a rule defined independently of the transaction builder and forcefully enforced during execution. In the Bybit scenario, a proper security rule would have mandated that the approved Safe implementation contract remain entirely unchanged. For a Badger user, an automated rule would have restricted new token approvals exclusively to officially published Badger contracts. For the Aave user, a protective rule would have enforced a strict minimum acceptable output calculated independently of the quotes displayed by the interface, provided the solver-based flow or settlement protocol supported the assertion. Currently, however, Ethereum lacks any generalized mechanism for onchain code to inspect the full set of net state changes and emitted events produced by a transaction.
What a signature does not control
When a user signs an Ethereum transaction, their signature commits specifically to the requested action, including the target contract, the transferred value, and the raw calldata. However, the EVM executes this call against whatever contract code and blockchain state happen to be present at the exact moment the transaction is included in a block. Because blockchain environments are dynamic, the state frequently changes between the time of signing and the time of execution. Consequently, the resulting net balance changes, storage modifications, and emitted events can deviate wildly from initial expectations.
The target contract specified in a transaction, or any secondary contract it calls, may utilize an upgradeable proxy pattern whose implementation contract changes prior to execution. As a result, the executing code can easily differ from what the user inspected during the review stage. Furthermore, transaction ordering and adversarial manipulation can dramatically alter the local state encountered by a call. For instance, a classic sandwich attack can manipulate decentralized exchange pool prices immediately before a user’s swap executes, altering the financial outcome without ever modifying the user’s signed transaction data.
Where today’s defenses stop
The Ethereum ecosystem has successfully deployed several important defenses to mitigate these risks. One prominent approach is Clear Signing, which aims to translate raw hexadecimal calldata into human-readable descriptions of what a transaction requests. However, Clear Signing relies heavily on accurate decoding by wallet software and assumes that the signer possesses the vigilance to recognize when a displayed action contradicts their original intent.
Another common defense is transaction simulation, which predicts the effects of a pending transaction by running it against a selected snapshot of the chain state. Despite its usefulness, the chain state can shift before final block inclusion, and a compromised environment can cause the signed transaction to differ from the one that was initially simulated. A stark example of this vulnerability occurred during the Radiant Capital exploit, where both the wallet user interface and the simulation tool accurately displayed the intended transaction, while malware operating locally on the signers’ machines substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap transaction if the final output falls below a user-defined amountOutMinimum parameter. Similarly, Safe’s checkAfterExecution hook allows a designated guard contract to inspect an account’s state immediately after execution finishes and revert the transaction if it violates pre-established rules regarding owners or configurations.
Despite their utility, both of these approaches require developers to choose which specific state variables to check in advance. To read another contract’s internal storage, they depend entirely on the specific view functions that the target contract exposes. While a standard token’s balanceOf function makes balance validation straightforward, a generic proxy contract is not obligated to expose its implementation address through a public function. Without a dedicated interface function, a security guard cannot read the implementation slot directly. Crucially, these traditional checks remain incapable of inspecting a transaction’s complete set of net state changes, meaning unforeseen or side-effect vulnerabilities can easily go unnoticed.
How native transaction assertions work
Native transaction assertions would fundamentally change this dynamic by allowing onchain code to inspect the full set of net state changes after a transaction’s primary actions have finished running. An assertion utilizes read-only execution logic to compare starting and final values against a predefined rule. If the specified rule fails to hold true, the entire transaction reverts.
These rules are embedded directly into the transaction itself and are cryptographically signed alongside its core actions. They can govern net changes across native balances, storage slots, and contract code, as well as newly deployed contracts and generated events. A rule can mandate a minimum received amount, cap maximum spending, block unauthorized token approvals, preserve an account’s foundational control logic, or restrict execution to a strictly specified set of state modifications.
However, the origin of the validation rule matters just as much as the check itself. A compromised frontend interface could theoretically write a malicious assertion that covertly permits an attack. Therefore, a genuinely useful security rule must originate from an independently approved user intent, a standing account policy, or native protocol logic that a compromised interface component cannot manipulate.
Three design choices
Designing native transaction assertions requires navigating complex technical 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 whether the exposed data encompasses net state changes, event logs, or both. Access mechanisms might range from enumerating through entries and looking up specific values to copying the complete set of net changes directly into memory. Furthermore, developers must decide whether the new opcodes should be restricted to specialized transaction types and execution phases, or made available universally across the EVM.
EIP-7906 as a possible solution
One prominent approach currently under active consideration is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. Under this architecture, a frame transaction contains an ordered sequence of distinct validation and action steps. EIP-7906 introduces a read-only POST_TX frame situated at the very end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has been scheduled for the upcoming Hegot upgrade, EIP-7906 has successfully advanced to a "Considered for Inclusion" status, though it is not yet officially confirmed for that specific network 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 values, alongside newly deployed contracts and their associated code hashes. For instance, a storage slot that is written to multiple times during execution appears as a single unified entry detailing its starting and final values; if a slot ultimately ends with its original value, it does not appear in the trace at all.
Three new EVM opcodes provide programmatic access to this verification data. The TXTRACE opcode enumerates net state changes and emitted events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies an event’s recorded data into memory. These opcodes function exclusively within a POST_TX frame executing at the end of the transaction as a static call, ensuring the assertion can inspect the final outcome without altering state. If the underlying rule is violated, the entire execution body reverts, but the transaction remains recorded on-chain with a failed status, and the gas payer is charged for the computational resources consumed. This economic penalty prevents malicious actors from forcing block builders to process deliberately failing transactions for free.
The assertion has to be required
A notable characteristic of EIP-7906 is that it does not inherently mandate that transactions must include an assertion, meaning transaction builders retain the technical ability to omit them entirely. To protect individual users, wallet software must ensure that every frame transaction it constructs incorporates the necessary assertion, derived either from a pre-execution simulation or a standing account policy.
Similarly, a decentralized protocol seeking to leverage this security model must configure its protected functions to verify that incoming calls originate from frame transactions containing the exact required assertion. The protocol must reject ordinary transactions as well as frame transactions that feature missing or incorrect assertions. Consequently, callers and ecosystem integrations must adopt compatible frame transactions, meaning already deployed immutable contracts cannot retroactively add this verification check.
Where transaction assertions could help
Beyond providing essential security safeguards for individual users and protocols, native transaction assertions could unlock powerful new use cases across the Ethereum ecosystem. For example, they could significantly strengthen automated delegation systems. When a user delegates operational authority to an agent, they can restrict which contracts the agent interacts with, how much capital it spends, and how long its permissions persist. Assertions introduce the ability to constrain the economic outcome of every single transaction, allowing users to tightly govern both what an agent is permitted to do and what its actions must ultimately produce.
Protocols could also define native rules requiring identical safety checks for all callers utilizing frame transactions. In solver-based execution architectures, a protocol could specify the required final outcome while leaving solvers entirely free to determine the routing mechanics. While this guarantee applies strictly within a single transaction on a single network—and thus cannot span multi-chain cross-network routes—assertions can also verify that complex workflows reach their intended final state, ensuring that any unused tokens are correctly returned to the user and residual token approvals are automatically 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, protocol engineers, and security teams who intend to utilize these capabilities. Interested contributors can reach out via email to explore specific use cases and help shape ongoing research, or participate directly in the community discussions on the EIP-7906 discussion thread. Additional information regarding ongoing risk controls and priority development areas is available through the initiative’s official coordination channels.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
