As the blockchain ecosystem scales toward securing institutional and retail capital on a massive scale, the Ethereum Foundation’s Trillion Dollar Security initiative has spotlighted critical vulnerabilities rooted in standard transaction lifecycles. Chief among these user experience risks are blind signing and transaction outcome uncertainty. To address these vulnerabilities, researchers and core developers are actively exploring native transaction assertions as a foundational security layer. Working alongside companion efforts like Clear Signing, native transaction assertions aim to fundamentally enforce a transaction’s exact final outcome at the protocol level, bridging a long-standing gap in how user intent is verified and executed on Ethereum.
This emerging research tackles a foundational security question: why a cryptographically valid signature does not always guarantee the desired transaction result. By examining how native transaction assertions could protect users well beyond the limits of today’s defenses, the Ethereum Foundation hopes to spark vital architectural discussions across the developer community. At the heart of this exploration is EIP-7906 (Transaction Assertions via State Diff Opcode), which presents a compelling technical framework for enforcing economic and operational guardrails directly inside the Ethereum Virtual Machine (EVM).
Two Ways a Signed Transaction Can Go Wrong
The root of the problem lies in the deterministic nature of Ethereum execution. The EVM executes instructions precisely as authorized by the caller, without intrinsic judgment regarding whether the outcome aligns with the user’s actual intent. A standard digital signature merely commits to an invocation request, while the ultimate financial and state outcome depends entirely on the code and network state encountered when the transaction is finally included in a block. Over the history of the network, significant funds have been lost either because users unknowingly approved actions that deviated from their beliefs, or because an intended request executed under network conditions that produced an unacceptable economic result.
The first major failure mode is an intent mismatch, a phenomenon highlighted by high-profile exploits such as the Bybit security incident and the BadgerDAO attack. In both of these instances, a compromised frontend or malicious payload supplied a signing request that differed fundamentally from what users believed they were authorizing. During the Bybit incident, affected signers inadvertently authorized replacing their Safe’s implementation contract with a malicious alternative. Similarly, BadgerDAO users granted an attacker unchecked permission to drain their token balances by approving malicious calldata disguised as routine interactions.
The second major failure mode is an outcome mismatch. In these scenarios, the signer consciously approves the exact request presented by the user interface, but underlying limits or unfavorable state shifts during execution produce a result that directly violates their economic goals or standing safety policies. A stark example of this 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. Unfortunately, real-time AAVE liquidity was far too thin to support a trade of that magnitude cleanly. Furthermore, CoW Swap’s gas ceiling rejected more complex, multi-path quotes during verification, leaving a single verified quote yielding roughly 329 aEthAAVE.
Although the user interface displayed a severe 99.9 percent price impact warning and required explicit confirmation that the entire principal could be lost, the user signed the transaction regardless, ultimately receiving tokens valued at around $36,000. Across all three distinct scenarios—Bybit, BadgerDAO, and the Aave collateral swap—a common architectural deficiency was present: the complete absence of a trusted rule governing the resulting state, defined independently of the transaction builder and rigorously enforced during EVM execution.
In a robust security model, a protective rule for the Bybit incident would have mandated that the approved Safe implementation contract remain strictly immutable. For a BadgerDAO user, a pre-configured rule would have restricted new token approvals exclusively to verified, published Badger smart contracts. For the Aave user, an independent rule would have enforced a strict minimum acceptable output, calculated entirely apart from the quotes displayed by the interface. However, Ethereum currently lacks a generalized, native mechanism for onchain code to inspect the comprehensive set of net state changes and emitted events produced over the course of a transaction.
What a Signature Does Not Control
When a user signs an Ethereum transaction, their cryptographic commitment applies specifically to the requested action, encompassing the recipient target address, transferred value, and execution calldata. However, the EVM evaluates this call against whatever contract code and global state are present at the exact moment the transaction runs, which may have shifted dramatically since the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can diverge wildly from the user’s expectations.
The target contract specified in a transaction—or any downstream contract it calls—may utilize proxy architectures whose implementation logic can be secretly updated prior to execution. As a result, the active code running on-chain can differ fundamentally from the code the user inspected in their wallet. Transaction ordering and mempool dynamics also introduce severe variables. For instance, a classic sandwich attack can manipulate liquidity pool reserves and shift token prices immediately before a user’s swap executes, altering the financial outcome without invalidating the underlying signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several defensive layers to mitigate these risks, but each possesses inherent limitations. One primary defense is Clear Signing, which translates complex calldata into human-readable parameters for the user. While helpful, Clear Signing relies entirely on accurate decoding libraries and assumes the signer possesses the attentiveness to recognize discrepancies between the displayed action and their true intent.
Simulation is another widely adopted defense, using a predicted chain state to forecast a transaction’s likely consequences before broadcasting. However, chain states are fluid and frequently change prior to block inclusion. Moreover, if malware compromises a signer’s local machine, a malicious payload can be swapped in at the exact moment of signing, bypassing simulation checks entirely. As demonstrated in the Radiant Capital post-mortem, both the wallet interface and the pre-execution simulation displayed the intended, benign transaction, while local malware substituted a harmful payload at signing time.
Contract-level checks and wallet guards also enforce runtime rules during EVM execution. For example, Uniswap automatically reverts a swap if the resulting output falls below a pre-defined amountOutMinimum parameter. Similarly, Safe’s checkAfterExecution hook enables a specialized guard contract to inspect account states post-execution and revert transactions that violate ownership or configuration rules.
Despite their utility, these existing mechanisms require developers to anticipate which specific state variables must be checked in advance. To read another contract’s storage, these guards are entirely dependent on the specific viewing functions exposed by that contract. While checking a standard token balance via balanceOf is straightforward, an uncooperative proxy contract is not required to expose its implementation address via a public getter function. Without such an explicit interface, a standard guard cannot read the underlying implementation storage slot directly. Crucially, these existing checks are fundamentally incapable of inspecting a transaction’s full, comprehensive set of net state changes. While a guard can verify that a specific balance remains untouched, it cannot query the EVM regarding unexpected side effects, leaving unforeseen modifications completely unchecked.
How Native Transaction Assertions Work
Native transaction assertions would fundamentally transform this paradigm by allowing onchain code to inspect the complete set of net state changes immediately after a transaction’s primary actions have executed. Utilizing read-only logic, an assertion compares starting and final values against a predefined, cryptographically bound rule. If the rule is violated, the transaction actions automatically revert.
Under this proposed model, the assertion rule is embedded directly within the transaction payload and signed alongside its primary actions. These rules can comprehensively govern net changes to native balances, storage slots, and code deployment parameters, as well as newly deployed contracts and emitted event logs. An assertion can mandate a strict minimum received amount, cap maximum spending, block unauthorized token approvals, preserve an account’s control logic, or whitelist a strict set of permitted state modifications.
However, the provenance of the rule matters just as much as the integrity of the check itself. If a compromised frontend interface writes the transaction assertion, an attacker could easily craft a rule that permits their own exploit. Therefore, a genuinely useful security rule must originate from an independently verified user intent, a standing institutional account policy, or underlying protocol logic that cannot be manipulated by vulnerable UI components.
Three Design Choices
Implementing native transaction assertions at the protocol level requires core developers to resolve several critical architectural design choices regarding what data the EVM exposes, how assertion code accesses that data, and where the associated opcodes are permitted to execute. First, designers must determine whether the exposed information should encompass state modifications, event logs, or a combination of both. Second, access mechanisms must be established, ranging from enumerating raw entries and querying specific values to copying entire sets of state differences directly into EVM memory. Finally, developers must decide whether the new opcodes should be restricted to specialized transaction types and distinct execution phases, or permitted universally across the EVM.
EIP-7906 as a Possible Solution
A leading proposal addressing these architectural questions is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. A frame transaction structures execution into an ordered sequence of distinct validation and action steps. EIP-7906 introduces a specialized, read-only POST_TX frame appended to the end of the execution pipeline specifically designed to evaluate transaction outcomes. While EIP-8141 has advanced toward inclusion in upcoming network upgrades, EIP-7906 has progressed to "Considered for Inclusion status, though its formal confirmation remains under active evaluation.
The EIP-7906 design exposes both comprehensive state modifications and event logs. State changes are systematically 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 that undergoes multiple writes during a transaction is reported as a single consolidated entry detailing its initial starting value and final ending value. If a storage slot ultimately reverts to its original value by the end of execution, it is omitted entirely to optimize efficiency.
To interact with this data, three new EVM opcodes are introduced. TXTRACE enables assertion logic to enumerate net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies targeted event data directly into memory.
Crucially, these specialized opcodes operate exclusively within the isolated POST_TX frame, which executes at the very conclusion of the transaction lifecycle as a static call. This ensures that the assertion can inspect final outcomes without altering network state. If an assertion rule is violated, the entire execution body reverts, but the transaction remains permanently recorded on-chain with a failed status, and the gas payer is fully 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 nuance of the EIP-7906 framework is that it does not inherently force transactions to include an assertion, meaning transaction builders retain the technical capability to omit them entirely. To protect individual users, modern cryptocurrency wallets must be engineered to ensure that every frame transaction constructed under the hood includes a robust, verified assertion. This rule can be derived dynamically from a local wallet-side simulation or enforced through standing security policies configured by the user.
For decentralized protocols, protecting user interactions requires smart contracts to verify that incoming calls originate from a valid frame transaction containing the exact, expected assertion. Protocols must reject legacy transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, callers and frontend integrations must adopt compatible frame transaction wrappers, meaning already deployed, immutable smart contracts cannot retroactively add this validation layer without wrapper migration.
Where Transaction Assertions Could Help
Beyond mitigating basic user-facing vulnerabilities and protocol exploits, native transaction assertions unlock powerful new paradigms for account abstraction and workflow automation. For example, assertions can significantly strengthen delegated execution. When users grant authorized agents or automation bots permission to act on their behalf, they typically constrain which contracts can be accessed, spending limits, and operational lifespans. Native assertions introduce an additional layer of constraint governing the precise economic output of every delegated transaction, allowing users to tightly govern both the actions taken and their ultimate results.
Protocols can also define standardized safety rules, mandating consistent verification checks for every caller utilizing compatible frame transactions. In solver-based execution architectures, a protocol can specify a strict required outcome while leaving decentralized solvers free to optimize execution routing. While these outcome guarantees apply natively within a single transaction on a single network—and thus cannot inherently span complex cross-chain bridges—assertions ensure that complex multi-step workflows reach their intended final state, guaranteeing that unused capital is properly returned and residual token approvals are revoked before block finalization.
Help Shape the Design
Research into native transaction assertions remains ongoing under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Core researchers are actively seeking feedback from wallet developers, infrastructure providers, and protocol engineers who would ultimately implement and rely on these standards. Teams interested in exploring practical use cases and contributing to the technical research are encouraged to reach out via email to the initiative or join the ongoing public discussions within the Ethereum Magicians EIP-7906 community forum threads.
Comments (0)