As part of the broader ongoing efforts within the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers are focusing intensely on mitigating two persistent user experience and security risks: blind signing and transaction uncertainty. To combat these challenges, the initiative is actively exploring the implementation of native transaction assertions. Alongside complementary initiatives such as Clear Signing, these assertions are designed to enforce a transaction’s final outcome strictly, ensuring that what a user intends to happen is mathematically and programmatically guaranteed to be what actually occurs on the blockchain.
The core motivation behind this research stems from a fundamental reality of how the Ethereum Virtual Machine (EVM) operates. Currently, Ethereum executes instructions precisely as they are authorized, without evaluating whether the resulting economic or state outcome matches the user’s actual desires. A digital signature commits a user to a specific request, but the ultimate execution outcome depends heavily on the prevailing network conditions, smart contract logic, and chain state encountered at the exact moment the transaction is processed. Over the history of the network, users have frequently suffered substantial financial losses due to two distinct categories of failure: intent mismatches and outcome mismatches.
Two Ways a Signed Transaction Can Go Wrong
The first major category of failure is an intent mismatch, a vulnerability famously exploited in high-profile incidents such as the Bybit security breach and the BadgerDAO attack. In both of these instances, compromised frontends or malicious interfaces supplied signing requests that radically differed from what the users believed they were approving. During the Bybit incident, unsuspecting signers authorized a transaction that effectively replaced their Safe’s core implementation contract with a malicious one. Similarly, BadgerDAO users inadvertently granted an attacker sweeping permissions to drain their tokens. In both scenarios, the user interface displayed one narrative while executing a vastly different reality.
The second category is an outcome mismatch, where a user signs an authentic, intended request, but external liquidity limits, unfavorable market slippage, or unpredictable chain states produce a final result that violently conflicts with their financial goals or standing safety policies. A prominent example of this occurred during a large-scale collateral swap involving Aave and CoW Swap. A user attempted to trade roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because the liquidity for AAVE was extraordinarily thin for a trade of that magnitude, and because CoW’s gas ceiling mechanisms rejected overly complex quotes during verification, only a single verified quote remained, yielding a mere 329 aEthAAVE.
Despite the interface flashing a severe 99.9 percent price impact warning and requiring explicit confirmation that the entire value could be lost, the user signed the transaction anyway, ultimately receiving tokens valued at a paltry $36,000. In all three of these historical cases—Bybit, BadgerDAO, and the massive Aave-CoW swap—the root vulnerability was identical: the lack of a trusted, immutable rule governing the resulting state that was defined independently of the transaction builder and strictly enforced during execution. Ethereum currently lacks a generalized, native mechanism for on-chain code to inspect the complete set of net state changes and emitted events produced by a single transaction before it finalizes.
What a Signature Does Not Control
When a user signs a transaction on Ethereum, their cryptographic commitment covers specific parameters, including the destination target, the native value attached, and the calldata. However, the EVM executes this call against whatever contract code and state happen to be present at the time the transaction is included in a block. Between the moment of signing and the moment of execution, that state can shift dramatically. Consequently, the resulting net balances, storage changes, and emitted events can diverge wildly from expectations.
The target contract, or any secondary contract it interacts with, may rely on proxy patterns where the underlying implementation contract is updated maliciously or unexpectedly before execution. Furthermore, transaction ordering introduces profound volatility. Front-running and sandwich attacks can manipulate decentralized exchange pool prices immediately before a user’s swap executes, altering financial outcomes without modifying a single byte of the signed transaction itself.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several vital defenses to combat these risks, but each possesses inherent limitations. One primary defense is Clear Signing, a standard designed to decode calldata into human-readable terms so users can clearly understand what an action requests. However, Clear Signing relies entirely on accurate decoding pipelines and assumes that the signer possesses the technical literacy to recognize when a decoded action deviates from their intent.
Another common defense is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. Because chain state is dynamic and can change before block inclusion, the transaction that gets signed can subtly or drastically differ from the one that was simulated. A stark illustration of this vulnerability occurred during the Radiant Capital exploit, where both the user wallet interface and the simulation engine displayed the correct, intended transaction, but local malware on the signers’ machines quietly substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also attempt to enforce rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-specified amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook, allowing a designated security guard to inspect account states after execution and revert the transaction if owner configurations or security policies are violated.
While effective within narrow parameters, these existing mechanisms require developers to anticipate and choose which specific state variables to check in advance. To read the storage of another contract, they are strictly dependent on the functions that the target contract chooses to expose. While a standard ERC-20 token’s balanceOf function makes checking token balances straightforward, a proxy contract is not obligated to expose its implementation address through a public function, leaving guards blind to underlying logic changes. Crucially, these traditional checks remain incapable of inspecting a transaction’s comprehensive net set of changes across the entire state tree.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions are being designed to empower on-chain code to inspect the full scope of net state changes occurring after a transaction’s core actions have executed. Utilizing read-only logic, an assertion evaluates starting and final values against a predefined rule. If the rule fails to hold true, the entire transaction reverts.
These rules are embedded directly into the transaction payload and are cryptographically signed alongside its primary actions. An assertion can govern net changes across native token balances, storage slots, newly deployed contract code hashes, and emitted events. It can establish rigid mathematical constraints, such as enforcing a strict minimum amount of tokens received, capping maximum spending limits, blocking unauthorized token approvals, preserving core account control logic, or permitting only an explicitly whitelisted set of state modifications.
However, researchers emphasize that the origin of the rule is just as critical as the verification logic itself. If a compromised frontend interface is allowed to write the assertion rule, it can easily write a rule that permits the malicious attack. Therefore, a genuinely useful assertion rule must derive from an independently verified expression of user intent, a standing institutional account policy, or underlying protocol logic that cannot be manipulated by vulnerable or compromised interface components.
Three Design Choices
The ongoing architectural research into native transaction assertions requires balancing three fundamental design choices. Developers and core protocol architects must decide precisely what information the EVM should expose, how assertion code should access that data, and where the new opcodes should be permitted to run.
Information exposure options range from detailed net state changes and comprehensive event logs to a combination of both. Access mechanisms under consideration include enumerating entries sequentially, looking up specific address and storage values directly, or copying the full set of state diff data into memory for advanced programmatic analysis. Finally, architects must determine whether the necessary opcodes should be restricted exclusively to specialized transaction types and execution phases, or made globally accessible throughout the EVM.
EIP-7906 as a Possible Solution
One prominent approach currently moving through the development pipeline is Ethereum Improvement Proposal 7906 (EIP-7906), which builds directly upon the frame transactions introduced in EIP-8141. Under this architecture, a frame transaction contains an ordered sequence of distinct validation and action steps. EIP-7906 proposes appending a read-only POST_TX frame at the very conclusion of the transaction lifecycle specifically designed to evaluate the final outcome. While EIP-8141 has been scheduled for the Hegotá network upgrade, EIP-7906 has advanced to "Considered for Inclusion" status, though its formal inclusion in the upgrade remains unconfirmed.
The EIP-7906 design exposes both state changes and emitted events natively. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed smart contracts and their associated code hashes. For instance, a storage slot that is written to multiple times during the execution of a transaction is reported as a single consolidated entry reflecting only its initial starting value and its final ending value. If a storage slot ultimately reverts to holding its original pre-transaction value, it is omitted from the trace entirely.
To interact with this data, the proposal introduces three specialized EVM 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 specific event payload data directly into memory.
Crucially, these opcodes are designed to function exclusively within a POST_TX frame executing as a static call at the end of the transaction. This ensures that the assertion logic can thoroughly inspect execution outcomes without introducing state mutation risks. If an assertion rule is violated, the execution body reverts entirely, but the transaction is still recorded in the block with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement is vital to prevent malicious actors from spamming block builders with deliberately failing transactions for free.
The Assertion Has to be Required
A key structural challenge with proposals like EIP-7906 is that they do not inherently mandate that every single transaction must include an assertion, leaving transaction builders technically capable of omitting them. To achieve robust security, wallets must be programmed to automatically ensure that every frame transaction they construct includes the necessary assertions, derived either from real-time local simulations or from enforced standing user policies.
Similarly, decentralized finance protocols looking to leverage this technology must implement protective functions that explicitly verify that incoming calls originate from frame transactions containing the exact, expected assertion rules. These protocols would need to actively reject ordinary transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, widespread adoption requires ecosystem-wide compatibility across client software, wallets, and smart contract integrations, noting that already deployed immutable contracts would be unable to retroactively enforce these checks without upgrade mechanisms.
Where Transaction Assertions Could Help
Beyond serving as a powerful defense against phishing, malware, and unexpected slippage, native transaction assertions open up advanced use cases across the Ethereum ecosystem. For instance, they can significantly strengthen account delegation frameworks. When delegating operational authority to automated agents, users can already limit which contracts an agent may interact with, set maximum spending allowances, and define expiration timeframes. Transaction assertions would add a crucial layer of outcome-based governance, enabling users to constrain not just what an agent is permitted to do, but precisely what financial and state results those actions are allowed to generate.
Protocols can also leverage assertions to enforce standardized safety checks uniformly across all callers utilizing frame transactions. In solver-based execution architectures, a protocol could specify the required output state while allowing solvers complete flexibility in determining the optimal routing path to achieve it.
Researchers note, however, that these transaction-level guarantees remain strictly bounded to a single transaction on a single network, meaning they cannot inherently span cross-chain operations. Beyond trading, assertions can be utilized to verify that complex multi-step workflows successfully reach intended final states, ensuring that unspent funds are reliably returned to users and redundant token approvals are cleanly revoked before finality.
Help Shape the Design
As research and engineering around native transaction assertions continue under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, core contributors are actively seeking feedback and collaboration from wallet developers, security researchers, and protocol architects. Teams interested in exploring practical use cases and contributing to the research can reach out to the initiative via email or participate directly in ongoing community discussions, such as the EIP-7906 thread on Ethereum Magicians. Further updates regarding security risk controls and priority development work are regularly published through the initiative’s official coordination portals.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
