As part of the broader 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 across the ecosystem. To combat these persistent vulnerabilities, the initiative is actively exploring native transaction assertions as a fundamental next step to enforce a transaction’s exact final outcome. Working in tandem with initiatives like Clear Signing, this technical exploration seeks to redefine how transactions are validated, executed, and constrained on the network.
The core issue stems from a foundational characteristic of how Ethereum operates. The Ethereum Virtual Machine executes instructions precisely as authorized, without inherently judging whether the ultimate result aligns with what the user actually intended. While a digital signature commits a user to a specific request, the final outcome of that request depends entirely on the prevailing contract code and blockchain state encountered during execution. Over 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 still yielded an economic or operational result that ran counter to their goals.
These security challenges generally manifest in two distinct ways: intent mismatches and outcome mismatches. Intent mismatches occur when a user is misled or tricked into signing a transaction that does not match their perception. Prominent historical examples include the high-profile Bybit incident and the BadgerDAO attack. In both of these events, compromised frontend interfaces supplied signing requests that deviated sharply from what users thought they were approving. Specifically, Bybit signers authorized the replacement of a Safe multi-signature wallet’s core implementation contract, while BadgerDAO users unknowingly granted malicious actors sweeping permissions to spend their underlying tokens.
Conversely, outcome mismatches represent scenarios where the signer accurately approves the request shown to them, but structural limits or shifting blockchain state parameters still allow for a result that violates their economic interests or standing safety policies. A stark illustration of this dynamic occurred during the Aave and CoW collateral swap event. In that instance, a user attempted to execute a massive trade swapping approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because the available market liquidity for AAVE was far too thin to support a trade of that magnitude without catastrophic slippage, and because CoW’s gas ceiling mechanisms rejected more complex quotes during the verification phase, only a single verified quote of roughly 329 aEthAAVE remained viable. Although the interface displayed a stark 99.9 percent price impact warning and required explicit manual confirmation of a potential total loss, the user signed the transaction regardless, ultimately receiving tokens valued at a mere $36,000.
Across all of these disruptive incidents, a common architectural gap remained glaringly apparent: the complete absence of a trusted rule governing the resulting state, defined independently of the transaction builder and enforced natively during execution. In the Bybit scenario, a robust rule would have mandated that the approved Safe implementation contract remain strictly unchanged. For a BadgerDAO user, an automated rule could have restricted new token approvals exclusively to verified, published protocol contracts. In the Aave collateral swap, a predetermined rule would have established a strict minimum acceptable output amount calculated independently of the interface’s displayed quotes, ensuring the transaction would instantly abort if market conditions deteriorated past a safe threshold. Currently, however, Ethereum lacks a generalized mechanism that allows onchain code to comprehensively inspect the full set of net state changes and emitted events produced over the course of a transaction.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is necessary to examine the precise limitations of an Ethereum cryptographic signature. When a user signs a transaction, they are committing strictly to a requested action, which includes the designated target address, value, and input calldata. However, the EVM executes this call against whatever contract code and state happen to be present at the exact moment the transaction is included in a block, which may have shifted significantly since the moment of signing. Consequently, the resulting net balance modifications, storage updates, and emitted events can diverge wildly from user expectations.
The target contract specified in a transaction, or any secondary contract it calls, may rely on proxy patterns where the underlying implementation logic changes before execution takes place. This means the code that ultimately runs can be fundamentally different from what the user or their wallet inspected during the review phase. Furthermore, transaction ordering within a block introduces profound unpredictability. Miner and validator ordering, or adversarial exploitation like sandwich attacks, can shift liquidity pool prices and alter the prevailing state parameters immediately before a user’s transaction executes, all without altering a single byte of the user’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has progressively deployed several defensive layers to mitigate these risks, but each possesses inherent boundaries. One prominent approach is Clear Signing, a method designed to translate raw calldata into human-readable details explaining what an action requests. While helpful, Clear Signing relies entirely on accurate protocol decoding and assumes that the human signer will actively recognize when the displayed action diverges from their true intent.
Another widely used defense is transaction simulation, which predicts the effects of a transaction by testing it against a selected snapshot of the chain state. Because chain states are fluid and can shift prior to block inclusion, the state during simulation frequently differs from the state at the moment of actual execution. Illustrating this vulnerability, the Radiant Capital security incident demonstrated a scenario where both the wallet interface and the underlying simulation correctly displayed the intended transaction, yet malware operating locally on the signers’ machines managed to substitute a malicious payload precisely at the moment of signing.
Contract-level checks and wallet guards also attempt to enforce rules during EVM execution. For example, Uniswap automatically reverts a token swap if the resulting output falls below a user-defined threshold known as amountOutMinimum. Similarly, the Safe wallet architecture utilizes a checkAfterExecution hook, allowing a designated security guard to inspect the account’s state immediately after execution and revert transactions that violate established configuration or ownership policies.
Despite their utility, these existing mechanisms require developers and users to choose which specific state variables to check in advance. To read the storage values of external contracts, these guards are strictly dependent on the specific viewing functions exposed by those contracts. While checking a token’s balanceOf function is straightforward, an arbitrary proxy contract is under no obligation to expose its implementation address via a public function. Without a standardized interface or native instrumentation, a security guard cannot directly read implementation storage slots or evaluate unexposed state parameters. Crucially, these legacy checks remain entirely incapable of inspecting a transaction’s comprehensive net set of changes across the entire state tree. While a guard can verify that a specific balance remains untouched, it cannot natively query the EVM to uncover secondary or collateral effects that it was not explicitly coded to monitor.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions are being conceptualized as an architectural enhancement that would empower onchain code to inspect the complete set of net state changes after a transaction’s core actions have fully executed. Operating through read-only logic, an assertion would systematically compare starting and final state values against a predefined rule. If the execution outcome violates the parameters of that rule, the transaction’s actions automatically revert.
Under this model, the governing rule is bundled directly into the transaction itself and signed alongside the primary execution steps. These assertions can encompass net modifications to native balances, storage slots, and code execution paths, as well as newly deployed contracts and emitted events. This flexibility allows users and protocols to enforce minimum output thresholds, cap spending allowances, block unauthorized token approvals, preserve account control logic, or restrict execution outcomes to a rigidly specified set of changes.
However, the source of the assertion rule is paramount to its security utility. If a compromised frontend interface were able to arbitrarily dictate the assertion logic, an attacker could simply write an assertion that accommodates and permits the malicious exploit. Therefore, a genuinely useful assertion rule must derive from an independently verified expression of user intent, a standing and immutable account policy, or foundational protocol logic that cannot be manipulated by vulnerable or untrusted UI components.
Three Design Choices
Designing native transaction assertions requires deep consideration regarding what specific execution information the EVM should expose, how assertion code accesses that data, and where the corresponding opcodes are permitted to execute. Architectural decisions involve determining whether to expose state changes, event logs, or both simultaneously. Potential access mechanisms range from enumerating entries sequentially and looking up specific address values to copying entire sets of state changes directly into memory for programmatic evaluation. Furthermore, designers must decide whether the new opcodes should be restricted exclusively to specialized transaction types and distinct execution phases, or made universally available throughout the EVM environment.
EIP-7906 as a Possible Solution
A prominent technical proposal addressing these challenges is EIP-7906, which builds natively upon the frame transaction framework defined in EIP-8141. Within this paradigm, a frame transaction contains an ordered sequence of discrete validation and action steps. EIP-7906 introduces a dedicated, read-only POST_TX execution frame at the very end of the transaction lifecycle specifically designed to inspect the final outcome. While EIP-8141 has progressed toward inclusion in the upcoming Hegotá network upgrade, EIP-7906 has advanced to a "Considered for Inclusion" status while awaiting final confirmation.
The proposed design exposes both net state changes and event logs to the evaluation logic. State modifications are reported as net differences in native ETH balances and storage slots, alongside newly deployed contract addresses and their corresponding code hashes. For instance, if a specific storage slot is modified multiple times during the course of a transaction, it appears as a single unified entry detailing its initial and final values. If a storage slot ultimately concludes its execution cycle matching its original value, it is omitted entirely from the trace.
Access to this data is facilitated by three proposed EVM opcodes. The TXTRACE instruction enumerates net state changes and emitted events, TXDIFF retrieves starting and final values for specific target addresses and storage slots, and EVENTDATACOPY copies event payloads directly into working memory. These specialized opcodes are designed to function exclusively within the POST_TX frame, which executes as a static call at the conclusion of the transaction. This ensures that the assertion logic can comprehensively evaluate the execution outcome without altering state variables. If an assertion rule is violated, the entire execution body reverts, but the transaction remains permanently recorded on the blockchain with a failed status, ensuring that the gas payer is properly charged for the consumed computational resources. This economic disincentive prevents malicious actors from forcing block builders to process deliberately failing transactions for free.
The Assertion Has to Be Required
A critical nuance of the EIP-7906 framework is that it does not inherently mandate transactions to include an assertion, meaning that transaction builders retain the technical capability to omit them. Consequently, user-facing wallets must actively ensure that every frame transaction they construct incorporates the necessary assertion logic, drawn either from automated pre-execution simulations or from standing account policies configured by the user.
Similarly, protected protocol functions must independently verify that incoming calls originate from frame transactions containing the exact required assertions. These protocols must reject ordinary legacy transactions as well as frame transactions carrying missing or improperly formulated assertions. Consequently, widespread adoption requires calling contracts and ecosystem integrations to natively support compatible frame transactions, presenting an adoption hurdle for already deployed immutable contracts that cannot easily add such verification checks.
Where Transaction Assertions Could Help
Beyond fortifying basic user and protocol security, native transaction assertions present potential utility across several broader decentralized finance use cases. For example, they could substantially strengthen account delegation models. When delegating operational authority to automated agents or secondary keys, users could enforce strict limits not only on which contracts the agent may interact with and how much capital it can expend, but also on the guaranteed outcome of every executed transaction, constraining both agent activity and resulting portfolio state.
Protocols could likewise define native rules requiring uniform safety checks for any caller utilizing a frame transaction. In advanced solver-based execution architectures, a protocol could specify the required economic outcome while leaving solvers unrestricted in finding the most efficient execution route. While such guarantees would operate strictly within the boundaries of a single transaction on a specific network rather than spanning multi-chain routing paths, assertions could nonetheless ensure that complex workflows reliably reach their intended final state, with residual tokens successfully returned to users and unneeded approvals automatically revoked.
Help Shape the Design
Research and engineering solutions surrounding native transaction assertions remain under active development as part of the Ethereum Foundation’s Trillion Dollar Security initiative. Developers, wallet architects, and protocol teams interested in utilizing these capabilities are encouraged to engage with the research groups. Technical feedback and collaboration inquiries can be directed to the initiative via email, or through ongoing community discussions on developer forums and EIP implementation threads as the technical specifications continue to evolve ahead of upcoming network upgrades.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
