As part of the broader ongoing efforts within the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers are focusing heavily on user experience risks associated with blind signing and transaction uncertainty. To combat these persistent threats, the initiative is actively exploring the implementation of native transaction assertions as a crucial next step. These assertions are designed to enforce a transaction’s final outcome deterministically, working alongside parallel security paradigms like Clear Signing to offer a more robust defense layer for everyday users and major protocols alike.
The primary motivation behind this research centers on a fundamental reality of how Ethereum operates: the network executes instructions precisely as they are authorized, without making subjective judgments about whether the resulting state matches the user’s actual intent. While a cryptographic signature commits a user to a specific request, the ultimate outcome of that request is heavily dependent on the surrounding code and blockchain state it encounters during actual execution. Over the history of the ecosystem, substantial funds have been lost not only because individuals inadvertently approved malicious actions they did not understand, but also because intended actions frequently yielded economic results that directly conflicted with the user’s original goals.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize these catastrophic execution discrepancies into two distinct categories: intent mismatches and outcome mismatches. The first category involves a mismatch between what a user believes they are signing and what is actually submitted to the network. High-profile security breaches, such as the widely documented Bybit incident and the historical BadgerDAO attack, starkly illustrate this vulnerability. In both instances, a compromised frontend successfully supplied a signing request that fundamentally differed from what the affected users thought they were approving. During the Bybit incident, authorized signers unknowingly approved instructions that replaced the implementation contract of a Safe wallet, whereas BadgerDAO users inadvertently granted malicious actors sweeping permissions to drain their tokens.
The second category involves outcome mismatches, where a signer deliberately approves the exact request presented by an interface, but underlying limits or unfavorable state conditions lead to an execution result that violates their economic objectives or standing safety policies. A prominent example of this occurred during the Aave and CoW collateral swap event. In that scenario, a user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Unfortunately, the available AAVE liquidity was far too shallow to accommodate a single trade of that magnitude. Furthermore, CoW’s internal gas ceiling mechanism rejected the more complex multi-hop quotes during verification, leaving only a single verified quote valued at roughly 329 aEthAAVE. Although the user interface prominently displayed a 99.9 percent price impact warning and explicitly required confirmation acknowledging that the entire position could be lost, the user signed the transaction regardless, ultimately receiving tokens worth a mere $36,000.
In all three of these historical scenarios, a critical missing component was a trusted, enforceable rule governing the resulting state—one defined completely independently of the transaction builder and strictly enforced during execution. In the Bybit situation, an ideal safety rule would have mandated that the approved Safe implementation contract remain entirely immutable. For BadgerDAO users, an automated rule would have restricted new token approvals exclusively to verified, published contracts. For the Aave swap, a reliable rule would have enforced a strict minimum acceptable output calculated independently of the quotes provided by the frontend interface. Currently, however, Ethereum lacks a general, native mechanism for onchain code to inspect the comprehensive set of net state changes and emitted events generated by a transaction.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is essential to examine the technical limitations of standard cryptographic signatures. When a user signs a transaction, they are committing solely to the specific request parameters, which include the target contract, the transferred value, and the associated calldata. However, the Ethereum Virtual Machine executes this call against the specific contract code and blockchain state present at the exact moment the transaction is included in a block—conditions that may have altered dramatically since the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can deviate wildly from expectations.
The target contract specified in a transaction, or any other contract it subsequently calls, may rely on a proxy architecture whose implementation address changes prior to execution. As a result, the executing code can be entirely different from the code the user originally audited or inspected. Furthermore, transaction ordering within a block introduces severe unpredictability. Adversarial actors can execute frontrunning or sandwich attacks that manipulate liquidity pool prices right before a victim’s swap executes, altering the economic reality of the trade without ever touching the victim’s signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has developed several vital defensive measures to mitigate these risks, but each possesses inherent boundaries. One primary defense is Clear Signing, which translates complex calldata into human-readable terms for the user. However, Clear Signing remains entirely dependent on accurate decoding mechanisms and relies on the user’s ability to recognize discrepancies between the displayed interpretation and their true intent.
Another widely adopted defense is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. Because the underlying chain state can shift before inclusion, and because malicious malware can substitute a completely different payload at the exact moment of signing, simulation alone cannot guarantee safety. This vulnerability was clearly demonstrated during the Radiant Capital post-mortem, where both wallet interfaces and simulation tools accurately displayed the intended transaction, while local malware on the signers’ machines secretly swapped in a malicious payload during the signing process.
Contract-level checks and specialized wallet guards also attempt to enforce safety rules during EVM execution. For instance, Uniswap automatically reverts a swap if the final output falls below a user-defined threshold, while Safe accounts utilize execution hooks to inspect account states and block configurations that violate predefined owner policies. Nevertheless, these existing approaches require developers to anticipate which specific states to check in advance. To read another contract’s storage, they must rely entirely on the explicit functions exposed by that contract. While checking a standard token balance is straightforward, a proxy contract is not obligated to expose its implementation slot through a standard read function, leaving guards blind to subtle architectural changes. Ultimately, these traditional checks cannot comprehensively inspect the full scope of net state changes produced across an entire transaction.
How Native Transaction Assertions Work
To bridge these defensive gaps, native transaction assertions are being designed to empower onchain code to inspect the complete set of net state changes after all transaction actions have fully executed. Utilizing lightweight, read-only logic, an assertion compares starting values and final values against a predefined rule. If the established rule is violated, the entire transaction reverts, protecting the user from unintended outcomes.
These rules are embedded directly within the transaction payload and signed alongside the core actions. They can encompass net changes to native balances, storage slots, and code deployment, as well as newly instantiated contracts and emitted events. Effectively, an assertion can enforce minimum receiving amounts, cap spending permissions, block unauthorized token approvals, preserve account control logic, or restrict execution to an approved set of state modifications. Crucially, the origin of the rule is as vital as the check itself; because a compromised frontend could theoretically draft an assertion that permits an attack, valid rules must originate from independently verified user intent, standing account policies, or immutable protocol logic that untrusted interfaces cannot manipulate.
EIP-7906 as a Possible Solution
Among the various proposals currently under consideration, Ethereum Improvement Proposal 7906 stands out as a prominent approach. Building directly upon the foundation transactions defined in EIP-8141, EIP-7906 introduces a specialized read-only execution phase at the conclusion of a transaction to evaluate its ultimate outcome. While EIP-8141 has advanced toward upcoming network upgrades, EIP-7906 is currently classified as being under active consideration for inclusion, reflecting its ongoing maturation through community discussions on platforms like Ethereum Magicians.
The design of EIP-7906 exposes comprehensive state changes and event logs. State alterations are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. To maximize efficiency, a storage slot that is modified multiple times during execution is reported as a single net entry representing its initial and final values. Three new EVM instructions—TXTRACE, TXDIFF, and EVENTDATACOPY—provide the underlying machinery required to enumerate net changes, query specific storage slots, and copy event data into memory for evaluation.
These opcodes function exclusively within a protected final execution frame, ensuring that assertions operate purely in a read-only capacity without altering state. If an assertion fails, the execution body reverts entirely, yet the transaction remains recorded in the block with a failed status, ensuring that the gas payer is appropriately charged for consumed computational resources. This economic disincentive prevents malicious actors from exploiting the feature to force block builders to process failing transactions without cost.
Moving Forward and Shaping the Design
Because EIP-7906 does not mandate that every transaction include an assertion by default, wallet providers and protocol developers must proactively integrate these checks into their workflows. For user-initiated transactions, wallets will be responsible for ensuring that constructed frame transactions incorporate robust assertions derived from verified simulations or standing account policies. Meanwhile, decentralized protocols seeking to protect their users will need to ensure that critical functions verify incoming calls originate from frame transactions carrying the correct, expected assertions.
Beyond basic user protection, native transaction assertions hold significant promise for advanced use cases such as delegated agent execution, where users can establish strict automated boundaries over what actions and economic outcomes an authorized agent is permitted to produce. As research and development continue under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, stakeholders, wallet developers, and protocol architects are encouraged to engage with the core research teams. Interested contributors can reach out via email to explore specific use cases or participate directly in community development threads to help refine the architecture of these emerging security standards.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
