The Ethereum Foundation’s Trillion Dollar Security initiative has flagged blind signing and transaction uncertainty as critical user experience and safety risks across the ecosystem. As part of its ongoing mission to secure the network for mainstream and high-value adoption, the initiative is actively exploring native transaction assertions as a fundamental next step. Working alongside other modern defense mechanisms like Clear Signing, these assertions are designed to enforce a transaction’s final outcome directly at the protocol level, offering a robust safety net where traditional client-side defenses ultimately reach their limits.
This development addresses a foundational vulnerability in how blockchain transactions operate: the fact that a valid cryptographic signature does not inherently guarantee that the transaction will yield the user’s desired economic or operational result. By examining potential architectures such as EIP-7906, which introduces transaction assertions via a state diff opcode, researchers and core developers are seeking ways to protect users against unexpected execution outcomes without sacrificing the flexibility of the Ethereum Virtual Machine (EVM).
Two Ways a Signed Transaction Can Go Wrong
The core security challenge stems from the deterministic execution model of Ethereum. The EVM executes instructions precisely as authorized, without evaluating whether the net result aligns with what the user intended when they signed. A user’s signature represents a commitment to a specific request, but the final outcome depends heavily on the prevailing smart contract code and blockchain state at the exact moment the transaction is included in a block. Throughout the history of the network, users and protocols have suffered significant financial losses due to failures that generally manifest in one of two distinct ways: intent mismatches and outcome mismatches.
The first category, an intent mismatch, occurs when the signing request presented to the user differs significantly from what actually gets executed. High-profile security breaches, such as the Bybit incident and the BadgerDAO attack, illustrate this vulnerability vividly. In both historical events, compromised frontends or malicious vectors supplied signing requests that deviated entirely from what the victims believed they were approving. During the Bybit security incident, signers authorized an operation that replaced a Safe multi-signature wallet’s implementation contract, whereas BadgerDAO users inadvertently granted attackers broad permissions to drain their token balances.
The second category is an outcome mismatch. In these scenarios, the signer approves the exact request they were shown, but external variables, insufficient liquidity, or shifting onchain states allow an execution result that directly conflicts with their economic goals or standing security policies. A prominent example of this dynamic occurred during an Aave and CoW collateral swap. A user attempted to execute a massive trade, swapping approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, available AAVE liquidity was far too thin to support a trade of that magnitude cleanly. CoW’s built-in gas ceiling rejected more complex multi-hop quotes during the verification phase, leaving a single verified quote of roughly 329 aEthAAVE.
Although the wallet interface displayed a dramatic 99.9 percent price impact warning and required explicit confirmation that the entire value could be lost, the user proceeded to sign the transaction, ultimately receiving tokens valued at around $36,000. Incidents of this scale highlight a glaring structural gap across these cases: all of them lacked a trusted, independent rule governing the resulting state that was defined separately from the transaction builder and strictly enforced during EVM execution. In the Bybit scenario, a protective rule would have mandated that the approved Safe implementation contract remain completely immutable. For BadgerDAO users, a rule would have restricted new token approvals solely to verified, published contracts. For the Aave trade, a rule would have established a hard minimum acceptable output, calculated independently of the interface quote provided by the application layer. Currently, however, Ethereum lacks a generalized mechanism enabling onchain code to inspect the comprehensive set of net state changes and emitted events generated by a transaction.
What a Signature Does Not Control
When a user signs an Ethereum transaction, their cryptographic signature commits strictly to the requested action parameters, including the target contract address, native value transfer, and raw calldata. It does not, however, lock down the execution environment itself. The EVM executes the call against whatever contract code and blockchain state happen to exist at the moment of inclusion, which may have shifted dramatically since the moment of signing. Consequently, the resulting net balance shifts, storage modifications, and emitted events can deviate widely from initial expectations.
The target contract specified in a transaction, or any downstream contract it interacts with, may rely on proxy patterns where the underlying implementation contract changes prior to execution. As a result, the active code running onchain can differ entirely from what the user inspected during the signing preview. Furthermore, transaction ordering within a block introduces severe vulnerabilities. A classic sandwich attack, for instance, can manipulate an automated market maker pool’s price right before a user’s swap executes, altering the economic reality of the transaction without modifying the underlying signed calldata itself.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several vital defense mechanisms to mitigate these risks, but each possesses inherent limitations. One primary defense is Clear Signing, an initiative designed to humanize calldata so users can clearly read what an application is requesting. However, Clear Signing ultimately depends on accurate transaction decoding and on the user’s ability to recognize when a presented action diverges from their true intent.
Another prevalent defense is transaction simulation, which predicts the effects of a transaction against a selected snapshot of chain state. Because chain state is fluid and can change before a transaction is officially included in a block, a simulated outcome is never guaranteed. Moreover, if a user’s local machine or wallet interface is compromised by malware, the transaction payload signed at the final moment can be swapped entirely for a malicious one, bypassing simulation checks altogether. Incidents such as the Radiant Capital exploit demonstrated that both the wallet interface and standard simulation tools displayed the intended, safe transaction, while malware on the signer’s hardware substituted a malicious payload at the point of signature.
Contract-level checks and wallet guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final token output falls below a pre-set amountOutMinimum parameter. Similarly, Safe accounts feature a checkAfterExecution hook that allows a designated guard to inspect the account’s state variables post-execution, reverting the transaction if it violates pre-configured ownership or operational rules.
Despite their utility, these approaches require developers to choose which specific state variables to check in advance. To read the storage slot of another contract, they are entirely dependent on the functions that the target contract chooses to expose publicly. While a standard ERC-20 token contract exposes a balanceOf function making balance validations straightforward, a proxy contract is not obligated to expose its implementation address via a standard read function. Without such an explicit interface, a traditional security guard cannot read the underlying implementation storage slot directly. Crucially, these existing checks cannot inspect the transaction’s complete set of net state changes, meaning unforeseen side effects often go entirely unnoticed.
How Native Transaction Assertions Work
Native transaction assertions propose a foundational shift by allowing onchain code to inspect the full set of net state changes after a transaction’s primary actions have finished executing. Utilizing specialized read-only logic, an assertion evaluates starting states against final outcomes according to a predefined rule. If the execution fails to satisfy the rule, the transaction’s actions automatically revert.
The rule itself is bundled directly into the transaction data and cryptographically signed alongside the primary actions. It can encompass net modifications to native asset balances, storage slots, newly deployed contract code hashes, and emitted event logs. By establishing these boundaries, a user or protocol can require a strict minimum received amount, cap token spending, block unauthorized approvals, preserve an account’s foundational control logic, or restrict execution to an explicitly approved set of state modifications.
However, the provenance of the rule is just as critical as the validation mechanism itself. If a frontend interface is compromised, an attacker could theoretically write an assertion that accommodates their malicious objectives. Therefore, a truly secure rule must originate from an independently verified user intent, a standing account policy, or native protocol logic that a compromised interface component cannot tamper with or overwrite.
Three Design Choices and EIP-7906
Implementing native transaction assertions at the protocol level requires core developers to resolve three primary design choices: determining what exact information the EVM exposes, establishing how assertion code accesses that data, and defining where the supporting opcodes are permitted to execute. Proposals must decide whether to expose state modifications, event logs, or both. Access mechanisms could range from enumerating entries and looking up specific storage values to copying the complete set of net changes directly into memory. Additionally, developers must decide whether the new opcodes should be restricted to specific transaction types or execution phases, or made universally available throughout the EVM.
A leading approach currently under active consideration is EIP-7906, which builds directly upon the frame transaction architecture outlined in EIP-8141. A frame transaction structures execution into an ordered sequence of distinct validation and action steps. EIP-7906 expands this framework by introducing a read-only POST_TX execution frame at the very conclusion of the transaction to verify the final outcome. While related proposals like EIP-8141 are advancing toward upcoming network upgrades, EIP-7906 has progressed to the "Considered for Inclusion" stage, though it is not yet finalized for deployment.
The EIP-7906 specification exposes both state changes and event data. Net state changes are reported as the net difference in native ETH balances and storage slots, alongside newly deployed contract addresses and their respective code hashes. If a specific storage slot is modified multiple times during a transaction but ultimately returns to its original value by the end of execution, it is omitted entirely, reducing computational overhead.
To interact with this data, the proposal introduces three new EVM opcodes. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for targeted addresses and storage slots, and EVENTDATACOPY copies specific event data directly into memory. These specialized opcodes are restricted to functioning exclusively inside the POST_TX frame, which operates as a static call at the end of the transaction lifecycle. This architectural design enables the assertion logic to inspect outcomes without risking unintended state mutations. If a rule violation occurs, the entire transaction body reverts, but the transaction record remains permanently logged onchain with a failed status, and the gas payer is billed for the execution resources consumed. This economic enforcement prevents malicious actors from spamming network builders with deliberately failing transactions for free.
The Assertion Has to Be Required
Because EIP-7906 does not inherently mandate that every single transaction must include an assertion, transaction builders retain the technical capability to omit them entirely. To achieve meaningful security, the workflow must be enforced at the application and wallet layers.
For standard user transactions, modern wallets must ensure that every constructed frame transaction automatically incorporates the necessary assertion, derived either from a secure client-side simulation or a standing account policy. Concurrently, decentralized protocols wishing to protect their users must design their smart contracts to verify that incoming calls originate strictly from frame transactions carrying the exact required assertion. This means protocols would need to reject standard legacy transactions as well as frame transactions with missing or improperly configured assertions. Consequently, integrations and callers would need to adopt compatible frame transaction formats, though already deployed immutable contracts would lack the ability to retrofit this specific verification check.
Where Transaction Assertions Could Help
Beyond mitigating basic user-facing vulnerabilities and protocol exploits, native transaction assertions unlock a wide array of advanced use cases across the Ethereum ecosystem. For instance, they can significantly strengthen account delegation frameworks. When delegating operational authority to an automated agent or third-party service, users can already limit which contracts the agent accesses, spending caps, and permission durations. Transaction assertions introduce an extra layer of granular control by constraining the exact economic and state-based outcome of each delegated action.
Furthermore, protocols can establish standardized safety rules applicable to any interacting user via frame transactions. In solver-based execution models, a protocol could specify the required outcome while granting independent solvers the flexibility to determine the optimal routing path to achieve it. While these guarantees remain scoped to a single transaction on a specific network rather than spanning multi-chain routing paths, they provide unprecedented finality assurance. Assertions can also verify that complex multi-step workflows reach their intended terminal state, ensuring that any residual unused tokens are safely returned to the user and lingering token approvals are automatically revoked before finalization.
Help Shape the Design
Research and development surrounding native transaction assertions remain ongoing under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Core researchers are actively seeking feedback from wallet providers, infrastructure developers, and protocol teams who intend to integrate these features. Stakeholders interested in exploring potential use cases or contributing to the research can reach out via email to [email protected] or participate directly in the ongoing EIP-7906 discussion thread on the Ethereum Magicians forum. Additional information regarding foundational risk controls and priority development areas is available at the initiative’s official portal.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
