As the Ethereum ecosystem continues to scale in economic value and global adoption, the Ethereum Foundation’s Trillion Dollar Security initiative is turning its attention to persistent user experience risks, specifically blind signing and transaction uncertainty. Core researchers and developers involved in the initiative are actively exploring native transaction assertions as a critical next step to enforce a transaction’s exact final outcome onchain. This effort is designed to run alongside broader ecosystem advancements like Clear Signing, aiming to provide a multi-layered defense system that protects users at the execution layer where today’s conventional safety mechanisms ultimately stop.
The core motivation behind this research stems from a fundamental reality of how Ethereum operates by design. The Ethereum Virtual Machine (EVM) executes instructions precisely as they are authorized, without judging whether the resulting state or economic trade-off matches what the user actually intended. When a user signs a transaction, they are committing to a specific request, but the ultimate outcome depends heavily on the prevailing code and state encountered during execution. Over the history of the network, users and protocols have lost significant funds either because they approved a request that differed radically from what they believed they were signing, or because a legitimate request produced an economic outcome that flew in the face of their original intentions.
Two Ways a Signed Transaction Can Go Wrong
Security analysts broadly categorize these failures into two distinct phenomena: intent mismatches and outcome mismatches. Intent mismatches occur when the transaction presented to a user’s wallet or signing interface has been tampered with or replaced. High-profile security incidents in recent years underscore this vulnerability. During the Bybit incident and the BadgerDAO attack, compromised frontends successfully supplied signing requests that completely diverged from the user’s perception. In the Bybit event, signers unwittingly authorized the replacement of a Safe account’s core implementation contract, whereas BadgerDAO users inadvertently granted malicious actors broad permissions to drain their tokens.
The second major category, outcome mismatches, presents a different kind of risk. In these scenarios, the signer approves the exact request shown to them by their interface, but variable market conditions, liquidity constraints, or shifting block states produce a result that severely conflicts with their economic goals or standing safety policies. A striking example of this occurred during the Aave and CoW collateral swap event. A user attempted to execute a massive trade, swapping approximately $50.4 million worth of aEthUSDT for aEthAAVE. Due to thin liquidity in the AAVE market for a trade of that magnitude, combined with CoW’s gas ceiling rejecting more complex quotes during verification, only one verified quote of roughly 329 aEthAAVE remained available.
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 regardless, ultimately receiving tokens valued at around $36,000. Across all of these scenarios, a common architectural gap was evident: the complete absence of a trusted rule governing the resulting state, defined independently of the transaction builder and strictly enforced by the protocol during execution. In the Bybit scenario, a robust rule would have mandated that the approved Safe implementation remain unchanged. For BadgerDAO users, a rule would have restricted new token approvals solely to verified, published contracts. For the Aave swap, a rule would have established a hard minimum acceptable output, calculated independently of the interface quote, and enforced by the solver-based flow or settlement protocol. Currently, Ethereum lacks a general, native mechanism for onchain code to inspect the full set of net state changes and emitted events produced by a single transaction.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is necessary to examine the exact boundaries of what an Ethereum signature controls. When a user signs a transaction, they commit to specific parameters, including the target address, value, and 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 drifted significantly since the moment of signing. Consequently, the resulting net balance shifts, storage updates, and emitted events can diverge widely from expectations.
This vulnerability is exacerbated by proxy patterns. The target contract, or another contract it interacts with during execution, may rely on a proxy whose implementation contract changes just prior to execution, meaning the code that ultimately runs is entirely different from the code inspected by the user. Furthermore, transaction ordering within a block introduces profound unpredictability. Front-running and sandwich attacks can drastically alter a liquidity pool’s pricing parameters immediately before a user’s swap executes, all without altering a single byte of 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 has inherent structural limitations. Clear Signing initiatives attempt to translate raw calldata into human-readable descriptions so users understand what an action requests. However, Clear Signing relies entirely on accurate decoding and assumes the signer will successfully notice if the translated action deviates from their intent.
Simulation tools represent another widely used defense, predicting a transaction’s effects using a chosen snapshot of chain state prior to broadcast. Because chain state can shift rapidly before inclusion, and because malicious malware running locally on a signer’s machine can substitute a harmful payload at the exact moment of signing—as demonstrated in the Radiant Capital post-mortem—simulation alone is not a silver bullet. In the Radiant incident, wallet interfaces and simulations accurately showed the intended transaction, yet local malware successfully injected a malicious payload at signing time.
Contract checks and wallet guards also attempt to enforce rules during EVM execution. For instance, Uniswap automatically reverts a swap if the final output drops below a specified amountOutMinimum parameter. Similarly, Safe accounts utilize checkAfterExecution hooks to inspect account states after execution and revert transactions that violate governance rules. However, these mechanisms require developers to choose which specific state variables to check in advance. Reading another contract’s storage depends entirely on the specific view functions that contract chooses to expose. While a token’s balanceOf function makes balance validation straightforward, a proxy contract is not obligated to expose its implementation address via a standard function call, leaving guards blind to unauthorized implementation swaps. Crucially, these existing checks are fundamentally incapable of inspecting a transaction’s comprehensive net set of changes across the entire state tree.
How Native Transaction Assertions Work
Native transaction assertions propose a structural paradigm shift by empowering onchain code to inspect the complete set of net state changes after all transaction actions have fully executed. Utilizing read-only logic, an assertion compares starting and final values against a predefined rule. If the validation check fails, the entire transaction reverts.
Under this proposed model, the governing rule is packaged directly into the transaction and cryptographically signed alongside its primary actions. These rules can comprehensively cover net changes to native asset balances, storage slots, newly deployed contract code hashes, and emitted events. They can enforce strict parameters such as requiring a minimum payout, capping total spending, blocking unauthorized token approvals, preserving core account control logic, or restricting execution to a tightly specified set of state alterations.
Crucially, the origin of the rule is as vital as the verification mechanism itself. If a compromised frontend is permitted to write the assertion, it could easily craft a rule that explicitly permits the attack. Therefore, a secure, effective rule must originate from independently verified user intent, a standing account policy, or core protocol logic that a compromised component cannot unilaterally alter or bypass.
Three Design Choices and EIP-7906
Implementing native transaction assertions requires addressing complex protocol-level design choices regarding what information the EVM exposes, how assertion code accesses that data, and where the corresponding opcodes are permitted to run. Potential approaches involve exposing state changes, events, or a combination of both. Access mechanisms could range from enumerating entries to looking up specific values or copying the full set of changes directly into memory. Furthermore, protocol architects must decide whether the new opcodes should be restricted to specific transaction types or execution phases.
One prominent approach currently moving through the standards pipeline is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. While EIP-8141 introduces an ordered sequence of validation and action steps to frame transactions, EIP-7906 introduces a dedicated, read-only POST_TX frame executed at the very end of a transaction lifecycle specifically to check the transaction’s final outcome. While EIP-8141 has progressed toward inclusion in the upcoming Hegot upgrade, EIP-7906 has advanced to "Considered for Inclusion," though its formal confirmation remains under active review.
The EIP-7906 design exposes both state changes and events. Net state changes are reported as differences in native ETH balances and storage slots, alongside newly deployed contracts and their associated code hashes. To maintain efficiency, a storage slot written multiple times during a transaction is summarized as a single entry reflecting its starting and final values, and if a slot ultimately returns to its original value, it is omitted entirely.
To interact with this data, the proposal introduces three new EVM instructions. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies specific event data into memory. These opcodes are strictly restricted to the POST_TX frame, executing as static calls at the conclusion of the transaction to inspect outcomes without modifying state. If a rule violation occurs, the entire execution body reverts, but the transaction remains recorded onchain with a failed status, ensuring the gas payer is charged for consumed computational resources. This economic deterrent prevents malicious actors from spamming block builders with zero-cost, deliberately failing transactions.
Broader Applications and Future Design
Because EIP-7906 does not mandate that transactions include assertions by default, transaction builders could technically omit them. Consequently, user wallets must ensure that every frame transaction they construct incorporates the necessary assertion, derived either from internal simulations or standing user security policies. Similarly, protocols seeking to leverage this security layer must enforce that incoming calls originate from frame transactions containing the exact required assertions, rejecting standard transactions or improperly formulated frames.
Beyond basic user protection, native transaction assertions open up advanced possibilities for delegation and automated execution. When delegating authority to automated agents, users can enforce strict constraints not only on what contracts an agent may interact with and how much capital it can spend, but also on the precise economic outcome each transaction must achieve. In solver-based execution models, protocols can specify required outcomes while granting solvers the flexibility to determine optimal routing, though these guarantees remain bounded within single-transaction parameters on a single network.
As research continues under the Ethereum Foundation’s Trillion Dollar Security initiative, core contributors are actively engaging with wallet developers, protocol engineers, and security researchers to refine these designs. Teams and researchers interested in contributing to the development of native transaction assertions or exploring integration use cases are encouraged to participate in ongoing discussions through the EIP-7906 community channels and related security forums.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
