The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as critical user experience and safety risks across the ecosystem. As part of its ongoing efforts to harden network security alongside the deployment of Clear Signing, researchers are exploring native transaction assertions as a fundamental next step to enforce a transaction’s final outcome directly at the protocol level.
This technical exploration delves into why possessing a valid signature does not always guarantee a desired transaction result, how native transaction assertions could protect users beyond the limits of current defenses, and the core design choices driving these proposals. Among the primary approaches under consideration is EIP-7906, which introduces transaction assertions via a state diff opcode to secure user intent against unexpected execution environments.
Two ways a signed transaction can go wrong
The root of the problem lies in the deterministic nature of how Ethereum operates. The EVM executes instructions exactly as authorized, without exercising judgment over whether the resulting state aligns with the user’s actual intent. A cryptographic signature commits a user to a specific request, but the ultimate outcome depends heavily on the prevailing contract code and onchain state encountered at the moment of execution. Over the history of the network, users have suffered substantial losses either because they approved a request that differed from what they believed they were signing, or because a legitimate request produced an economically disastrous result due to shifting market conditions.
The first major failure mode is an intent mismatch, a vulnerability starkly illustrated by major security breaches such as the Bybit incident and the BadgerDAO attack. In both cases, compromised frontends supplied signing requests that deviated significantly from what users thought they were approving. During the Bybit security breach, signers unwittingly authorized the replacement of their Safe account’s implementation contract. Similarly, BadgerDAO users granted malicious actors broad permissions to spend tokens directly from their wallets under false pretenses.
The second failure mode is an outcome mismatch. In these scenarios, the signer approves the exact request presented to them, but tight execution limits, thin liquidity, or unfavorable state changes cause the transaction to resolve in a manner that directly conflicts with their economic goals or standing safety policies. A prominent example occurred during an Aave and CoW collateral swap, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because liquidity for AAVE 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 severe 99.9 percent price impact warning and forced manual confirmation of a potential total loss, the user signed the transaction regardless, ultimately receiving tokens valued at around $36,000.
What united these distinct incidents was the total absence of a trusted rule governing the resulting state—a rule defined independently of the transaction builder and enforced securely during execution. In the Bybit scenario, an independent rule would have mandated that the approved Safe implementation contract remain strictly unchanged. For a BadgerDAO user, a policy could have restricted new token approvals exclusively to published and verified protocol contracts. In the Aave swap incident, a strict rule would have enforced a minimum acceptable output calculated independently of the quotes displayed by the interface, assuming the underlying solver-based flow or settlement protocol required such an assertion. Currently, however, Ethereum lacks a general mechanism for onchain code to inspect the complete set of net state changes and emitted events produced by a single transaction.
What a signature does not control
When a user signs an Ethereum transaction, their cryptographic signature provides a definitive commitment to a specific action, including the designated target address, transferred value, and execution calldata. However, the EVM executes this call against whatever contract code and chain state happen to be present when the transaction finally runs. Because this state can fluctuate dramatically between the moment of signing and the moment of inclusion, the resulting net balance adjustments, storage modifications, and emitted events often diverge from user expectations.
The target contract itself, or any external contracts it invokes, may rely on proxy patterns where the underlying implementation changes unexpectedly before execution. Consequently, the actual code running onchain can differ entirely from what the user inspected beforehand. Furthermore, transaction ordering and adversarial mempool dynamics can manipulate the state encountered by a call. For instance, a classic sandwich attack can distort a decentralized exchange liquidity pool’s price right before a swap executes without altering the user’s signed transaction data in the slightest.
Where today’s defenses stop
The Ethereum ecosystem already relies on several defensive layers to mitigate these risks. One prominent mechanism is Clear Signing, which aims to provide users with a human-readable explanation of the actions requested by raw calldata. Despite its utility, Clear Signing depends entirely on accurate decoding logic and on the signer’s ability to recognize whether the presented action matches their true intent.
Another common defense is simulation, which attempts to predict a transaction’s effects using a snapshot of the current chain state. Because the underlying chain state can change prior to inclusion, and because a compromised signing environment can substitute a malicious payload at the final moment, simulation alone cannot guarantee safety. A stark example of this vulnerability occurred during the security incident at Radiant Capital, where both the user’s wallet interface and transaction simulation tools displayed the intended transaction accurately, while local malware on the signers’ machines substituted a malicious payload during the actual signing process.
Contract-level checks and wallet guards also enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a predefined amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook that enables a security guard to inspect the account’s state following execution, allowing it to revert transactions that violate established configuration rules. However, both approaches require developers to anticipate and choose which specific state variables to check in advance. To read another contract’s storage, these guards must rely entirely on the explicit functions exposed by that contract. While checking a token’s balance via balanceOf is straightforward, proxy contracts are not strictly required to expose their implementation addresses through a standard function call, leaving guards unable to read implementation storage slots directly.
Crucially, these conventional checks remain incapable of inspecting a transaction’s complete set of net state changes. While a guard can easily verify that a specific balance remained untouched, it cannot natively query the EVM for every other modification that occurred, leaving unintended side effects entirely undetected.
How native transaction assertions work
Native transaction assertions are designed to overcome these limitations by enabling onchain code to inspect the full set of net state changes after a transaction’s primary actions have executed. By utilizing specialized read-only logic, an assertion can compare starting values and final outcomes against a predefined set of rules. If these rules are violated, the transaction’s execution actions are immediately reverted.
Under this model, the governing rule is bundled directly into the transaction and cryptographically signed alongside its actions. This rule can encompass net changes across native balances, storage slots, newly deployed contract code hashes, and emitted events. It can enforce minimum received amounts, cap total spending, block unauthorized token approvals, preserve an account’s core control logic, or restrict execution to an explicitly approved set of state modifications.
The security of this mechanism depends heavily on the origin of the rule itself. If a compromised frontend is permitted to write the assertion, it could easily craft a rule that permits an attack rather than preventing one. Therefore, any effective security rule must originate from an independently verified user intent, a standing account-level security policy, or core protocol logic that cannot be manipulated by untrusted components.
Three design choices
Designing native transaction assertions requires balancing several core technical decisions regarding the information exposed by the EVM, the mechanisms assertion code uses to access that data, and the execution boundaries where relevant opcodes are permitted to run. Developers must determine whether the system should expose net state changes, emitted events, or both. Access options range from enumerating individual entries and looking up specific storage values to copying an entire set of net changes directly into memory. Furthermore, policymakers must decide whether to restrict these diagnostic opcodes to specialized transaction types and execution phases, or make them broadly available across the EVM.
EIP-7906 as a possible solution
One prominent proposal addressing these challenges is EIP-7906, which builds upon the frame transactions defined 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 positioned at the very end of the transaction lifecycle solely to evaluate the final outcome. EIP-8141 has advanced toward inclusion in upcoming upgrades like Hegotázquez, while EIP-7906 has progressed to being considered for inclusion, though it remains unconfirmed for deployment.
The architecture of EIP-7906 exposes both comprehensive state changes and event logs. State updates are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their associated code hashes. For instance, if a specific storage slot is written to multiple times within a single transaction, it is reported as a single consolidated entry detailing its initial and final values. If a slot ultimately reverts to its original value by the end of execution, it is omitted entirely.
Access to this diagnostic data is facilitated by three new EVM instructions. The TXTRACE opcode enumerates net state changes and emitted events, TXDIFF retrieves the starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies event data directly into memory. These powerful opcodes are restricted to functioning exclusively inside a POST_TX frame, which executes at the conclusion of the transaction as a static call. This ensures that assertions can inspect the final outcome without altering the state themselves. If a defined rule violation occurs, the entire transaction execution body reverts. However, the transaction remains recorded on the blockchain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement ensures that malicious actors cannot induce network validators to process deliberately failing transactions for free.
The assertion has to be required
Because EIP-7906 does not mandate that every transaction include an assertion, transaction builders retain the technical capability to omit them. Consequently, user wallets must ensure that every frame transaction they construct explicitly incorporates the necessary assertions. These safety rules can be derived automatically from local transaction simulations or enforced through a standing policy applied universally across all user activity.
Similarly, decentralized protocols seeking to protect their users must implement smart contract logic verifying that incoming calls originate from frame transactions carrying the precise, required assertions. Protected functions must strictly reject ordinary legacy transactions as well as frame transactions with missing or incorrect assertions. As a result, callers and protocol integrations must adopt compatible frame transaction formats, meaning already deployed, immutable contracts cannot retroactively add this layer of verification.
Where transaction assertions could help
Beyond mitigating direct security risks for individual users and protocols, native transaction assertions offer versatile utility for broader blockchain workflows. For example, they could significantly strengthen delegation models. When delegating operational authority to an automated agent, users could enforce strict limits on which contracts the agent can interact with, how much capital it can expend, and how long its permissions remain valid. Assertions would introduce programmatic constraints over the exact outcome of each agent-driven transaction, aligning permitted actions with guaranteed results.
Protocols could also define standardized safety rules, requiring identical verification checks for every caller utilizing a frame transaction. In solver-based execution architectures, a protocol could specify the exact required financial outcome while giving solvers the flexibility to determine the optimal routing path. Although such guarantees remain bound to a single transaction on a single network—and thus cannot inherently span multi-chain bridges—assertions can successfully verify that complex workflows reach their intended final states, ensuring unspent assets are safely returned and leftover token approvals are promptly revoked.
Help shape the design
The development of solutions for native transaction assertions remains an active area of research within the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback from wallet developers, protocol engineers, and security professionals who would ultimately implement and rely on these mechanisms. Stakeholders interested in exploring specific use cases and contributing to the research can reach out directly via email to [email protected] or participate in ongoing community discussions on the Ethereum Magicians forum under the EIP-7906 discussion thread. Additional information regarding ongoing risk controls and priority security initiatives can be found at trilliondollarsecurity.org.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
