As the Ethereum ecosystem continues to scale and secure increasingly vast amounts of economic value, core developers and researchers are intensifying their focus on foundational user experience and security vulnerabilities. Spearheaded by the Ethereum Foundation’s Trillion Dollar Security initiative, researchers have identified blind signing and transaction uncertainty as critical risks facing everyday users and sophisticated protocols alike. To address these vulnerabilities, the ecosystem is actively exploring the implementation of native transaction assertions as a powerful next step to enforce a transaction’s final economic and structural outcome, working alongside complementary defenses like Clear Signing.
This ongoing research addresses a fundamental structural reality of how the Ethereum Virtual Machine operates: the simple fact that possessing a valid cryptographic signature does not always guarantee the specific transaction result a user intended. By investigating native transaction mechanisms—with Ethereum Improvement Proposal (EIP) 7906 standing out as a prominent approach utilizing the State Diff Opcode—the Ethereum community aims to protect users in scenarios where today’s conventional defenses inevitably reach their limits.
Two Ways a Signed Transaction Can Go Wrong
The core security challenge begins with the mechanical nature of how Ethereum processes state. The Ethereum Virtual Machine executes precisely what it is authorized to do, operating without inherent judgment regarding whether the ultimate result aligns with the user’s actual intent. A cryptographic signature successfully commits to a specific request, but its final outcome depends entirely on the code execution path and the state of the blockchain at the exact moment the transaction is mined. Over the history of the network, users have suffered substantial financial losses either because they inadvertently approved a malicious action that differed radically from what they believed they were signing, or because a legitimate request produced an economically disastrous result due to shifting market conditions.
Security analysts broadly categorize these failures into two distinct types: intent mismatches and outcome mismatches. The first category, intent mismatches, is prominently illustrated by historical security incidents such as the Bybit compromise and the BadgerDAO attack. In both of these high-profile events, a compromised frontend or interface supplied a signing request that fundamentally differed from what the users believed they were authorizing. During the Bybit incident, affected signers unknowingly authorized the replacement of a Safe multi-signature wallet’s core implementation contract. Similarly, BadgerDAO users granted malicious actors broad permissions to drain their token balances because the interface masked the true nature of the underlying calldata.
The second category involves outcome mismatches, where a signer accurately approves the request shown to them by their wallet, but existing limits or unexpected real-time state changes produce an outcome that directly conflicts with their economic goals or standing safety policies. A clear example of this dynamic occurred during the Aave and CoW collateral swap event. In that scenario, a user attempted to swap roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because onchain liquidity for AAVE was far too thin to absorb a trade of that magnitude without catastrophic slippage, and because gas ceiling constraints during verification rejected more complex alternative quotes, only one verified quote remained available, offering approximately 329 aEthAAVE. Although the user interface displayed a severe 99.9 percent price impact warning and explicitly required confirmation that the entire value could be lost, the user signed the transaction anyway, ultimately receiving tokens worth a mere $36,000.
In all three of these disparate cases, a common architectural deficiency emerges: the complete lack of a trusted, binding rule over the resulting state, defined independently of the transaction builder and strictly enforced during execution. In the Bybit scenario, an independent rule would have mandated that the approved Safe implementation contract remain entirely immutable. For a BadgerDAO user, a protective rule would have restricted new token spending approvals exclusively to verified, published protocol contracts. In the Aave scenario, a pre-calculated user rule would have established a strict minimum acceptable output threshold, calculated completely independently of the dynamic quote displayed by the application’s interface. Currently, however, Ethereum lacks a generalized onchain mechanism enabling executing code to inspect the full set of net state changes and emitted events produced by a transaction before final settlement.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is necessary to examine the precise limitations of what an Ethereum signature actually controls. When a user signs a transaction, they are committing cryptographic consent to a specific action request, which includes the designated target address, value, and calldata parameters. However, the EVM executes this call against whatever contract code and blockchain state happen to be present at the exact block height and position when the transaction finally runs. Because mempool conditions are dynamic, the state environment often changes significantly between the moment of signing and the moment of execution.
Consequently, the resulting net balance shifts, storage modifications, and emitted events can diverge wildly from the user’s initial expectations. The target contract specified in the transaction, or another contract it invokes via external calls, may utilize an upgradeable proxy pattern whose underlying implementation changes before execution, meaning the code that actually runs differs from what the user or their wallet inspected. Furthermore, transaction ordering within a block can alter the immediate state environment. For instance, a malicious sandwich attack can manipulate a decentralized exchange liquidity pool’s price right before a user’s swap executes, altering the economic outcome without modifying the bytes of the user’s signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several important defensive mechanisms over the years to mitigate these risks, but each possesses inherent boundaries. One primary defense is Clear Signing, which aims to translate complex calldata into human-readable descriptions for the user. While helpful, Clear Signing relies entirely on accurate decoding libraries and assumes the signer possesses the technical literacy to recognize when the decoded action deviates from their original intent.
Another common defense is transaction simulation, which predicts the localized effects of a transaction using a snapshot of the current chain state. Despite its utility, chain state can change before block inclusion, and a sophisticated malware payload on a compromised user device can substitute a malicious payload at the exact moment of signing, bypassing the preview entirely. As demonstrated in the Radiant Capital security post-mortem, both the wallet interface and the pre-execution simulation accurately displayed the intended, benign transaction, while local malware secretly injected a malicious payload during the signing process itself.
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 drops below a predefined minimum amount. Similarly, Safe accounts utilize execution hooks like checkAfterExecution to inspect an account’s state configuration after code runs, reverting transactions that violate ownership rules.
However, both of these approaches require developers to anticipate which specific state variables to check in advance. To read another contract’s storage, they depend heavily on the specific view functions that the target contract chooses to expose. While checking a token’s balance via a standard function is straightforward, an arbitrary proxy contract is not required to expose its underlying implementation slot through a standard read function. Without such an interface, a traditional wallet guard cannot read the implementation storage slot directly, leaving blind spots where unmonitored state changes can take effect without interference.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions are being designed to let onchain code inspect the complete set of net state changes immediately after a transaction’s primary actions have finished executing. An assertion utilizes strict, read-only logic to compare starting and final values against a predefined rule. If the rule evaluation fails, the transaction’s actions automatically revert, preventing unauthorized state alterations from finalizing.
The assertion rule itself is bundled directly into the transaction payload and is cryptographically signed alongside the primary actions. These rules can govern net changes across native asset balances, storage slots, and contract code, as well as newly deployed contracts and emitted event logs. A user or protocol could use an assertion to mandate a minimum acceptable received amount, cap spending limits, block unauthorized token approvals, preserve an account’s control logic, or restrict execution to a strictly specified set of state modifications.
Crucially, the origin of the assertion rule is as vital as the verification mechanism itself. If a compromised frontend were able to arbitrarily dictate the assertion rule, it could simply write a rule that permits the attack. Therefore, a genuinely useful assertion rule must derive from an independently approved user intent, a standing account policy, or core protocol logic that a compromised interface component cannot alter or bypass.
Three Design Choices
Designing native transaction assertions at the protocol level requires core developers to resolve several complex architectural trade-offs regarding what information the EVM exposes, how assertion code accesses that data, and where the necessary opcodes are permitted to run. Specifically, developers must decide whether the EVM should expose net state changes, event logs, 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. Furthermore, protocol architects must determine whether the new opcodes should be restricted exclusively to specialized transaction types and execution phases, or made available generally throughout the EVM.
EIP-7906 as a Possible Solution
One of the most prominent proposals addressing these design questions is EIP-7906, which builds directly upon the frame transactions introduced in EIP-8141. A frame transaction contains an ordered sequence of discrete validation and action steps. EIP-7906 extends this architecture by appending a read-only post-execution frame at the very end of the transaction lifecycle specifically designed to evaluate the transaction’s ultimate outcome. While EIP-8141 has advanced toward inclusion in upcoming network upgrades, EIP-7906 has progressed to being actively considered for inclusion, though it is not yet formally confirmed for an imminent hard fork.
The EIP-7906 design explicitly exposes both state modifications and event logs. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contract addresses and their corresponding code hashes. To maintain efficiency, a storage slot that is written to multiple times within a single transaction is reported as a single consolidated entry detailing only its initial starting value and its final ending value. If a storage slot ultimately reverts to holding its original value by the end of the transaction, it does not appear in the trace at all.
To interact with this data, the proposal introduces three new EVM instructions, or opcodes. The first instruction enumerates net state changes and events, the second retrieves starting and final values for specific addresses and storage slots, and the third copies event data directly into memory for programmatic inspection.
These powerful opcodes operate exclusively within the designated post-execution frame, executing as a static call at the conclusion of the transaction. This ensures that the assertion logic can inspect the final outcome without accidentally mutating state. If the assertion rule is violated, the entire execution body reverts, but the transaction remains recorded onchain with a failed status, and the gas payer is charged for the computational resources consumed. This economic penalty is essential to prevent malicious actors from spamming block builders with deliberately failing transactions for free.
The Assertion Has to Be Required
A key operational hurdle associated with EIP-7906 is that it does not inherently mandate that every transaction must include an assertion, meaning transaction builders retain the technical capability to omit them entirely. To achieve robust security, wallets must be programmed to ensure that every frame transaction they construct includes the necessary validation assertions, drawing rules either from automated pre-execution simulations or from standing user security policies.
Similarly, for decentralized protocols wishing to leverage this technology, protected smart contract functions must be designed to verify that incoming calls originate from frame transactions containing the exact required assertions. These contracts must explicitly reject standard transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, protocol integrations and calling applications must adopt compatible frame transaction formats, meaning already deployed immutable smart contracts cannot retroactively enforce these checks without new wrapper infrastructure.
Where Transaction Assertions Could Help
Beyond immediate user security and threat mitigation, native transaction assertions offer significant utility across a variety of advanced Ethereum use cases. For instance, they can substantially strengthen account delegation frameworks. When delegating operational authority to an automated agent or smart account session key, users can already restrict which contracts the agent may interact with, how much capital it can spend, and how long its permissions remain active. Transaction assertions introduce an additional layer of constraint governing the precise economic output of each transaction, allowing users to tightly control not only what an agent is permitted to do, but what the resulting state of those actions must look like.
Protocols can also utilize assertions to enforce standardized safety checks across all inbound user interactions handled by solvers or third-party relayers. In solver-based execution architectures, a protocol can specify the exact required outcome while leaving the solver free to determine the optimal routing path to achieve it. This guarantee, however, applies strictly within the boundaries of a single transaction on a single network, and would not natively span multi-chain cross-rollup pathways. Additionally, assertions can verify that complex multi-step workflows successfully reach their intended final state, ensuring that unused tokens are correctly returned to the user and that any temporary spending approvals are fully revoked before the transaction concludes.
Help Shape the Design
Research and development surrounding native transaction assertions remain active as part of the Ethereum Foundation’s broader Trillion Dollar Security initiative. Core researchers are actively seeking feedback and collaboration from wallet developers, security auditors, and protocol engineering teams who would ultimately implement and rely on these features. Teams interested in exploring potential use cases, contributing to research discussions, or reviewing technical specifications can connect via the official initiative email or participate in the ongoing EIP-7906 community discussion threads. Further details regarding priority security work and ongoing risk control initiatives continue to be published through the Trillion Dollar Security portal.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
