The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as critical user experience risks within the decentralized finance ecosystem. As part of its ongoing efforts to harden network security alongside features like Clear Signing, researchers are exploring native transaction assertions as a fundamental next step to enforce the final, exact outcome of a blockchain transaction.
This proactive push addresses a foundational vulnerability in how blockchain applications process requests. While users frequently sign transactions expecting a specific result, valid cryptographic signatures do not currently guarantee that the execution phase will yield the desired economic or structural outcome. By introducing native transaction assertions, the Ethereum ecosystem hopes to provide a reliable safety net where current security defenses ultimately stop.
Two Ways a Signed Transaction Can Go Wrong
The security challenge originates from the deterministic nature of Ethereum. The EVM executes instructions precisely as authorized without inherently judging whether the outcome aligns with the user’s intent. A cryptographic signature commits a user to a specific request, but the actual result depends heavily on the prevailing contract code and network state encountered during execution. Over the history of the network, users have suffered significant financial losses either because they approved a request that differed from their understanding, or because an intended request produced an unintended economic outcome.
These vulnerabilities generally manifest in two distinct scenarios: intent mismatches and outcome mismatches. Intent mismatches occur when a compromised or malicious frontend supplies a signing request that deviates from what the user believes they are approving. High-profile security breaches, such as the Bybit incident and the BadgerDAO attack, illustrate this danger clearly. During the Bybit security event, signers unwittingly authorized the replacement of a Gnosis Safe implementation contract, while BadgerDAO users unknowingly granted malicious actors unlimited permissions to spend their underlying tokens.
In contrast, outcome mismatches occur when the signer fully approves the transaction presented to them, but fluctuating liquidity limits or dynamic onchain states produce results that conflict directly with their financial goals. A prominent example of this dynamic unfolded during an Aave and CoW collateral swap. In that event, a user attempted to swap roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was remarkably thin 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 user interface displayed a severe 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 of these historical cases, the common missing element was a trusted, immutable rule governing the resulting state—defined independently of the transaction builder and strictly enforced during execution. Bybit users would have benefited from a rule requiring the Safe implementation to remain untouched, BadgerDAO participants needed rules restricting new approvals exclusively to published contracts, and the Aave user required a rule enforcing 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 comprehensive 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 signature commits strictly to specific parameters, including the destination target, transferred value, and calldata payload. However, the EVM executes this call against whatever contract code and network state happen to exist at the exact moment the transaction is processed, which may have shifted drastically since the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can diverge widely from initial expectations.
The target contract, or any secondary contracts it interacts with, may rely on proxy patterns where the implementation address changes prior to execution, meaning the executing code differs from what the user originally inspected. Furthermore, transaction ordering within a block introduces significant volatility. A classic example is a sandwich attack, where a malicious actor manipulates a decentralized exchange liquidity pool’s price immediately before a user’s swap executes, altering the financial outcome without ever modifying the user’s signed transaction payload.
Where Today’s Defenses Stop
The broader Ethereum community has implemented several layers of defense to mitigate these operational risks, yet each comes with inherent limitations. Clear Signing initiatives strive to explain the requested actions in human-readable terms, but they rely entirely on accurate payload decoding and depend on the user’s ability to spot discrepancies between the displayed interpretation and their actual intent.
Simulation tools represent another common safeguard, predicting a transaction’s effects using a chosen snapshot of the chain state. Because chain states change constantly before block inclusion, and because malicious malware can substitute a harmful payload on the user’s machine at the exact moment of signing—as demonstrated in the Radiant Capital post-mortem—simulation alone remains insufficient. In the Radiant Capital incident, both the wallet interface and the transaction simulation displayed the benign, intended transaction, while hidden malware swapped out the payload during final authorization.
Existing contract checks and wallet guards also attempt to enforce safety rules during EVM execution. For example, Uniswap protocols automatically revert a swap if the resulting output falls below a pre-set amountOutMinimum threshold. Similarly, Safe’s checkAfterExecution hook permits a guard to inspect an account’s state after transaction execution and revert any actions that violate configuration policies. However, these mechanisms require developers to anticipate which specific state variables to check in advance. Reading another contract’s storage depends entirely on the specific functions that contract chooses to expose publicly. While checking a token balance via balanceOf is straightforward, an unexposed proxy implementation slot remains invisible to external guards without dedicated interface support. Crucially, these existing checks are fundamentally incapable of inspecting a transaction’s full, overarching set of net state changes.
How Native Transaction Assertions Work
Native transaction assertions propose a structural shift by allowing onchain code to inspect the complete set of net state changes after a transaction’s primary actions have finished executing. Utilizing read-only logic, an assertion evaluates starting and final values against a predefined rule set. Should the rule evaluate as false, the entire transaction reverts.
Crucially, these rules are bundled directly into the transaction payload and signed alongside the core actions. They can govern net changes across native balances, storage slots, newly deployed contracts, and emitted events. Assertions can enforce strict economic bounds, such as requiring a minimum token receive amount, capping spending limits, blocking unauthorized token approvals, preserving specific account control logic, or permitting only an authorized subset of state changes.
However, the provenance of the rule is just as vital as the verification mechanism itself. If a compromised frontend is allowed to write the assertion rule unchecked, it can easily craft an assertion that permits the malicious exploit. Therefore, effective rules must originate from independently verified user intent, established account policies, or trusted protocol logic that compromised frontends cannot tamper with.
Three Design Choices and EIP-7906 as a Possible Solution
Implementing native transaction assertions requires delicate architectural decisions concerning what operational information the EVM exposes, how assertion code interacts with that data, and where the associated opcodes are permitted to execute. Developers must weigh whether to expose state changes, event logs, or both, as well as determine whether assertion code should enumerate specific entries, look up individual values, or copy complete change sets into memory.
One of the leading approaches currently under active consideration is EIP-7906, which builds directly upon the foundational frame transactions outlined in EIP-8141. While EIP-8141 introduces an ordered sequence of validation and action steps, EIP-7906 adds a dedicated, read-only POST_TX frame at the very end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has advanced toward inclusion in the upcoming Hegotá network upgrade, EIP-7906 has progressed to being "Considered for Inclusion," though its ultimate confirmation remains pending.
The design of EIP-7906 exposes comprehensive state changes and event data, reporting native ETH balance modifications, storage updates, newly deployed contracts, and their associated code hashes as net differences. Storage slots modified multiple times within a single transaction appear as a single entry denoting their initial and final states, while slots returning to their original values are omitted entirely. Three new EVM instructions facilitate this inspection process: TXTRACE to enumerate net state changes and events, TXDIFF to retrieve starting and final values for specific addresses and storage slots, and EVENTDATACOPY to load event data into memory.
These opcodes operate exclusively within the POST_TX frame, executing as a static call at the conclusion of the transaction to inspect results without altering state. If an assertion rule is violated, the execution body reverts entirely, yet the transaction remains recorded in the block with a failed status, ensuring the gas payer is properly charged for consumed computational resources. This economic penalty effectively prevents malicious actors from spamming block builders with deliberately failing transactions.
The Assertion Has to Be Required
Because EIP-7906 does not mandate the inclusion of an assertion in every standard transaction, transaction builders retain the technical ability to omit them. Consequently, user wallets must ensure that any frame transaction they construct explicitly embeds the necessary safety assertions, drawing rules either from pre-execution simulations or standing user policies.
Similarly, protected protocol functions must verify that incoming calls originate from frame transactions containing the exact mandatory assertions, explicitly rejecting ordinary transactions or frame transactions featuring missing or invalid rules. Because legacy, immutable smart contracts deployed prior to these standards cannot retroactively enforce these checks, widespread integration will require coordinated ecosystem adoption among wallets, solvers, and application developers.
Where Transaction Assertions Could Help
Beyond fortifying standard user and protocol security, native transaction assertions unlock powerful capabilities across various emerging web3 paradigms. For instance, they can significantly strengthen account delegation and autonomous agent workflows. When users authorize autonomous agents to act on their behalf, assertions can enforce strict boundaries regarding permissible target contracts, spending limits, duration, and crucially, the precise economic outcome of the agent’s actions.
Protocols can also define standardized safety rules that must accompany any caller utilizing a frame transaction. In solver-based execution models, protocols can specify required outcomes while allowing solvers optimal flexibility in determining execution routes. Furthermore, assertions can verify that multi-step workflows reach their intended final states cleanly, guaranteeing that residual tokens are correctly returned to the user and superfluous approvals are systematically revoked.
Help Shape the Design
Research and development surrounding native transaction assertions remain active components of the Ethereum Foundation’s Trillion Dollar Security initiative. Foundation researchers are actively seeking feedback and collaboration from wallet developers, infrastructure providers, and protocol engineers who stand to utilize these capabilities. Interested stakeholders are encouraged to reach out to explore potential use cases, contribute to ongoing research, or join the community discussion threads dedicated to EIP-7906 as the technical specifications continue to evolve.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
