The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as critical user experience risks facing the ecosystem. As part of an ongoing effort to secure user assets alongside existing safety measures like Clear Signing, researchers are exploring native transaction assertions as a fundamental next step to enforce a transaction’s final outcome.
This development addresses a foundational challenge in blockchain architecture: why a valid cryptographic signature does not always guarantee the transaction result a user actually intended. By evaluating native transaction mechanisms—with EIP-7906 (Transaction Assertions via State Diff Opcode) serving as a prominent framework—the initiative aims to protect users where current defenses fall short.
Two Ways a Signed Transaction Can Go Wrong
The vulnerability stems from how the Ethereum Virtual Machine (EVM) fundamentally operates. The network executes transactions precisely as authorized, without judging whether the net result aligns with the user’s subjective intent. A cryptographic signature commits to a specific request, but its outcome depends entirely on the code and state encountered during execution. Over the history of the network, users have lost substantial sums either because they approved a request different from what they believed they were signing, or because an intended request produced an unintended economic outcome.
The first major failure mode is an intent mismatch, a phenomenon vividly illustrated by historical exploits such as the Bybit incident and the BadgerDAO attack. In both instances, compromised frontends supplied signing requests that differed fundamentally from what users thought they were approving. Bybit signers authorized the replacement of a Safe multi-sig implementation contract, while BadgerDAO users inadvertently granted an attacker sweeping permission to spend their underlying tokens.
The second major failure mode is an outcome mismatch. In these scenarios, the signer approves the exact request presented to them, but the execution limits or the prevailing chain state permit a final result that sharply conflicts with their economic goals or personal safety policies. A prominent example occurred during an Aave and CoW collateral swap, where a user attempted to swap roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was far too thin to support a trade of that magnitude, and CoW’s gas ceiling rejected more complex quotes during verification, only a single verified quote of roughly 329 aEthAAVE remained. Although the user interface displayed a 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 approximately $36,000.
In all three scenarios, the transactions suffered from a shared systemic flaw: the absence of a trusted rule governing the resulting state, defined independently of the transaction builder and enforced natively during execution. For Bybit, an effective rule would have mandated that the approved Safe implementation contract remain entirely unchanged. For a BadgerDAO user, a protective rule would have restricted new token approvals exclusively to published, audited Badger contracts. For the Aave user, a hardcoded rule would have established a minimum acceptable output calculated independently of the interface’s displayed quotes. Currently, however, Ethereum lacks a generalized mechanism for onchain code to inspect the full set of net state changes and emitted events produced by a transaction.
What a Signature Does Not Control
When an Ethereum user signs a transaction, their cryptographic signature commits to specific parameters: the target address, the transferred value, and the calldata. However, the EVM executes this call against whatever contract code and chain state happen to be present at the exact moment the transaction is included in a block. Because blockchain environments are dynamic, this state may have shifted significantly since the moment of signing. Consequently, the resulting net balance shifts, storage modifications, and emitted events can diverge widely from user expectations.
This structural vulnerability leaves room for external manipulation. The target contract—or another contract it calls—may utilize a proxy whose underlying implementation address changes before execution, causing the running code to differ entirely from what the user inspected. Furthermore, transaction ordering can alter the local state encountered by a call. For instance, a classic sandwich attack can manipulate a decentralized exchange pool’s price immediately before a swap executes, altering the financial outcome without modifying the user’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several important defenses to mitigate these risks, but each possesses inherent limitations. One primary defense is Clear Signing, which translates raw calldata into human-readable actions for the user. While helpful, Clear Signing relies entirely on accurate decoding and assumes the signer can successfully recognize when a displayed action deviates from their original intent.
Another common defense is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. Because chain states change rapidly before block inclusion, the actual state at execution can differ from the simulation. Moreover, the transaction signed by the user may differ from the one simulated, as demonstrated in the Radiant Capital post-mortem, where wallet interfaces and simulations displayed intended transactions while local malware substituted malicious payloads at the final moment of signing.
Contract-level checks and wallet guards also enforce rules during EVM execution. For example, Uniswap automatically reverts a swap if its final output falls below a pre-configured amountOutMinimum parameter. Similarly, Safe’s checkAfterExecution hook enables a security guard to inspect an account’s state post-execution and revert transactions that violate predefined governance rules.
However, these existing validation approaches require developers to choose which specific state variables to check in advance. To read another contract’s storage, they remain entirely dependent on the functions explicitly exposed by that contract. While checking a token’s balanceOf function is straightforward, a custom proxy contract is not required to expose its implementation address via a public function, leaving guards unable to read the implementation slot directly. Crucially, none of these current checks can inspect a transaction’s full set of net state changes across the board, meaning unintended side effects outside the scope of a specific guard frequently go unnoticed.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions would empower onchain code to inspect the comprehensive set of net state changes occurring after a transaction’s primary actions have finished running. Utilizing read-only logic, an assertion compares starting state values against final state values according to a predefined programmatic rule. If the rule is violated, the entire transaction reverts.
Crucially, this rule is embedded directly within the transaction payload and signed alongside its execution actions. It can encompass net changes across native ETH balances, contract storage, and deployed code, as well as newly deployed contracts and emitted events. This allows users to enforce strict boundaries, such as requiring a minimum token payout, capping maximum spending, blocking unauthorized new token approvals, preserving account control logic, or permitting only a precisely specified set of state modifications.
The security of this model, however, relies heavily on the provenance of the rule itself. If a compromised frontend is allowed to author the assertion, it can easily write a rule that permits the malicious activity it intends to commit. Therefore, a genuinely useful assertion rule must originate from an independently verified user intent, a standing account-level security policy, or core protocol logic that a compromised interface component cannot alter or bypass.
Three Key Design Choices
Designing native transaction assertions at the protocol level requires core developers to resolve three fundamental architectural questions: what information the EVM exposes, how assertion code accesses that information, and where the associated opcodes are permitted to run.
Regarding exposed information, developers are weighing whether to include net state changes, event logs, or both. For data access, potential methods range from enumerating individual entries and looking up specific values to copying entire sets of state changes directly into memory. Finally, regarding execution scope, designers must decide whether the new opcodes should be strictly restricted to specific transaction types and execution phases, or made available universally across the EVM.
EIP-7906 as a Possible Solution
One prominent approach actively moving through the community pipeline is EIP-7906, which builds directly upon the frame transactions introduced in EIP-8141. While EIP-8141 establishes an ordered sequence of validation and action steps within a frame transaction, EIP-7906 introduces a specialized, read-only POST_TX frame appended to the very end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has advanced toward inclusion in the Hegot upgrade, EIP-7906 has reached the status of "Considered for Inclusion," though its confirmation remains pending.
The EIP-7906 framework exposes both state changes and events. State modifications are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their respective code hashes. For instance, a storage slot that is written to multiple times during a transaction is consolidated into a single net entry reflecting only its starting and final values; if a slot concludes execution holding its original value, it is omitted entirely.
To interact with this data, the proposal introduces three new EVM instructions, or opcodes. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for specific target addresses and storage slots, and EVENTDATACOPY copies specific event data payloads into memory.
These instructions are intentionally restricted to operate exclusively within the POST_TX frame, executing at the tail end of the transaction as a static call. This design ensures that the assertion can inspect the final outcome without accidentally mutating state. If an assertion rule fails, the entire execution body reverts, but the transaction remains permanently recorded on the blockchain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement prevents malicious actors from spamming network builders with deliberately failing transactions for free.
The Necessity of Mandating Assertions
A critical consideration in the EIP-7906 framework is that transactions are not inherently required to include an assertion, meaning transaction builders retain the technical capability to omit them.
To protect individual users, wallet software must take responsibility for ensuring that every frame transaction it constructs incorporates the necessary assertion. These rules can be derived automatically from pre-execution wallet simulations or enforced via standing account security policies.
For smart contract protocols, protected functions must be coded to verify that incoming calls originate from frame transactions containing the exact required assertion, automatically rejecting ordinary transactions as well as frame transactions with missing or incorrect assertions. Consequently, callers and protocol integrations would be required to adopt compatible frame transactions, meaning already-deployed, immutable contracts could not retroactively add this verification check.
Where Transaction Assertions Could Help
Beyond fortifying basic user security and protocol resilience, native transaction assertions open up new design space for advanced blockchain interactions. For example, they could significantly strengthen automated delegation. When delegating authority to an AI agent or automated script, users could place hard constraints not only on which contracts the agent may access and how much it is allowed to spend, but also on the precise financial outcomes permitted for each transaction.
Protocols could similarly leverage native assertions to define standardized safety checks for every caller utilizing a frame transaction. In solver-based execution architectures, a protocol could specify the required final outcome while granting independent solvers complete flexibility over the routing path. While this guarantee remains confined to a single transaction on a single network—and thus cannot cover cross-chain pathways—assertions could reliably verify that complex workflows reach their intended final states, ensuring unspent assets are returned and unused token approvals are revoked.
Help Shape the Design
Solutions for native transaction assertions continue to evolve under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback from wallet developers, protocol engineers, and security teams who would ultimately rely on these primitives.
Interested contributors can reach out via email to explore specific use cases and participate in ongoing research, or join the active EIP-7906 discussion thread on Ethereum Magicians. Additional information regarding risk controls and core infrastructure priorities is available through the Trillion Dollar Security initiative portal.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
