Ethereum Foundation Unveils Native Transaction Assertions to Combat Blind Signing and Transaction Uncertainty Risks

The Ethereum Foundation’s Trillion Dollar Security initiative has spotlighted critical user experience risks stemming from blind signing and transaction uncertainty. In response, the initiative is actively exploring the implementation of native transaction assertions as a pivotal next step to robustly enforce a transaction’s final outcome. This development is being pursued in conjunction with existing efforts like Clear Signing, aiming to significantly bolster the security posture of the world’s leading smart contract platform.

This comprehensive overview delves into the fundamental issues that allow a valid signature to sometimes yield an unintended transaction result, explores how native transaction assertions are designed to safeguard users where current defenses falter, and outlines the key design considerations underpinning these proposed mechanisms. Among the most prominent approaches under consideration is EIP-7906, which suggests transaction assertions through a state difference opcode.

The Peril of Unintended Outcomes: Why Signed Transactions Go Astray

At its core, the challenge arises from Ethereum’s execution model. The network executes precisely what a user authorizes, without inherent mechanisms to validate whether the outcome aligns with the user’s true intent. A digital signature commits to a specific request, but the ultimate result of that request is contingent upon the smart contract code and the prevailing blockchain state at the moment of execution. This separation between authorization and outcome has led to significant financial losses for users, primarily through two distinct scenarios: intent mismatch and outcome mismatch.

An intent mismatch occurs when users unwittingly approve a transaction that is fundamentally different from what they believed they were signing. A prime example of this vulnerability was observed in the Bybit incident, where a compromised frontend interface presented users with a signing request that secretly aimed to replace the Safe’s implementation contract. Similarly, the BadgerDAO attack saw users granting an attacker sweeping permissions to spend their tokens, again due to a deceptive frontend presenting a malicious request disguised as a legitimate one. In both cases, the users’ signatures were valid for the presented (malicious) transaction, but their intent was entirely different.

The second scenario, an outcome mismatch, arises when a signer approves a request as displayed, but the transaction’s inherent limitations, or the state against which it executes, still permits an outcome that directly conflicts with their economic objectives or established safety policies. A notable instance involved a substantial Aave and CoW collateral swap. A user initiated a swap of approximately $50.4 million in aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was critically low for a transaction of this magnitude. Compounding the issue, CoW’s gas ceiling rejected more complex, safer quotes during verification, leaving only a single, highly unfavorable quote for roughly 329 aEthAAVE. Despite the interface prominently displaying a 99.9% price impact warning and requiring explicit user confirmation of potential total loss, the user proceeded to sign the transaction, ultimately receiving tokens valued at only about $36,000. In this case, the user signed what was shown, but the outcome was drastically different from a reasonable expectation for a $50 million swap.

In all three incidents, a critical element was missing: a trusted, on-chain rule governing the resulting state, defined independently of the transaction builder and enforced during execution. For the Bybit incident, such a rule would have prevented the Safe implementation contract from being altered. A BadgerDAO user could have implemented a rule restricting new token approvals to only officially published Badger contracts. The Aave user, ideally, would have defined a minimum acceptable output for the swap, calculated and enforced independently of the quote provided by the Aave interface. Critically, Ethereum’s current architecture lacks a general, native mechanism for on-chain code to thoroughly inspect the comprehensive set of net state changes and events generated by a transaction after its execution.

The Limitations of a Signature: What It Doesn’t Control

A digital signature on Ethereum primarily commits to the action requested by the user, encompassing the target contract, the value transferred, and the calldata. However, the Ethereum Virtual Machine (EVM) executes this call against the specific contract code and blockchain state that exists when the transaction is processed by a miner or validator. This state can — and often does — change 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 diverge significantly from initial expectations.

For example, a target contract might employ a proxy whose underlying implementation contract changes before your transaction executes. This means the actual code that runs could be different from what was inspected at the time of signing. Furthermore, transaction ordering (or reordering by block builders) can dramatically alter the state encountered by a user’s call. A classic example is a sandwich attack, where malicious actors manipulate a decentralized exchange (DEX) pool’s price immediately before and after a user’s swap executes, without altering the user’s signed transaction itself. The diagram below visually illustrates how the signed request, code, and state collaboratively determine the ultimate outcome of an Ethereum transaction, highlighting points of potential divergence.

[Diagram representing the flow: Signed Request + Current Code + Current State -> Outcome]
(Imagine a diagram here showing "Signed Request" leading to "EVM Execution" which interacts with "Current Code" and "Current State," ultimately producing "Outcome." Arrows from "Current Code" and "Current State" to "Outcome" could be labeled "Can Change unpredictably.")

Current Defenses and Their Inherent Shortcomings

The Ethereum ecosystem has developed several defensive mechanisms to mitigate these risks, but each has its limitations:

1. Clear Signing: This technique aims to make transaction details human-readable, translating complex calldata into understandable actions (e.g., "Approve 100 USDC to Uniswap"). It relies on accurate decoding and the user’s ability to discern if the presented action deviates from their intent. However, Clear Signing is only as effective as the frontend’s integrity and the user’s vigilance. It cannot prevent an outcome mismatch if the signed action itself, under specific on-chain conditions, leads to an undesirable result.

2. Transaction Simulation: Wallets and dApps often simulate a transaction’s effects using a snapshot of the blockchain state. While helpful for predicting outcomes, simulations are not guarantees. The actual chain state can change before the transaction is included in a block, and crucially, the transaction signed by the user might differ from the one simulated if malware or a compromised interface intervenes. The Radiant Capital incident serves as a stark reminder: both the wallet interface and its simulation showed the intended transaction, yet malware on the signers’ machines surreptitiously substituted a malicious payload at the critical signing stage.

3. Contract Checks and Wallet Guards: Protocols and smart wallets often incorporate on-chain logic to enforce specific rules during EVM execution. For instance, Uniswap automatically reverts a swap if the output falls below a predefined amountOutMinimum. Similarly, Safe (formerly Gnosis Safe) utilizes a checkAfterExecution hook, allowing a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined rules for owners or configuration. While valuable, these approaches require defining which state variables to check in advance. They also depend on the target contract exposing relevant functions (e.g., a token’s balanceOf). If a proxy contract doesn’t expose its implementation address via a function, a guard cannot directly read the implementation slot, leaving a potential blind spot. Furthermore, these checks are designed for specific, predefined conditions and cannot inspect the full set of net state changes. A guard might confirm a particular balance is unchanged, but it cannot query the EVM about everything else that changed, allowing unforeseen side effects to go unnoticed.

Introducing Native Transaction Assertions: A Paradigm Shift in Security

Native transaction assertions represent a profound architectural shift, designed to empower on-chain code with the ability to inspect the entire set of net state changes after a transaction’s actions have been executed. An assertion functions as read-only logic that compares the initial and final values of relevant state components against a predefined rule. If this rule is violated, the entire set of transaction actions is automatically reverted, ensuring the user’s intent is respected.

The critical innovation is that this rule is included directly within the transaction and signed alongside its primary actions. This allows it to cover a wide array of potential outcomes: net changes to balances, storage, and code; newly deployed contracts and their code hashes; and even emitted events. Users could mandate a minimum amount received in a swap, cap spending limits, block new token approvals, preserve an account’s control logic, or permit only a specified set of changes. The accompanying diagram illustrates this process, showing how assertions validate the outcome and trigger a full transaction reversion if the rules are not met.

[Diagram showing "Signed Request + Assertion" leading to "EVM Execution" (with "Current Code" and "Current State" input). After "EVM Execution," the "Outcome" is fed into "Assertion Check." If "Assertion Check" fails, it leads to "Revert Transaction." If it passes, "Commit Transaction."]
(Imagine a diagram here similar to the previous one, but with an additional box labeled "Assertion" that influences the outcome, leading to either "Commit" or "Revert.")

A crucial aspect of this design is the source of the rule. A compromised frontend, capable of injecting malicious transaction data, could also theoretically inject a malicious assertion that permits an attack. Therefore, a truly effective rule must originate from an independently approved user intent (e.g., a wallet-generated policy), a standing account-level policy, or protocol logic that cannot be manipulated by a compromised component.

EIP-7906: A Concrete Proposal for Implementation

The design of native transaction assertions necessitates careful consideration of what information the EVM exposes, how assertion code can access it, and where these new opcodes can operate. Potential information includes state changes, events, or both. Access methods could range from enumerating all entries, looking up specific values, or copying entire sets of changes into memory. The opcodes themselves might be restricted to particular transaction types or execution phases, or allowed more broadly within the EVM.

One prominent and actively discussed approach is EIP-7906: Transaction Assertions via State Diff Opcode. This EIP builds upon the "frame transactions" introduced in EIP-8141, which are structured as an ordered sequence of validation and action steps. EIP-7906 proposes adding a read-only POST_TX frame at the very end of this sequence, specifically designed to check the transaction’s outcome. While EIP-8141 is slated for inclusion in the upcoming Hegotá network upgrade, EIP-7906 has advanced to "Considered for Inclusion" status, indicating strong community interest, though its final confirmation for an upgrade is still pending.

Under EIP-7906, the design exposes both state changes and events. State changes are reported as net differences in native ETH balances and storage values, alongside newly deployed contracts and their corresponding code hashes. A storage slot written to multiple times within a transaction will appear as a single entry reflecting its starting and final values. If a slot ultimately reverts to its original value, it will not appear in the diff at all, optimizing for relevance.

To facilitate access to this crucial information, EIP-7906 introduces three new EVM opcodes:

• TXTRACE: This opcode allows for the enumeration of all net state changes and emitted events.
• TXDIFF: This opcode retrieves the starting and final values for specific addresses and storage slots, enabling targeted checks.
• EVENTDATACOPY: This opcode facilitates copying an event’s data into memory for detailed inspection.

Crucially, these opcodes are restricted to operate only within a POST_TX frame, which executes at the conclusion of the transaction as a static call. This "static call" nature ensures that the assertion code can inspect the outcome without inadvertently altering the state itself. If the assertion rule is violated, the entire execution body of the transaction is reverted. However, the transaction still remains in the block with a failed status, and the gas payer is charged for the gas consumed. This mechanism is vital to prevent attackers from exploiting the system by submitting deliberately failing transactions to block builders for free, which could lead to denial-of-service attacks.

The Imperative of Requiring Assertions

A key challenge for the widespread effectiveness of EIP-7906 is that it does not inherently mandate the inclusion of an assertion in every transaction. This means that, without additional safeguards, whoever constructs the transaction could simply omit the assertion, circumventing the intended security benefits.

For a user’s own transactions, the responsibility falls on the wallet software to ensure that every frame transaction it constructs includes the necessary assertion. This assertion could be derived from a pre-run simulation by the wallet, or it could be based on a standing security policy that the user has configured to apply to all their transactions.

For protocols seeking to enhance their security, a protected function would need to verify that an incoming call originates from a frame transaction that contains the exact, required assertion. Such a function would reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach would necessitate that callers and integrating dApps adopt compatible frame transactions. A significant consideration here is that already deployed, immutable smart contracts would not be able to retroactively add this assertion-checking mechanism without a full contract upgrade or migration.

Broader Implications and Future Use Cases

Beyond the immediate security benefits for individual users and protocols, native transaction assertions hold the potential to unlock a range of other powerful use cases:

• Strengthening Delegation: When users delegate authority to an agent (e.g., a smart contract wallet managing funds), they can already set limits on which contracts the agent can interact with, how much it can spend, or how long its permissions last. Assertions could add an additional layer of control by enforcing rules on the outcome of each delegated transaction, ensuring that both the agent’s actions and their results align with the delegator’s intent.
• Protocol-Defined Safety: A protocol could define a universal safety rule, requiring the same outcome-based check for every caller utilizing a frame transaction. This could be particularly impactful in solver-based execution models (common in MEV-resistant designs), where the protocol could specify the required final state (e.g., minimum output from a swap) while granting the solver flexibility in choosing the optimal execution path. It’s important to note, however, that this guarantee would typically apply only within a single transaction on a single network, not across multiple chains.
• Workflow Guarantees: Assertions could verify that complex multi-step workflows reach their intended final state, ensuring that unused tokens are returned to the user, and any remaining, unnecessary token approvals are revoked, reducing residual risk.

A Call to Action for the Ethereum Community

The development and refinement of native transaction assertions are ongoing, forming a critical component of the Ethereum Foundation’s ambitious Trillion Dollar Security initiative. Launched in May 2025 (as per internal roadmap dates), this initiative underscores Ethereum’s commitment to safeguarding the vast and growing value locked within its ecosystem, which currently boasts a Total Value Locked (TVL) in decentralized finance (DeFi) estimated to be tens of billions of dollars, and significantly more when considering the broader market capitalization of Ethereum and its associated tokens.

The success of these security enhancements hinges on collaborative input from the diverse Ethereum community. The Foundation is actively seeking engagement from wallet developers, protocol teams, and security researchers who would be the primary beneficiaries and implementers of these features. Interested parties are encouraged to reach out to [email protected] to explore use cases, contribute to the research, and help shape the final design. Furthermore, the EIP-7906 discussion thread on ethereum-magicians.org provides a public forum for technical discourse and feedback.

As Ethereum continues its evolution, initiatives like native transaction assertions are paramount to fostering a more secure, predictable, and trustworthy environment for all participants, paving the way for mainstream adoption and further innovation in decentralized applications. The journey to a truly "Trillion Dollar Secure" Ethereum is a collective effort, and the current momentum indicates a strong commitment to addressing these foundational security challenges head-on. More information on risk controls and priority work can be found at trilliondollarsecurity.org.