Layla Zulfa
The Ethereum Foundation’s ambitious Trillion Dollar Security initiative, launched in May 2025, has pinpointed critical vulnerabilities in the user experience: blind signing and transaction uncertainty. In response, the Foundation is actively developing and exploring native transaction assertions as a pivotal next step to robustly enforce a transaction’s final outcome. This groundbreaking effort runs in parallel with the previously announced Clear Signing initiative (May 2026), aiming to provide a comprehensive security framework for the burgeoning decentralized ecosystem. This article delves into the inherent risks of current Ethereum transaction mechanisms, the limitations of existing defenses, the proposed solution of native transaction assertions, and the design principles guiding their implementation, particularly through the lens of EIP-7906 (Transaction Assertions via State Diff Opcode).
The Peril of Transaction Uncertainty: Why a Signature Isn’t Enough
At its core, the challenge stems from how the Ethereum Virtual Machine (EVM) operates. It meticulously executes precisely what a user authorizes, without an inherent mechanism to discern if the resulting state aligns with the user’s ultimate intent. A digital signature unequivocally commits to a specific transaction request, but its actual outcome is dynamically determined by the underlying smart contract code and the prevailing blockchain state at the moment of execution. This disjunction frequently leads to substantial financial losses for users, falling into two primary categories: intent mismatch and outcome mismatch.
An intent mismatch occurs when users sign a transaction believing they are approving one action, only for the underlying request to be fundamentally different. This insidious form of attack often exploits compromised frontends or sophisticated social engineering. A stark illustration of this was the Bybit incident, where attackers successfully compromised a frontend interface. Unsuspecting users, interacting with what they believed to be a legitimate interface, were prompted to sign transactions. Unbeknownst to them, these transactions authorized the replacement of Safe’s implementation contract, a critical component of their multi-signature wallets. Had the attack fully materialized, it could have led to a systemic compromise of funds managed by these Safe contracts. Similarly, the infamous BadgerDAO attack, which transpired in December 2021 and resulted in over $120 million in losses, saw users unknowingly grant attackers permission to spend their deposited tokens. A compromised user interface displayed seemingly innocuous prompts, while the signed transaction calldata silently conferred broad token spending approvals to malicious addresses.
The second category, outcome mismatch, arises even when a user knowingly approves the transaction presented to them. However, due due to dynamic on-chain conditions, the transaction’s execution either exceeds predefined limits or interacts with the blockchain state in a way that produces an unintended or economically detrimental result. The Aave and CoW collateral swap incident serves as a sobering example. A user initiated a swap of approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE on the CoW Swap protocol was extremely shallow for a transaction of this magnitude. Furthermore, CoW Swap’s internal gas ceiling mechanisms, designed to prevent excessively complex or costly transactions, rejected more favorable quotes during the verification phase, leaving only one viable, albeit disastrous, quote offering roughly 329 aEthAAVE. Despite the interface displaying a glaring 99.9 percent price impact warning and requiring explicit user confirmation acknowledging potential total loss, the user proceeded. The outcome was receiving tokens valued at a mere $36,000 – a catastrophic loss of over $50 million.
In all three cases, a critical missing piece was a reliable, trusted rule governing the final state of the blockchain, enforced independently of the transaction builder and during the actual execution. For the Bybit incident, a vital rule would have mandated that the approved Safe implementation contract remain unchanged. For BadgerDAO users, a rule could have restricted new token approvals exclusively to whitelisted, published Badger contracts. In the Aave case, the user could have stipulated a minimum acceptable output for the swap, calculated independently of the quote provided by the interface. Crucially, Ethereum currently lacks a general, native mechanism for on-chain code to comprehensively inspect the full suite of net state changes and events generated by a transaction, leaving a significant security gap.
The Technical Labyrinth: What a Signature Does Not Control
A user’s digital signature on Ethereum is a commitment to a specific action, encompassing the target contract address, the value (ETH) to be sent, and the calldata (the function to call and its arguments). The EVM then executes this call against the contract code and state that are present at the time the transaction runs. This is a critical distinction, as both the code and the state can evolve between the moment a user signs a transaction and its inclusion in a block. Consequently, the resulting net balance and storage changes, along with any emitted events, can deviate dramatically from the user’s initial expectation.
Consider the intricate interplay: the signed request provides the intent, but the code and state at execution time determine the outcome. The target contract, or any contract it subsequently calls, might utilize a proxy pattern where the underlying implementation contract can be upgraded or replaced before the transaction executes. This means the actual code that runs could be entirely different from what the user initially inspected and approved. Furthermore, transaction ordering, often influenced by miner extractable value (MEV) strategies, can profoundly alter the state that a user’s call encounters. For instance, a "sandwich attack" can front-run a user’s swap, manipulate the pool’s price, and then back-run it, all without altering the user’s signed transaction, yet leading to significant financial detriment for the user. These dynamic elements underscore the inherent limitations of a signature alone to guarantee a desired outcome in a mutable blockchain environment.
Current Security Measures: Strengths and Limitations
While Ethereum’s ecosystem has developed several layers of defense, each has its inherent limitations, failing to provide a complete shield against all forms of transaction uncertainty.
Clear Signing, a significant improvement, aims to present users with a human-readable interpretation of the action their calldata requests. It decodes complex hexadecimal transaction data into understandable language, allowing users to verify the intended operation. However, its effectiveness hinges on two key factors: the accuracy and trustworthiness of the decoding mechanism, and the user’s ability to recognize when the decoded action deviates from their true intent. In sophisticated attacks, even clear signing might be circumvented if the malicious payload is crafted to appear benign or if the user is overwhelmed by complex information.
Transaction Simulation offers another line of defense. Wallets and security services often simulate a transaction’s effects using a snapshot of a selected chain state. This provides a predictive preview of the potential outcome. Yet, simulations are not infallible. The actual chain state can change between the moment of simulation and the transaction’s inclusion in a block, rendering the simulation’s prediction inaccurate. More critically, as seen in the Radiant Capital post-mortem where approximately $4.5 million was lost, sophisticated malware on users’ machines can substitute a malicious payload at the precise moment of signing, despite both the wallet interface and pre-signing simulation displaying the intended, benign transaction. The simulation provides a snapshot of what would happen if this specific transaction ran now, but it cannot guarantee that this specific transaction is what ultimately gets signed and broadcast.
On-chain Contract Checks and Wallet Guards represent a programmatic approach to enforcing rules during EVM execution. Protocols like Uniswap, for instance, incorporate amountOutMinimum parameters, which revert a swap if the output tokens fall below a specified threshold, protecting against severe price slippage. Similarly, Safe (formerly Gnosis Safe) utilizes a checkAfterExecution hook, enabling a guard contract to inspect the account’s state after a transaction’s execution and revert it if it violates predefined rules for owners or configuration. While powerful, these approaches also have limitations. They necessitate choosing which state variables to check in advance, meaning they can only guard against foreseen deviations. Reading another contract’s storage often depends on specific getter functions exposed by that contract. A token contract’s balanceOf function makes balance checks straightforward, but a proxy contract might not expose its implementation address through a public function, preventing a guard from directly reading the critical implementation slot. Most importantly, these existing checks cannot inspect the full set of net state changes produced by a transaction. A guard can confirm that a particular balance remains unchanged, but it lacks the EVM-native capability to query everything else that might have changed, leaving unnoticed effects that were not specifically designed to be checked.
Introducing Native Transaction Assertions: A Paradigm Shift
Native transaction assertions are poised to introduce a profound paradigm shift in Ethereum’s security architecture. This proposed mechanism would empower on-chain code to meticulously inspect the entire set of net state changes following a transaction’s execution. An assertion operates as a read-only logic module that compares the blockchain’s state before and after the transaction’s actions have run, against a predefined rule. Should this rule be violated, the entire set of actions within the transaction is automatically reverted, ensuring the user’s intended outcome or preventing an undesired one.
The assertion rule itself is embedded within the transaction and cryptographically signed alongside the transaction’s core actions. This rule offers comprehensive coverage, capable of scrutinizing net changes to native ETH balances, contract storage, deployed code, newly deployed contracts, and even emitted events. For instance, an assertion could mandate a minimum amount of tokens received in a swap, cap the total spending from an account, explicitly block new token approvals, ensure an account’s critical control logic (e.g., a multi-sig owner list) remains unaltered, or restrict changes to only a specified, whitelisted set. This capability ensures that users can define granular, outcome-based security policies that are enforced directly by the EVM.
Crucially, the source of the assertion rule is as vital as the check itself. A compromised frontend could, theoretically, craft a malicious assertion that permits an attack. Therefore, a truly effective rule must originate from an independently approved source of user intent, a robust standing account policy (such as those managed by smart contract wallets), or immutable protocol logic that cannot be tampered with by a compromised component. This independence is key to preventing sophisticated supply-chain attacks.
The EIP-7906 Framework: A Concrete Proposal
One prominent approach to realizing native transaction assertions is outlined in EIP-7906, which builds upon the concept of "frame transactions" defined in EIP-8141. Frame transactions structure a transaction into an ordered sequence of distinct validation and action steps. EIP-7906 specifically introduces a read-only POST_TX frame that executes at the very end of the transaction’s lifecycle, dedicated to verifying the transaction’s outcome against assertions. As of the current development roadmap, EIP-8141 is provisionally scheduled for inclusion in the upcoming Hegotía network upgrade, while EIP-7906 has advanced to "Considered for Inclusion" status, indicating strong interest but awaiting final confirmation for a future upgrade.
The design of EIP-7906 is meticulously crafted to expose comprehensive state information to the assertion logic. State changes are reported as net differences: the aggregate change in native ETH balances and storage slots, alongside the code hashes of newly deployed contracts. Significantly, if a storage slot is written to multiple times within a transaction, it appears as a single entry in the state diff, showing only its starting and final values. If a slot ultimately reverts to its original value, it does not appear in the diff at all, ensuring efficiency and clarity. The proposal also makes all emitted events accessible.
To facilitate access to this rich information, EIP-7906 introduces three powerful new EVM opcodes (low-level instructions):
TXTRACE: This opcode enables the enumeration of all net state changes and events produced by the transaction. It allows assertion logic to iterate through all modifications.TXDIFF: This opcode provides a targeted way to retrieve the starting and final values for specific addresses and storage slots, allowing for precise checks on known variables.EVENTDATACOPY: This opcode allows an assertion to copy the data from a specific event into memory, enabling detailed inspection of event logs.
These specialized opcodes are designed to function exclusively within the POST_TX frame. This frame executes as a static call, meaning it can read the state but cannot modify it itself. This critical design choice ensures that the assertion logic can inspect the outcome without introducing any unintended side effects or vulnerabilities. If an assertion rule is violated within the POST_TX frame, the entire execution body of the transaction is reverted. However, the transaction itself remains in the block with a failed status, and the gas payer is still charged for the gas consumed up to the point of reversion. This mechanism is crucial for preventing attackers from repeatedly submitting deliberately failing transactions to force builders to expend computational resources for free.
Enforcement and Adoption: The Path Forward
While EIP-7906 provides the foundational tools for native transaction assertions, it does not inherently mandate their inclusion in every transaction. This necessitates strategic adoption and enforcement across the ecosystem.
For a user’s own transactions, the responsibility largely falls on the wallet interface. Wallets must evolve to ensure that every frame transaction they construct includes the appropriate, user-defined assertion. This rule could be automatically generated based on a simulation performed by the wallet or derived from a standing, pre-configured security policy that applies to all transactions originating from that wallet. This places a significant burden and opportunity on wallet developers to integrate this new security primitive seamlessly.
For protocols and dApps, adoption requires a more direct approach. A protected function within a smart contract would need to verify that any incoming call originates from a frame transaction that includes the exact required assertion. This implies that protocols would need to reject ordinary transactions or frame transactions with missing or incorrect assertions. This necessitates that callers and integrations adapt to using compatible frame transactions. A significant challenge here is that already deployed, immutable smart contracts cannot easily be retrofitted with this check, limiting immediate universal adoption for existing infrastructure. However, new contracts and upgrades could certainly incorporate this powerful validation.
Broader Implications and Transformative Use Cases
Beyond the immediate security benefits for individual users and protocols, native transaction assertions unlock a spectrum of transformative use cases across the Ethereum ecosystem.
One significant area is strengthened delegation. When users delegate authority to an agent (e.g., a smart contract, a relayer, or even another wallet) to act on their behalf, they typically implement controls over which contracts the agent can interact with, how much it can spend, and the duration of its permissions. Transaction assertions could add an unprecedented layer of control by allowing users to define precise rules for the outcome of each delegated transaction. This means constraining not only what the agent may do but also what its actions must produce, providing a more robust and trustworthy delegation framework.
Protocol-defined safety checks could also become standardized. A protocol could define its own universal assertion rule, requiring the same safety check for every caller utilizing a frame transaction. In complex solver-based execution flows, where solvers compete to find the most efficient transaction routes, the protocol could specify the required outcome (e.g., minimum output, maximum slippage) through an assertion, while granting the solver complete freedom to choose the optimal execution path. This guarantees the user’s desired result irrespective of the solver’s chosen strategy. It’s important to note that this guarantee would apply within the confines of a single transaction on a single network, and would not extend to multi-chain or cross-protocol routes. Furthermore, assertions could be leveraged for comprehensive workflow verification, ensuring that a multi-step process reaches its intended final state – for example, verifying that unused tokens are returned to the user, and any temporary token approvals granted during the workflow are subsequently revoked.
These capabilities collectively foster a significantly more secure, predictable, and trustworthy environment for users, developers, and institutions engaging with Ethereum. By reducing the surface area for various attack vectors and mitigating the risks associated with transaction uncertainty, native transaction assertions are a cornerstone in the Ethereum Foundation’s "Trillion Dollar Security" vision, paving the way for greater mainstream and institutional adoption of decentralized technologies.
Timeline and Community Engagement
The Trillion Dollar Security initiative, a long-term strategic endeavor, commenced in May 2025, with Clear Signing announced in May 2026 as an initial step. The ongoing research and development into native transaction assertions, epitomized by EIP-7906, represent a critical advancement in this multi-year roadmap. EIP-8141 (Frame Transactions), which provides the structural foundation for EIP-7906, is slated for the Hegotía network upgrade, demonstrating a clear commitment to integrating these foundational changes into the Ethereum protocol. While EIP-7906 is "Considered for Inclusion," signifying active discussion and potential integration, the timeline for its final confirmation and deployment remains subject to further research, refinement, and community consensus.
The Ethereum Foundation emphasizes that solutions for native transaction assertions are still in active design and development phases. They are keenly soliciting input and collaboration from wallet developers, protocol teams, and the broader community who stand to benefit most from these advancements. This collaborative approach is vital to ensure the proposed solutions are practical, effective, and widely adopted. Interested parties are encouraged to contribute to this pivotal work by contacting [email protected] to explore use cases and help shape the ongoing research. Additionally, active participation in the EIP-7906 discussion thread on Ethereum Magicians offers a direct avenue for technical feedback and engagement.
Further information on risk controls and priority work within the Trillion Dollar Security initiative can be found at trilliondollarsecurity.org, underscoring the Foundation’s unwavering commitment to fortifying Ethereum’s security posture for its increasingly complex and valuable ecosystem.
