As part of the broader ongoing efforts of the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers have identified blind signing and transaction uncertainty as critical user experience and safety risks facing the ecosystem. To address these vulnerabilities, the initiative is actively exploring the implementation of native transaction assertions as a fundamental next step. Alongside initiatives like Clear Signing, these assertions are designed to enforce a transaction’s final outcome directly at the protocol level, offering a robust layer of protection where traditional user-facing defenses often fall short.
This development addresses a foundational challenge in blockchain architecture: possessing a valid cryptographic signature does not always guarantee that a transaction will yield the intended result. By investigating native transaction mechanisms—with EIP-7906 (Transaction Assertions via State Diff Opcode) standing out as a prominent approach—the Ethereum community aims to protect users from unexpected financial losses caused by execution discrepancies, compromised user interfaces, and volatile market conditions.
Two Ways a Signed Transaction Can Go Wrong
The root of the problem lies in the deterministic nature of how Ethereum operates. The Ethereum Virtual Machine (MVM) executes precisely what a user authorizes, operating without independent judgment regarding whether the outcome aligns with the user’s actual intent. A cryptographic signature represents a strict commitment to a requested action, but the final outcome is entirely dependent on the smart contract code and the global state of the network at the exact moment the transaction is executed. Throughout the history of the network, users have suffered significant financial losses either because they inadvertently approved an action different from what they believed they were authorizing, or because a legitimate request produced an undesired result due to external variables.
The first major failure mode is an intent mismatch, a phenomenon highlighted by high-profile security incidents such as the Bybit compromise and the BadgerDAO attack. In both of these security breaches, a compromised frontend or interface supplied a signing request that fundamentally differed from what the users believed they were approving. During the Bybit incident, affected signers authorized the replacement of a Safe multi-sig implementation contract, effectively handing control over to malicious actors. Similarly, users interacting with BadgerDAO were tricked into granting external attackers unlimited permission to drain their token balances.
The second major vulnerability is an outcome mismatch. In this scenario, the user or signer accurately approves the exact request presented by the user interface, but underlying execution limits or sudden shifts in network state produce a result that directly conflicts with their economic goals or institutional safety policies. A prominent example of this occurred during a high-profile collateral swap involving Aave and CoW Protocol. A user attempted to execute a swap exchanging approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, available AAVE liquidity was far too shallow to support a trade of that magnitude cleanly.
Due to these constraints, CoW’s underlying 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 value of the transaction could be lost, the user signed the transaction anyway, ultimately receiving tokens worth a mere $36,000.
Across all three of these distinct scenarios, a critical safeguard was missing: a trusted, immutable rule governing the resulting state, defined entirely independently of the transaction builder and enforced directly during execution. In the Bybit incident, an ideal security rule would have mandated that the approved Safe implementation contract remain completely unchanged. For a BadgerDAO user, a protective rule would have restricted new token approvals strictly to previously published and verified Badger contracts. In the Aave collateral swap, a deterministic rule would have enforced a strict minimum acceptable output calculated independently of the quotes supplied by the interface, while solver-based protocols would similarly require native assertions to honor these economic boundaries. Currently, however, Ethereum lacks a general, native mechanism for onchain 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 on Ethereum, their cryptographic signature commits strictly to the explicit action requested, including the target contract address, native value transfer, and specific calldata. However, the EVM executes this call against whatever contract code and network state happen to exist at the exact moment the transaction is included in a block. Because time elapses between signing and execution, the underlying state may have shifted significantly. Consequently, the resulting net balance changes, storage modifications, and emitted events can diverge widely from what the user originally anticipated.
The target contract specified in the transaction—or another contract invoked further down the execution call stack—may utilize an upgradeable proxy pattern whose implementation changes prior to execution. As a result, the code that ultimately runs can be entirely different from the code the user inspected in their wallet interface. Transaction ordering within a block introduces further unpredictability. A classic sandwich attack, for instance, can manipulate a decentralized exchange liquidity pool’s price immediately before a victim’s swap executes, altering financial outcomes without modifying the bytes of the user’s signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several security measures to mitigate these risks, but each possesses inherent limitations. One primary defense is Clear Signing, a standard designed to decode calldata and present human-readable explanations of requested actions to the user. While helpful, Clear Signing relies entirely on accurate decoding algorithms and assumes the signer possesses the technical literacy to recognize when a decoded action deviates from their actual intent.
Another common defense is transaction simulation, which predicts the effects of a transaction by evaluating it against a selected historical or current chain state. Because chain states are dynamic, the state can change before inclusion, or the transaction ultimately signed can diverge from the one simulated. A stark illustration of this vulnerability occurred during the Radiant Capital exploit, where both the wallet interface and the simulation engine displayed the intended, safe transaction, while malware running locally on the user’s machine quietly substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet security guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-defined amountOutMinimum parameter. Similarly, the Safe multi-sig wallet ecosystem utilizes a checkAfterExecution hook, allowing a dedicated guard contract to inspect the account’s state after execution and revert the transaction if it violates pre-configured rules regarding owners or operational parameters.
However, these existing approaches suffer from significant constraints. They require developers to choose which specific state variables to check in advance. To read another contract’s storage, they must rely entirely on the explicit functions exposed by that contract. While checking a token’s balanceOf function is straightforward, an arbitrary proxy contract is not required to expose its underlying implementation address via a public read function. Without such an accessible interface, a wallet guard cannot inspect the implementation storage slot directly. Furthermore, these localized checks are fundamentally incapable of inspecting a transaction’s comprehensive set of net state changes, meaning unforeseen side effects can easily slip through unobserved.
How Native Transaction Assertions Work
Native transaction assertions propose a systemic solution by allowing onchain code to inspect the full set of net state changes immediately after a transaction’s primary actions have concluded. Utilizing read-only logic, an assertion compares starting and final values against a predefined rule set. If the execution fails to satisfy the established rules, the entire transaction reverts.
Under this model, the governing rule is packaged directly into the transaction and cryptographically signed alongside its operational actions. These rules can encompass net changes to native asset balances, storage slots, newly deployed contract code hashes, and emitted events. A user or protocol could mandate a strict minimum received amount, cap spending limits, block unauthorized token approvals, preserve account control logic, or restrict execution to a designated set of outcomes.
Crucially, the origin of the rule is just as important as the mechanics of the check itself. If a compromised user interface were allowed to generate the assertion, an attacker could simply write a rule that permits their malicious activity. Therefore, a secure rule must originate from independently verified user intent, a strict standing account policy, or foundational protocol logic that a compromised frontend component cannot tamper with or rewrite.
Three Design Choices
Developing native transaction assertions requires complex architectural decisions regarding what information the EVM exposes, how assertion code accesses that data, and where the corresponding opcodes are permitted to run. Core researchers must determine whether the exposed information should include state changes, emitted events, or both. Access mechanisms must also be defined, ranging from enumerating individual entries and looking up specific values to copying the complete set of net state changes directly into memory. Additionally, architects must decide whether the new opcodes should be restricted to specific transaction types and execution phases, or made universally available across the EVM.
EIP-7906 as a Possible Solution
A prominent proposal addressing these challenges is EIP-7906, which builds directly upon the frame transactions introduced in EIP-8141. A frame transaction structures execution into an ordered sequence of discrete validation and action steps. EIP-7906 extends this architecture by appending a read-only POST_TX frame at the very end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has been scheduled for the Hegot upgrade, EIP-7906 has advanced to a "Considered for Inclusion" status without yet securing final confirmation for the upcoming upgrade.
The design of EIP-7906 exposes both net state changes and protocol events. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their associated code hashes. For instance, if a specific storage slot is written to multiple times within the span of a single transaction, it appears as a single unified entry detailing only its starting and final values. If a storage slot ultimately concludes execution holding its original value, it is omitted entirely.
Three new EVM opcodes provide programmatic access to this 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 specific event data into memory. These powerful opcodes function exclusively within a dedicated POST_TX frame executing as a static call at the end of the transaction, ensuring the assertion can inspect outcomes without inadvertently altering state. If the asserted rule is violated, the entire execution body reverts. However, the transaction remains recorded on-chain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement prevents malicious actors from spamming block builders with deliberately failing transactions for free.
The Assertion Has to Be Required
A key consideration of EIP-7906 is that it does not inherently mandate transactions to include an assertion, meaning transaction builders retain the technical ability to omit them. To safeguard everyday users, software wallets must ensure that every frame transaction they construct automatically incorporates the necessary assertion, derived either from a pre-execution simulation or a persistent security policy.
Conversely, protocols seeking to protect their users must programmatically verify that incoming calls originate from frame transactions containing the exact required assertion. Smart contracts would need to reject ordinary transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, protocol integrations and calling applications would need to adopt compatible frame transactions, and already deployed immutable contracts would be unable to retroactively incorporate this verification check.
Where Transaction Assertions Could Help
Beyond immediate user protection against frontends and unexpected execution outcomes, native transaction assertions unlock broader utility across the Ethereum ecosystem. They can significantly strengthen account delegation and automated agent workflows. When delegating authority to an autonomous agent, users can already restrict which contracts the agent interacts with, set spending caps, and establish time limits. Assertions introduce a granular layer of control over the precise economic outcome of each transaction, constraining both the actions an agent can take and the results those actions must produce.
Protocols can similarly leverage assertions to standardize safety guarantees for users interacting via complex solver networks. By specifying a required final outcome within a frame transaction, a protocol can ensure safety constraints are met while leaving solvers flexibility regarding routing and execution paths. Furthermore, assertions can verify that multi-step workflows reach their intended destination state, ensuring that unspent tokens are successfully returned and redundant token approvals are automatically revoked before a transaction settles.
Help Shape the Design
As research and development surrounding native transaction assertions continue under the Ethereum Foundation’s Trillion Dollar Security initiative, core contributors are actively seeking feedback from wallet developers, protocol architects, and infrastructure teams. Stakeholders interested in exploring these use cases and contributing to the research can reach out via email or join the ongoing discussions on the Ethereum Magicians forum under the EIP-7906 thread. Additional information regarding ongoing risk control initiatives is available through the official Trillion Dollar Security portal.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
