As the Ethereum ecosystem continues to scale and manage unprecedented volumes of economic activity, the Ethereum Foundation’s Trillion Dollar Security initiative has identified persistent vulnerabilities centered around blind signing and transaction uncertainty. To address these critical user experience risks, developers and researchers are actively exploring native transaction assertions as a foundational next step to strictly enforce a transaction’s final economic and structural outcome. Working alongside complementary defense frameworks like Clear Signing, this ongoing research aims to fundamentally change how transactions are validated, executed, and safeguarded on the network.
This development addresses a foundational operational reality of the Ethereum Virtual Machine: a valid cryptographic signature does not inherently guarantee that the transaction execution will yield the result a user intended. By investigating native transaction assertions, the Ethereum Foundation seeks to protect users and protocols where current, traditional defenses ultimately fall short. The architectural design choices behind these potential upgrades—highlighted by proposals such as EIP-7906, which introduces transaction assertions via a state diff opcode—represent a major potential shift in how onchain safety rules are defined, verified, and executed.
Two Ways a Signed Transaction Can Go Wrong
The core security challenge originates from the deterministic nature of Ethereum execution. The network executes transactions precisely as they are authorized, operating without external judgment regarding whether the outcome aligns with the user’s actual desires. While a digital signature securely commits to a specific request, the final result depends entirely on the smart contract code and the blockchain state encountered at the exact moment of execution. Historically, users have experienced catastrophic financial losses due to two distinct categories of failure: intent mismatches and outcome mismatches.
The first category, an intent mismatch, occurs when a user authorizes an action that differs radically from what they believed they were approving. High-profile security breaches, such as the widely documented Bybit incident and the BadgerDAO attack, vividly illustrate this vulnerability. In both security failures, compromised frontend interfaces successfully supplied signing requests that concealed malicious payloads behind familiar user interfaces. During the Bybit incident, signers authorized a transaction that inadvertently replaced their Safe account’s implementation contract, whereas BadgerDAO users unknowingly granted malicious actors sweeping permissions to drain their deposited tokens.
The second major category involves outcome mismatches. In these scenarios, the signer legitimately approves the exact request presented to them, but existing pool limits, transaction sequencing, or the live state of the blockchain allow an execution result that directly conflicts with their economic goals or standing security policies. A prominent example unfolded during the Aave and CoW collateral swap event, where a user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because market liquidity for AAVE was vastly insufficient to absorb a trade of that magnitude, and because CoW’s strict gas ceiling mechanisms automatically 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 severe 99.9 percent price impact warning and explicitly required confirmation that the entire transaction value could be lost, the user signed the transaction anyway and ultimately received tokens valued at roughly $36,000. In all three of these historical cases, a vital protective layer was entirely absent: a trusted, independent rule governing the resulting state, defined separately from the transaction builder and strictly enforced during execution. A native rule in the Bybit scenario would have mandated that the approved Safe implementation contract remain completely immutable. A defensive rule for BadgerDAO users would have restricted new token approvals exclusively to verified, officially published Badger contracts. Similarly, an Aave user safety policy could have established an immutable minimum acceptable output, calculated independently of the quotes provided by the interface. Currently, however, Ethereum lacks a generalized native mechanism enabling onchain code to inspect the comprehensive set of net state changes and emitted events produced by a transaction before final settlement.
What a Signature Does Not Control
When an end user signs a transaction, their cryptographic commitment applies strictly to the requested action parameters, including the designated target contract, value amount, and associated calldata. However, the EVM executes this call against the exact contract code and blockchain state present at the moment of inclusion, both of which may have shifted drastically since the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can diverge unpredictably from user expectations.
The target contract itself, or any secondary contracts it interacts with via external calls, may utilize proxy architectures whose underlying implementation logic can change prior to execution. As a result, the code that ultimately executes can differ substantially from what the user initially inspected. Furthermore, transaction ordering within a block introduces significant volatility. A classic sandwich attack, for instance, can manipulate a liquidity pool’s price immediately before a user’s swap executes, altering market conditions without ever requiring a modification to the user’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has progressively deployed several defensive mechanisms to mitigate these operational risks, yet each possesses inherent limitations. One primary defense is Clear Signing, which translates raw calldata into human-readable terms to inform users about the exact nature of their requested action. Nevertheless, Clear Signing relies entirely on accurate decoding pipelines and assumes that the signer can correctly recognize if a presented action deviates from their actual intent.
Simulation tools represent another widely adopted safeguard, predicting a transaction’s precise effects by modeling them against a selected snapshot of the chain state. Because the underlying chain state can fluctuate before block inclusion, and because a sophisticated malware payload can substitute a malicious transaction at the final signing stage—as seen in the Radiant Capital post-mortem, where wallet interfaces and simulations displayed benign intentions while local malware injected malicious execution steps—simulation alone cannot guarantee absolute protection.
Contract-level checks and wallet guards also enforce defensive rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-calculated amountOutMinimum threshold. Similarly, Safe’s checkAfterExecution hook enables a custom security guard to inspect an account’s state configuration immediately after execution, reverting transactions that violate established parameters for owners or settings. However, both methodologies require developers to anticipate and select which specific storage slots to check in advance. To read another contract’s storage variables, these mechanisms depend entirely on the specific view functions that the target contract exposes. While checking a standard ERC-20 token balance via balanceOf is straightforward, upgradeable proxy contracts are not strictly required to expose their implementation slot via a public function. Without such an explicit interface, conventional guards cannot read the implementation address directly.
Crucially, these existing checks cannot inspect a transaction’s comprehensive set of net state changes. While a security guard can verify that a specific account balance remains untouched, it cannot query the EVM to evaluate every other modification that occurred during the transaction lifecycle, leaving unforeseen side effects entirely unmonitored.
How Native Transaction Assertions Work
To overcome these structural limitations, native transaction assertions would empower onchain code to inspect the complete set of net state changes generated after a transaction’s core actions have fully completed execution. Utilizing lightweight, read-only logic, a native assertion compares the starting and final values of targeted variables against a predefined safety rule. If the evaluation of this rule fails, the entire transaction execution reverts.
The assertion rule itself is bundled directly into the transaction payload and cryptographically signed alongside the primary actions. These rules can govern net modifications to native balances, storage slots, newly deployed contract bytecode, and emitted event logs. By establishing these constraints, users can mandate minimum output amounts, cap spending limits, block unauthorized token approvals, preserve account control logic, or restrict transaction execution to a strictly whitelisted set of state changes.
However, the provenance of the rule is just as critical as the verification logic itself. If a compromised frontend interface writes a permissive assertion rule tailored to facilitate an exploit, the protective value is lost. Therefore, a secure rule must originate from independently verified user intent, a permanent account security policy, or underlying protocol logic that cannot be manipulated by untrusted intermediaries.
Three Design Choices
Implementing native transaction assertions at the protocol level requires complex decisions regarding how the EVM exposes execution data, how assertion code interacts with that data, and where specific opcodes are permitted to execute. Core design considerations include determining whether the exposed information should encompass state modifications, emitted event logs, or both. Access mechanisms must also be evaluated, ranging from basic entry enumeration and targeted value lookups to copying complete sets of state changes into memory. Additionally, architects must decide whether new evaluation opcodes should be restricted to specific transaction categories and execution phases or permitted universally across the EVM.
EIP-7906 as a Possible Solution
One prominent approach currently under discussion is EIP-7906, which builds directly upon the frame transaction architecture outlined in EIP-8141. Under this framework, a frame transaction consists of an ordered sequence of distinct validation and action steps. EIP-7906 proposes adding a dedicated, read-only POST_TX frame at the concluding phase of transaction execution specifically designed to evaluate the overall outcome. While EIP-8141 has advanced toward inclusion in the Hegotá network upgrade, EIP-7906 has reached "Considered for Inclusion" status while awaiting formal confirmation.
The EIP-7906 design exposes both comprehensive state changes and event data to the evaluation frame. State modifications are reported as net differences in native ETH balances and storage configurations, alongside newly deployed smart contracts and their corresponding code hashes. For instance, a storage slot that is written to multiple times during a complex execution path is reported as a single consolidated entry displaying its initial starting value and its final ending value. If a storage slot ultimately reverts to its original value by the end of execution, it is omitted entirely.
To interact with this data, the proposal introduces three specialized EVM instructions. The TXTRACE opcode enumerates net state changes and event logs, TXDIFF retrieves specific starting and final values for designated addresses and storage slots, and EVENTDATACOPY copies specific event payload data directly into memory.
These operational opcodes function exclusively within the POST_TX frame, executing as a static call at the very end of the transaction lifecycle. This architectural constraint allows the assertion logic to inspect the final execution outcome without introducing unintended state modifications. If an assertion rule violation occurs, the entire execution body reverts. Nevertheless, the transaction remains recorded within the block with a failed execution status, and the designated gas payer is charged for the computational resources consumed. This economic enforcement prevents malicious actors from exploiting network builders by forcing them to process deliberately failing transactions for free.
The Assertion Has to Be Required
Because EIP-7906 does not mandate that every Ethereum transaction include an assertion, transaction builders retain the technical capability to omit them entirely. Consequently, wallet providers must ensure that every frame transaction they construct automatically incorporates the necessary validation assertions, derived either from comprehensive local simulations or from standing security policies governing all user activity.
Similarly, decentralized finance protocols seeking to leverage this security model must enforce that incoming calls originate exclusively from frame transactions containing the exact required assertion logic. Protocols must be programmed to systematically reject standard transactions as well as frame transactions carrying missing or improperly configured assertions. Consequently, callers and integration partners would need to adopt compatible frame transactions, meaning already deployed, immutable smart contracts cannot retroactively add this native verification check.
Where Transaction Assertions Could Help
Beyond enhancing standard user and protocol security, native transaction assertions unlock diverse utility across the broader Web3 ecosystem. For instance, they can significantly strengthen account delegation frameworks. When delegating operational authority to automated agents, users can enforce strict constraints regarding which contracts the agent may interact with, how much capital it can expend, and how long its permissions remain valid. Transaction assertions add an extra layer of governance by constraining the economic outcome of every transaction, ensuring precise control over both agent actions and final results.
Protocols can also define standardized safety rules, mandating identical verification checks for every participant utilizing a frame transaction. Within solver-based execution models, a protocol can specify the required economic outcome while permitting decentralized solvers complete flexibility regarding routing and execution paths. Furthermore, assertions can verify that complex multi-step workflows reach their intended final state, ensuring that unspent tokens are automatically returned to the user and that any residual token approvals are revoked before final settlement.
Help Shape the Design
Research and development surrounding native transaction assertions remain actively underway as part of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are encouraging wallet developers, protocol engineers, and security experts to contribute feedback and explore practical use cases. Interested participants can contact the security initiative directly or engage with ongoing community discussions on the Ethereum Magicians governance forums to help guide the future trajectory of EIP-7906 and associated risk control frameworks.
Comments (0)