As part of the ongoing Ethereum Foundation Trillion Dollar Security initiative, core researchers and developers have identified blind signing and transaction uncertainty as critical user experience and security risks facing the ecosystem. To address these vulnerabilities, the initiative is actively exploring native transaction assertions as a foundational next step. Working alongside complementary defensive measures like Clear Signing, native transaction assertions aim to enforce a transaction’s final outcome directly at the protocol level, offering a robust safeguard where current defenses ultimately reach their limits.
This architectural exploration focuses on a fundamental dilemma in blockchain design: why a valid signature does not always guarantee the desired transaction result, how native transaction frameworks could protect everyday users and protocols alike, and the specific design choices currently under consideration. Among these, Ethereum Improvement Proposal (EIP) 7906, which introduces transaction assertions via a state diff opcode, stands out as a leading technical approach to bridging the gap between user intent and on-chain execution.
Two Ways a Signed Transaction Can Go Wrong
The root of the problem lies in the deterministic nature of the Ethereum Virtual Machine (EVM). The EVM executes exactly what a user authorizes, operating without independent judgment as to whether the resulting state aligns with the user’s actual desires. When an account holder signs a transaction, they are committing to a specific request. However, the final economic and technical outcome of that request depends entirely on the prevailing smart contract code and network state encountered during execution. Over the history of the network, significant capital has been lost either because individuals approved actions that differed fundamentally from what they believed they were authorizing, or because a legitimate request nevertheless produced an unintended, disastrous result.
Industry incidents highlight these distinct failure modes. The first category is an intent mismatch, vivid examples of which include the high-profile Bybit incident and the BadgerDAO attack. In both instances, a compromised or malicious frontend supplied a signing request that subtly diverged from what users thought they were reviewing and approving. During the Bybit security breach, signers unwittingly authorized the replacement of a Safe multi-signature wallet’s core implementation contract. Meanwhile, BadgerDAO users inadvertently granted an attacker sweeping permissions to spend tokens directly from their wallets.
The second major category is an outcome mismatch. In this scenario, the signer approves the exact request shown to them by their interface, but the underlying execution limits or the dynamic state of the blockchain allow a final outcome that directly conflicts with their economic goals or institutional safety policies. A prominent example occurred during an Aave and CoW collateral swap. A user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Unfortunately, deep liquidity for AAVE was far too thin to support a trade of that magnitude cleanly.
Because CoW’s gas ceiling mechanisms rejected more complex quotes during the verification phase, only a single verified quote returning roughly 329 aEthAAVE remained viable. Although the user interface displayed a stark 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 of these scenarios, a critical architectural element was missing: a trusted rule governing the resulting state, defined 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 contract remain completely unchanged. For BadgerDAO users, a standing rule would have permitted new token approvals exclusively for verified, published protocol contracts. For the Aave swap, a proper rule would have established a strict minimum acceptable output calculated independently of the interface’s quote, with solver-based settlement protocols requiring the assertion before accepting the order. Currently, however, Ethereum lacks a generalized mechanism for on-chain code to inspect the complete set 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 commitment covers specific parameters, including the target contract, the attached value, and the calldata. Yet, 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 time elapses between signing and execution, that state may have shifted dramatically. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can deviate widely from initial expectations.
This vulnerability is compounded by proxy architectures. The target contract specified in a transaction, or another contract it subsequently calls, may utilize a proxy pattern whose underlying implementation address changes right before execution. This means the actual code running on-chain can differ from what the user inspected during the signing process.
Furthermore, transaction ordering within a block introduces persistent hazards. A malicious actor can execute a sandwich attack, altering a liquidity pool’s price right before a user’s swap transaction executes, all without modifying the user’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several vital defenses to mitigate these risks, but each possesses inherent limitations. One primary defense is Clear Signing, which translates complex calldata into human-readable terms for the user. However, Clear Signing relies entirely on accurate decoding by the wallet and assumes the signer can reliably recognize when the presented action diverges from their true intent.
Simulation represents another widely adopted safeguard, predicting a transaction’s effects by running it against a selected historical or pending chain state. Because the state can change before inclusion, the transaction that ultimately gets mined may differ from the one originally simulated. A stark illustration of this limitation occurred during the Radiant Capital post-mortem, where both the wallet interface and the transaction simulation accurately displayed the intended interaction, but malware running locally on the signers’ machines substituted a malicious payload at the final moment of signing.
Contract-level checks and wallet guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap transaction if its final output falls below a pre-set amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook, allowing a security guard to inspect the account’s state after transaction execution and revert the entire transaction if it violates structural rules governing owners or configurations.
Nevertheless, 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 specific viewing functions exposed by that contract. While a token contract’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 an explicit interface, a standard wallet guard cannot read the underlying implementation slot directly. Most importantly, these existing checks cannot inspect a transaction’s full set of net state changes comprehensively, meaning unforeseen side effects can easily bypass traditional defenses.
How Native Transaction Actions and Rules Work
Native transaction assertions propose a powerful paradigm shift by enabling on-chain code to inspect the complete set of net state changes after a transaction’s primary actions have finished running. Using read-only logic, an assertion compares starting and final values against a predefined rule. If the execution violates this rule, the entire transaction reverts.
The assertion rule itself is bundled directly into the transaction and cryptographically signed alongside its actions. These rules can govern net changes across native currency balances, arbitrary storage slots, code deployments, newly deployed contracts, and emitted events. A rule can enforce a minimum receiving amount, cap maximum spending, block unauthorized token approvals, preserve an account’s core control logic, or restrict execution to a strictly specified set of state modifications.
Crucially, the origin of the rule matters just as much as the technical check itself. If a compromised frontend were able to write the assertion rule, it could easily craft an assertion that permits the attack. Therefore, a truly useful rule must originate from independently validated user intent, a permanent account security policy, or foundational protocol logic that a compromised component cannot manipulate.
Three Design Choices for Native Assertions
Designing native transaction assertions requires resolving complex architectural questions regarding what information the EVM exposes, how assertion code accesses that data, and where the associated opcodes are permitted to run. Core researchers must decide whether the exposed data should encompass state changes, emitted events, or both.
Access mechanisms present another design choice, ranging from enumerating raw entries and looking up specific values to copying the entire set of net changes directly into memory. Finally, developers must determine whether the new opcodes should be restricted to specialized transaction types and execution phases, or made universally available throughout the EVM.
EIP-7906 as a Possible Solution
A prominent technical proposal addressing these challenges is Ethereum Improvement Proposal 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 very end of the transaction lifecycle solely to verify the final outcome. While EIP-8141 has been slated for the upcoming Hegot upgrade, EIP-7906 has advanced to the status of being "Considered for Inclusion," though its official confirmation remains pending.
The proposed design exposes both net state changes and emitted events. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their respective code hashes. For instance, if a specific storage slot is written to five times during a single transaction, it appears in the trace as a single consolidated entry showing its initial starting value and its final ending value. If the slot finishes execution with its original value intact, it is omitted entirely.
To access this data, EIP-7906 introduces three new EVM instructions, or opcodes. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies an event’s logged data directly into memory.
These opcodes function exclusively inside the POST_TX frame, which executes as a static call at the conclusion of the transaction. This ensures that the assertion can inspect the final outcome without modifying state. If a rule violation is detected, the entire execution body reverts, but the transaction still appears in the block with a failed status, and the gas payer is charged for the computation consumed. This economic enforcement prevents malicious actors from forcing block builders to process deliberately failing transactions for free.
The Importance of Requiring Assertions
Because EIP-7906 does not mandate that every transaction include an assertion, transaction builders retain the technical ability to omit them. Consequently, robust security implementation requires careful coordination across the stack.
For transactions initiated by users, wallet providers must ensure that every frame transaction they construct automatically incorporates the necessary assertion. This rule can be derived dynamically from a simulation performed by the wallet or enforced via a standing user policy that governs all outgoing transactions.
Similarly, protected protocol functions must verify that incoming calls originate from frame transactions containing the exact required assertion. These contracts must reject ordinary transactions as well as frame transactions carrying missing or incorrect assertions. As a result, callers and protocol integrations must adopt compatible frame transactions, meaning already deployed immutable contracts cannot retroactively add this verification check.
Where Transaction Assertions Could Help
Beyond immediate user and protocol security, native transaction assertions unlock broader functional use cases across the ecosystem. For instance, they could significantly strengthen automated delegation. When a user authorizes an agent to act on their behalf, they typically limit which contracts the agent can interact with, how much capital it can spend, and the duration of its permissions. Assertions introduce a granular way to constrain the economic outcome of every transaction executed by the agent, ensuring tight control over both actions and final results.
Protocols can also define standardized rules, requiring identical safety checks for any caller utilizing a frame transaction. In advanced solver execution models, a protocol can specify the required financial outcome while leaving solvers free to determine the most efficient execution route. While this guarantee applies strictly within the boundaries of a single transaction on a single network—and thus cannot cover cross-chain bridging routes—assertions can effectively verify that complex workflows reach their intended final state, ensuring any unused tokens are returned to the user and residual approvals are promptly revoked.
Help Shape the Design
The research and engineering surrounding native transaction assertions remain active components of the Ethereum Foundation Trillion Dollar Security initiative. Researchers are actively seeking feedback from wallet developers, security auditors, and protocol teams who would ultimately rely on these primitives.
Stakeholders interested in exploring specific use cases, contributing to the ongoing research, or participating in technical discussions are encouraged to reach out to the initiative or engage directly with the EIP-7906 community discussion threads. Additional information regarding ongoing risk controls and priority security work remains available through official project channels.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
