As part of the broader ongoing efforts within the 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 facing the decentralized finance ecosystem. To address these vulnerabilities, the foundation is actively exploring the implementation of native transaction assertions as a fundamental next step to enforce a transaction’s final outcome reliably. This mechanism is being evaluated alongside other security measures, such as Clear Signing, to provide a multi-layered defense system for end users and protocols alike.
The core investigation centers on a fundamental challenge in how Ethereum operates: the network executes instructions precisely as they are authorized, without evaluating whether the ultimate economic or state result aligns with the user’s actual intent. A standard cryptographic signature serves as an explicit commitment to a request, but the ultimate outcome is heavily dependent on the surrounding smart contract code and the exact blockchain state encountered during execution. Over the history of the network, users have suffered substantial financial losses either because they inadvertently approved malicious actions entirely distinct from their beliefs, or because a legitimate request produced an unintended, adverse outcome due to rapidly changing market conditions or frontrunning.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize these transaction failures into two distinct phenomena: intent mismatches and outcome mismatches. The first category involves deceptive practices or compromised infrastructure, famously illustrated by high-profile incidents such as the Bybit security event and the historic BadgerDAO attack. In both instances, compromised front-end user interfaces supplied signing requests that radically differed from what the users believed they were authorizing. During the Bybit compromise, signers unknowingly authorized the replacement of their Safe multi-signature wallet’s core implementation contract, while BadgerDAO users inadvertently granted malicious actors broad permissions to spend their native tokens.
The second category, an outcome mismatch, occurs when a user successfully signs the exact transaction presented by an interface, but underlying limits, high slippage, or shifting state variables produce an economic result that directly conflicts with their goals or standing risk policies. A notable example of this dynamic occurred during a collateral swap involving Aave and CoW. A user attempted to trade approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because market liquidity for AAVE was exceptionally thin for a trade of that unprecedented magnitude—and because CoW’s strict gas ceiling protocols rejected more complex quotes during the verification phase—only a single verified quote returning roughly 329 aEthAAVE remained viable. Despite the user interface displaying a staggering 99.9 percent price impact warning and requiring explicit manual confirmation of potential total loss, the transaction was signed and executed, resulting in an output worth only about $36,000.
In each of these scenarios, the underlying common denominator was the complete absence of a trusted, immutable rule governing the resulting state. These rules need to be defined completely independently of the transaction builder and strictly enforced at the EVM execution level. For instance, a proper rule during the Bybit event would have mandated that the approved Safe implementation contract remain entirely immutable. Similarly, a Badger user could have enforced a policy restricting new token approvals exclusively to officially published and verified Badger contracts. In the Aave instance, an independent rule would have enforced a strict minimum acceptable output calculation, independent of the quotes supplied by the primary interface, requiring both the signed order and the settlement protocol to honor the assertion. Currently, Ethereum lacks a generalized native mechanism enabling on-chain code to comprehensively inspect the full set of net state changes and emitted events produced by a single transaction.
What a Signature Does Not Control
A standard Ethereum signature commits strictly to the explicit parameters of a requested action, encompassing the target contract address, the attached value, and the raw calldata. However, the Ethereum Virtual Machine executes this call against the specific contract code and state existing at the exact moment the transaction is included in a block, which frequently differs from the state observed when the user originally signed. Consequently, the resulting net balance alterations, storage modifications, and emitted events can diverge wildly from expectations.
The target contract itself, or any auxiliary contracts it calls during execution, may rely on proxy patterns where the underlying implementation contract changes prior to execution. This means the code that ultimately runs can be entirely different from the code inspected by the user during the signing process. Furthermore, transaction ordering within a block introduces significant volatility. A classic sandwich attack, for instance, can manipulate a decentralized exchange liquidity pool’s price immediately before a user’s swap executes, altering the economic reality of the trade without modifying a single byte of the user’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several valuable defensive mechanisms to mitigate these risks, though each possesses inherent limitations. Clear Signing initiatives represent a major step forward, designed to translate raw calldata into human-readable descriptions of requested actions. However, Clear Signing fundamentally relies on accurate off-chain decoding and assumes the signer possesses the attentiveness to recognize when the decoded action deviates from their intent.
Transaction simulation is another prominent defense, predicting the likely effects of a transaction against a selected snapshot of the chain state. Despite its utility, the underlying chain state can shift before final inclusion, and malicious actors can occasionally substitute a harmful payload at the exact moment of signing, bypassing the simulation entirely. This vulnerability was underscored in the Radiant Capital post-mortem, where both wallet interfaces and simulation tools displayed the intended transaction accurately, while local malware on the victim’s machine substituted a malicious payload during the final signing phase.
At the execution level, individual smart contract checks and wallet guards enforce specific rules during EVM processing. Decentralized exchanges like Uniswap automatically revert swaps if the final output drops beneath a predefined amountOutMinimum parameter. Advanced wallet architecture like Safe utilizes execution hooks—such as checkAfterExecution—to inspect account states post-execution and revert transactions violating predefined security configurations. Nevertheless, these existing approaches require developers to anticipate and select which specific state variables to check in advance. To read external storage from another contract, they are entirely constrained by the specific functions that contract chooses to expose. While checking a token’s balance via balanceOf is relatively straightforward, a custom proxy contract is not required to expose its implementation address via an accessible public function, leaving guards blind to underlying changes. Crucially, none of these current checks possess the capability to inspect the transaction’s complete set of net state changes across the board.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions are being designed to empower on-chain code with the ability to inspect the complete set of net state changes occurring after a transaction’s primary actions have successfully executed. Operating via read-only logic, an assertion compares initial starting values and final ending values against a predefined set of rules. If the specified rule is violated, the transaction’s actions automatically revert.
The rule itself is embedded directly within the transaction payload and signed securely alongside the primary actions. These assertions can govern net changes across native ETH balances, storage slots, and code execution, as well as monitor newly deployed contracts and emitted events. Developers and users could mandate minimum token receipts, cap maximum spending, block unauthorized token approvals, preserve an account’s core control logic, or restrict execution exclusively to a specified set of state modifications.
However, security researchers emphasize that the origin of the assertion rule is just as vital as the verification check itself. If a compromised front-end interface were allowed to write the assertion rule unchecked, it could easily craft a rule that explicitly permits the attack. Therefore, a genuinely useful assertion rule must originate from an independently verified user intent, a strict standing account policy, or core protocol logic that a compromised interface component cannot manipulate.
Three Design Choices and EIP-7906
Designing native transaction assertions requires navigating complex protocol-level decisions regarding what exact information the EVM should expose, how assertion code accesses that data, and where the corresponding opcodes are permitted to execute. Considerations include whether to expose state changes, event logs, or both; whether access should be granted via entry enumeration, specific value lookups, or full-memory copying of state diffs; and whether new opcodes should be restricted to specific transaction types or execution phases.
One of the most prominent proposals addressing these challenges is EIP-7906, which builds directly upon the frame transactions introduced in EIP-8141. While EIP-8141 structures transactions into an ordered sequence of validation and action steps, EIP-7906 introduces a specialized, read-only POST_TX frame executed at the very end of the transaction lifecycle solely to evaluate the final outcome.
EIP-7906 proposes exposing both net state changes and event data. State modifications are reported as net differences in native ETH balances and storage, alongside newly deployed contracts and their corresponding code hashes. To optimize efficiency, a storage slot written multiple times during execution is reported as a single entry reflecting only its initial starting value and its final ending value. If a storage slot ultimately reverts to its original value by the end of the transaction, it is omitted entirely.
Three dedicated new EVM instructions, or opcodes, are planned to facilitate this inspection process. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves specific starting and final values for designated addresses and storage slots, and EVENTDATACOPY copies event data directly into memory. Crucially, these opcodes are designed to function exclusively within the POST_TX frame, operating as a static call that reviews outcomes without altering state. If an assertion rule fails, the entire execution body reverts. The transaction nonetheless remains recorded on-chain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement prevents malicious actors from exploiting the network by forcing block builders to process deliberately failing transactions for free.
Implementation and Future Applications
Because EIP-7906 does not mandate transactions to universally include an assertion, transaction builders retain the technical ability to omit them. Consequently, user-facing wallets must assume the responsibility of ensuring that every frame transaction they construct incorporates the necessary assertions, drawing rules either from pre-execution simulations or enforceable standing user policies. Similarly, decentralized protocols aiming to leverage this technology must update their protected functions to verify that incoming calls originate from frame transactions bearing the precise required assertion, thereby rejecting legacy transactions or improperly constructed payloads.
Beyond immediate security enhancements, native transaction assertions open up expansive possibilities across the broader blockchain ecosystem. They could substantially strengthen account delegation frameworks, allowing users to grant granular permissions to automated agents while strictly constraining not only the types of contracts the agent may interact with, but also the exact economic outcomes those actions are permitted to produce. Furthermore, decentralized protocols could establish standardized safety assertions for all incoming interactions, offering robust guarantees within single-chain transaction environments.
Solutions and architectural specifications for native transaction assertions remain active areas of research within the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers and core contributors are actively seeking feedback from wallet developers, infrastructure providers, and protocol engineers. Interested teams and contributors can engage directly with the research initiative or join ongoing community discussions surrounding the implementation framework to help shape the future of Ethereum transaction security.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
