As part of the ongoing Ethereum Foundation Trillion Dollar Security initiative, core researchers and developers have identified blind signing and transaction uncertainty as critical user experience and security risks facing the ecosystem. To address these vulnerabilities, the initiative is actively exploring native transaction assertions as a fundamental next step to enforce a transaction’s final outcome. Working alongside complementary solutions like Clear Signing, these assertions aim to protect users at the protocol level where traditional, surface-level defenses ultimately reach their limits.
The core problem stems from how the Ethereum Virtual Machine operates at its foundational level. The EVM executes transactions precisely as authorized, without exercising independent judgment regarding whether the ultimate result aligns with the user’s actual intentions. While a digital signature securely commits a user to a specific request, the execution outcome depends heavily on the prevailing contract code and network state encountered at the exact moment the transaction is processed on-chain. Over the history of the network, users have suffered substantial financial losses either because they inadvertently approved an action differing from their beliefs, or because an intended request yielded an economic result they never desired.
These failures generally manifest in two distinct ways: intent mismatches and outcome mismatches. Intent mismatches occur when users are deceived about the nature of the transaction they are authorizing, a vulnerability starkly highlighted by historical events such as the Bybit security incident and the BadgerDAO attack. In both instances, compromised front-end interfaces provided signing requests that drastically differed from what the victims believed they were endorsing. During the Bybit breach, signers authorized the replacement of a Safe multi-signature wallet’s implementation contract, whereas BadgerDAO users unknowingly granted malicious actors sweeping permissions to drain their token balances.
Conversely, outcome mismatches represent a different failure mode wherein the signer authorizes the exact request presented to them, but fluctuating liquidity limits or dynamic state conditions yield an unacceptable economic outcome that violates standing safety policies or expectations. A prominent example occurred during a collateral swap involving Aave and CoW, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was vastly insufficient for a trade of that magnitude, and because CoW’s gas ceiling mechanism rejected more complex quotes during verification, only a single verified quote of roughly 329 aEthAAVE remained. Although the interface displayed a stark 99.9 percent price impact warning and required explicit confirmation that the entire value could be lost, the user signed the transaction regardless, ultimately receiving tokens valued at a mere $36,000.
In each of these high-profile scenarios, the fundamental missing element was a trusted rule governing the resulting state—one defined completely independently of the transaction builder and rigidly enforced during execution. An ideal rule in the Bybit case would have mandated that the approved Safe implementation contract remain entirely unaltered. For a BadgerDAO user, a protective rule would have restricted new token spending approvals strictly to verified, published contracts. For the Aave user, a robust rule would have enforced a strict minimum acceptable output calculated independently of the quotes generated by the front-end interface. Currently, however, Ethereum lacks a generalized native mechanism allowing 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 an Ethereum transaction, their cryptographic signature commits strictly to the requested action, including the target address, value transferred, and raw calldata. However, the EVM executes this call against the specific contract code and blockchain state present at the exact time 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 expectations.
This structural gap leaves transactions vulnerable to dynamic manipulation. The target contract—or another contract it invokes during execution—might utilize an upgradeable proxy whose implementation changes unexpectedly prior to inclusion, meaning the executed code differs entirely from what was initially inspected. Furthermore, transaction ordering within a block introduces severe unpredictability. Front-running and sandwich attacks, for instance, can manipulate decentralized exchange pool prices immediately before a user’s swap executes without altering a single byte of the signed transaction itself.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several vital defenses to mitigate these risks, yet each possesses inherent limitations. One primary defense is Clear Signing, an initiative designed to present human-readable summaries of what calldata requests. While helpful, Clear Signing relies entirely on accurate payload decoding and depends on the human signer correctly recognizing when a displayed action deviates from their mental model.
Another widespread defense is transaction simulation, which predicts the downstream effects of a transaction using a snapshot of the current chain state. Because chain state is fluid and can shift before a transaction is included in a block, the state evaluated during simulation may not match the state encountered upon execution. Moreover, simulation fails if the signed payload itself is altered at the moment of signing. This vulnerability was demonstrated during the Radiant Capital exploit, where both the wallet interface and the simulation engine displayed the intended, safe transaction, while local malware on the victim’s machine substituted a malicious payload at the critical signing phase.
Contract-level checks and wallet security guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-determined amountOutMinimum threshold. Similarly, Safe accounts utilize execution hooks such as checkAfterExecution to inspect an account’s state variables post-execution and revert transactions that violate predefined governance rules.
Despite their utility, these existing protective measures require developers to choose which specific state variables to check in advance. To read another contract’s internal storage, they depend entirely on the specific view functions that contract exposes. While a standard ERC-20 token’s balance function makes balance tracking straightforward, a proxy contract is not required to expose its implementation address via a public function. Without a direct interface, a security guard cannot read the implementation slot directly. Crucially, these existing checks remain fundamentally incapable of inspecting a transaction’s full, comprehensive set of net state changes, meaning unintended side-effects and malicious alterations outside the scope of programmed guards can easily go unnoticed.
How Native Transaction Assertions Work
To bridge these security gaps, native transaction assertions would empower on-chain code to inspect the complete set of net state changes occurring after a transaction’s primary actions have fully executed. Utilizing read-only logic, an assertion evaluates starting and final values against a predefined rule. If the evaluation fails, the entire transaction reverts.
Crucially, the assertion rule is embedded directly within the transaction payload and signed alongside its primary actions. These rules can encompass net changes across native asset balances, storage slots, newly deployed contract code hashes, and emitted event logs. They can enforce strict parameters such as establishing minimum received amounts, capping spending limits, blocking unauthorized token approvals, preserving an account’s core control logic, or permitting only a strictly whitelisted set of state modifications.
However, the provenance of the assertion rule is just as critical as the technical check itself. If a compromised front-end interface is permitted to write its own assertion, it could easily include a rule that explicitly authorizes the exploit. Therefore, a truly effective rule must originate from an independently verified user intent, a standing institutional account policy, or rigid protocol-level logic that a compromised component cannot manipulate.
Three Design Choices and EIP-7906
Implementing native transaction assertions requires navigating complex design choices regarding what specific information the EVM exposes, how assertion logic accesses that data, and where the corresponding opcodes are permitted to execute. Architectural decisions must determine whether to expose net state changes, event logs, or both. Access mechanisms could range from enumerating entries to looking up precise values or copying entire sets of changes into memory. Additionally, developers must decide whether new opcodes should be restricted to specialized transaction types and execution phases or made broadly available across the EVM.
A leading approach currently under active consideration is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. While a standard frame transaction organizes execution into an ordered sequence of validation and action steps, EIP-7906 introduces a specialized, read-only POST_TX frame positioned at the very end of the transaction lifecycle specifically to evaluate the final outcome. Current development schedules place EIP-8141 under consideration for the Hegot network upgrade, while EIP-7906 has advanced to the status of being "Considered for Inclusion," though its ultimate inclusion remains unconfirmed.
Under the framework of EIP-7906, the execution environment exposes both net state modifications and event logs. 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 undergoes multiple writes during internal execution is reported as a single consolidated entry reflecting only its initial starting value and its ultimate final value. If a storage slot ultimately reverts to its original value by the end of execution, it is omitted entirely from the trace.
To interact with this data, EIP-7906 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 event data directly into memory for programmatic inspection.
Operationally, these opcodes function exclusively within the POST_TX frame, executing as a static call at the conclusion of the transaction. This ensures that the assertion can inspect the final outcome without altering the blockchain state. If the assertion rule fails, the entire execution body reverts, but the transaction record is retained on-chain with a failed status, and the designated gas payer is charged for the computational resources consumed. This economic enforcement mechanism prevents malicious actors from exploiting the network by forcing block builders to process deliberately failing transactions for free.
The Assertion Has to Be Required
A key architectural hurdle with EIP-7906 is that it does not inherently mandate the inclusion of an assertion in every transaction, leaving transaction builders technically capable of omitting them entirely. Consequently, wallet software must take responsibility for ensuring that any frame transaction it constructs incorporates the necessary assertion, derived either from a pre-execution simulation or a standing security policy enforced across all user activities.
For decentralized protocols seeking to protect their users, protected functions must be coded to verify that incoming calls originate from frame transactions containing the exact required assertion. These contracts must explicitly reject standard transactions as well as frame transactions that feature missing or incorrect assertions. As a result, integrations and callers would need to adopt compatible frame transactions, and already deployed, immutable smart contracts would lack the ability to retrofit this verification check independently.
Where Transaction Assertions Could Help
Beyond serving as a bulwark against front-end compromises and unexpected slippage, native transaction assertions unlock powerful new capabilities across the Ethereum ecosystem. For example, they could dramatically strengthen account delegation and automated agent workflows. When delegating authority to an autonomous agent, users could constrain not only which protocols the agent interacts with and how much capital it spends, but also enforce strict rules regarding the exact economic outcome of each transaction.
Protocols could likewise define standardized safety rules, requiring identical verification checks for every caller utilizing a compatible frame transaction. In solver-based execution architectures, a protocol could specify the exact required outcome while granting solvers the freedom to determine the most efficient execution route. While these guarantees apply strictly within the boundaries of a single transaction on a single network—and thus cannot cover cross-chain pathways—assertions can verify that complex workflows reach their intended final state, ensuring any residual tokens are properly returned to the user and superfluous token approvals are automatically revoked.
Help Shape the Design
Research and development surrounding native transaction assertions remain ongoing within the scope of the Ethereum Foundation Trillion Dollar Security initiative. Core contributors are actively seeking feedback and collaboration from wallet developers, protocol engineers, and security researchers. Stakeholders interested in exploring potential use cases and contributing to the technical research are encouraged to reach out via email or participate directly in the ongoing community discussions on the Ethereum Magicians forum.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
