Ethereum Foundation Explores Native Transaction Assertions to Bolster User Security and Transaction Certainty

The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as a user experience risk and is exploring native transaction assertions as a next step to enforce a transaction’s final outcome, alongside Clear Signing. This pivotal development aims to address critical vulnerabilities that have led to significant financial losses for users within the burgeoning decentralized finance (DeFi) ecosystem, representing a proactive step towards securing the vast economic value currently transacted and stored on the Ethereum blockchain.

The core problem stems from a fundamental characteristic of how Ethereum transactions are currently processed: while a signature irrevocably commits a user to a specific request, the ultimate outcome of that request is contingent upon the smart contract code and the blockchain state at the precise moment of execution. This disjunction between user intent at the signing stage and the actual transaction result has created fertile ground for exploits, leading to scenarios where validly signed transactions produce unintended and often catastrophic financial consequences. Users have, regrettably, lost substantial sums either by approving actions different from what they believed they were authorizing (an "intent mismatch") or by executing intended requests that, due to dynamic on-chain conditions, yielded undesirable results (an "outcome mismatch").

The Evolving Threat Landscape: Why Transactions Go Wrong

The issue of mismatched intent or outcome is not theoretical; it has been painfully demonstrated through high-profile incidents across the Ethereum ecosystem. These cases underscore the urgent need for enhanced security mechanisms that can validate not just the request, but the result.

One prevalent form of intent mismatch occurs when a compromised frontend or malicious actor manipulates the transaction payload presented to a user. The user believes they are signing one action, but the underlying calldata represents something entirely different. A notable example is the Bybit incident, where attackers reportedly compromised a frontend to trick users into signing transactions that replaced the implementation contract of a Safe (formerly Gnosis Safe) multisig wallet. While specific financial figures for Bybit’s incident were not publicly disclosed as part of a confirmed hack but rather a "security integrity" check, such an exploit could grant attackers complete control over substantial assets managed by the Safe. Similarly, in the December 2021 BadgerDAO attack, a front-end compromise led users to inadvertently grant attackers permission to spend their deposited tokens. This resulted in a staggering loss of approximately $120 million in various cryptocurrencies, including wrapped Bitcoin (wBTC) and Ethereum. In both instances, users signed transactions believing they were interacting with legitimate protocol functions, only for their signatures to authorize malicious operations.

The other critical scenario is an outcome mismatch, where the user signs the exact request they intended, but dynamic on-chain conditions or insufficient safeguards lead to an undesirable financial result. The Aave and CoW collateral swap incident serves as a stark illustration. A user initiated a swap of approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was exceptionally thin for a trade of that magnitude. Exacerbating the problem, CoW Swap’s gas ceiling mechanisms rejected more complex, potentially better-priced quotes during verification. This left a single, highly unfavorable quote for roughly 329 aEthAAVE, valued at approximately $36,000 – a minuscule fraction of the initial $50.4 million. Despite the interface displaying a glaring 99.9% price impact warning and requiring explicit user confirmation of potential total loss, the user proceeded with the transaction. This outcome, though "technically" what was signed, fundamentally conflicted with the user’s economic goal.

In each of these incidents, a critical element was missing: a trusted, on-chain rule capable of inspecting and enforcing the final state changes resulting from the transaction, independently of the transaction builder or even the user’s initial interaction. For Bybit, such a rule could 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, an assertion could have specified a minimum acceptable output for the swap, reverting the transaction if this threshold was not met, regardless of frontend warnings or solver choices. The current Ethereum Virtual Machine (EVM) lacks a general, native mechanism for on-chain code to comprehensively inspect the full suite of net state changes and events produced by a transaction, which is precisely the gap native transaction assertions aim to fill.

Limitations of Current Security Measures

The Ethereum ecosystem has developed several layers of defense against these risks, but each has inherent limitations that prevent comprehensive protection against intent and outcome mismatches.

• Clear Signing: This defense aims to present users with a human-readable interpretation of the calldata they are about to sign, explaining the action being requested. While crucial for transparency, Clear Signing relies on accurate decoding and the user’s ability to discern if the decoded action deviates from their actual intent. It’s a significant improvement over opaque hexadecimal data but can still be circumvented by sophisticated malware or if the user simply misunderstands the decoded information or trusts a compromised interface.

• Transaction Simulation: Wallets and security tools often simulate a transaction’s effects using a snapshot of the blockchain state. This provides a predictive view of the outcome. However, simulations are not guarantees. The chain state can change between the simulation and the transaction’s inclusion in a block, leading to different results. Furthermore, and more critically, the transaction signed by the user can differ from the one simulated if malware intercepts and alters the payload between the user’s approval and the final signing, as tragically demonstrated in the Radiant Capital incident. In this case, both the wallet interface and simulation showed the correct transaction, but malicious software on the signers’ machines swapped in a harmful payload at the last moment, bypassing the intended checks.

  

• Contract Checks and Wallet Guards: These mechanisms enforce specific rules during EVM execution. For example, decentralized exchanges like Uniswap often include amountOutMinimum parameters that revert a swap if the output falls below a user-defined threshold. Smart contract wallets, such as Safe, offer checkAfterExecution hooks, allowing a "guard" contract to inspect the account’s state post-execution and revert transactions violating predefined rules. While effective for specific, pre-programmed checks, these approaches require defining which state changes to monitor in advance. They also depend on target contracts exposing relevant functions to read their state. A token’s balanceOf function makes balance checks straightforward, but a proxy contract might not expose its implementation address directly, preventing a guard from reading a critical storage slot. Crucially, these existing checks cannot inspect the full set of net state changes. A guard can verify a particular balance remains unchanged, but it cannot ask the EVM what else changed, leaving unnoticed any unintended side effects beyond its programmed scope.

Native Transaction Assertions: A Paradigm Shift in On-Chain Security

Native transaction assertions represent a significant leap forward by empowering on-chain code to inspect the entire set of net state changes and emitted events after a transaction’s actions have run but before its finalization. An assertion functions as a read-only logical gate: it compares the blockchain state before the transaction to the state after its execution against a predefined rule. If this rule is violated, the transaction’s actions are automatically reverted, effectively preventing undesirable outcomes from being written to the blockchain.

The assertion rule itself is embedded within the transaction and signed by the user alongside the transaction’s primary actions. This ensures that the user’s intent regarding the outcome is cryptographically bound to the transaction. These rules can be highly versatile, capable of covering:

• Net changes to native ETH balances and ERC-20 token balances.
• Modifications to contract storage.
• Deployment of new contracts or changes to existing contract code.
• Specific events emitted during execution.

This flexibility allows for powerful user-defined or protocol-defined safeguards. Users could enforce a minimum amount received in a swap, cap spending limits, block new token approvals from untrusted entities, preserve an account’s critical control logic, or allow only a specified, whitelisted set of changes. The critical innovation is that the assertion inspects the actual result of the transaction against these rules, reverting it if the outcome deviates from the user’s or protocol’s expectations.

The integrity of the assertion rule is paramount. 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, such as the user’s secure wallet (based on their established policies or a simulation they trust), or from immutable protocol logic that cannot be manipulated by a front-end compromise. This independent validation source is key to making assertions a robust defense.

EIP-7906: A Concrete Proposal for State Diff Opcode

The Ethereum Foundation is actively developing solutions, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate. This EIP builds upon the foundation laid by EIP-8141, which introduces "frame transactions" – a new transaction type designed to contain an ordered sequence of validation and action steps. EIP-8141 is currently scheduled for inclusion in the upcoming Hegotác network upgrade, indicating strong momentum for these foundational changes. EIP-7906, which extends EIP-8141 by adding the assertion capability, has advanced to "Considered for Inclusion" status.

EIP-7906 introduces a read-only POST_TX frame that executes at the very end of a frame transaction. This frame is specifically designed to inspect the transaction’s outcome without introducing new state changes itself (it functions as a static call). The design exposes comprehensive information:

• State Changes: Reported as net differences in native ETH balances and storage. For storage, only slots whose values actually changed are reported, showing their starting and final values. If a slot is written multiple times but ends with its original value, it does not appear in the diff. This focus on net differences is crucial for efficiency and clarity.
• Events: Details of all events emitted during the transaction.
• Newly Deployed Contracts: Information on any new contracts deployed and their respective code hashes.

To access this information, EIP-7906 proposes three new EVM opcodes:

• TXTRACE: Allows enumeration of net state changes and events, enabling programmatic iteration through the transaction’s full impact.
• TXDIFF: Provides a direct lookup mechanism to retrieve starting and final values for specific addresses and storage slots, facilitating targeted checks.
• EVENTDATACOPY: Enables copying an event’s data into memory for detailed inspection.

These opcodes are deliberately restricted to function only within the POST_TX frame. This ensures that assertions are solely for verification and cannot be exploited to maliciously alter state. If an assertion rule fails within the POST_TX frame, the entire execution body of the transaction reverts. However, the transaction itself remains in the block with a failed status, and the gas payer is still charged for the consumed gas. This crucial design choice prevents attackers from repeatedly submitting deliberately failing transactions to force builders to perform expensive computations for free, maintaining network integrity.

Implementation Challenges and the Mandate for Wallets

While powerful, EIP-7906, as currently designed, does not require transactions to include an assertion. This means that a malicious or negligent transaction builder could simply omit the assertion, leaving the user unprotected. This highlights a critical implementation challenge and a clear mandate for ecosystem participants:

• Wallet Responsibility: For a user’s own transactions, the wallet software must become the primary guardian. It must ensure that every frame transaction it constructs includes the necessary assertion. This assertion could be generated dynamically based on a simulation run by the wallet, or it could be derived from a standing security policy the user has configured within their wallet that applies to all relevant transactions. Wallets will need to evolve to support assertion generation and signing.

• Protocol Integration: Protocols that wish to enforce specific safety checks for interactions with their contracts will need to verify that incoming calls originate from frame transactions containing the exact, required assertion. This means a protected function within a smart contract would reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach, however, faces a challenge with already deployed, immutable contracts, which cannot be updated to add this verification logic. New contract deployments or upgradeable proxies would be necessary for existing protocols to adopt this.

Broader Impact and Future Applications

Beyond the immediate and profound security benefits for individual users and DeFi protocols, native transaction assertions could unlock a range of innovative use cases, further enhancing the utility and trustworthiness of the Ethereum blockchain:

• Strengthening Delegation: When users delegate authority to an agent (e.g., a smart contract or another wallet) to act on their behalf, assertions can provide granular control over the outcome of the agent’s actions. Beyond limiting which contracts an agent can interact with, how much it can spend, or how long its permissions last, assertions can enforce specific post-execution state conditions for each transaction. This means users can constrain both what the agent may do and what its actions must produce.

• Protocol-Defined Safety Guarantees: Protocols could define universal safety rules that apply to every caller using a frame transaction. For instance, in complex solver-based execution models (common in MEV-resistant trading), a protocol could specify a required minimum output or a maximum price impact, while allowing solvers the freedom to choose the most efficient execution route. The assertion would guarantee the desired outcome, irrespective of the solver’s strategy. It’s important to note, however, that this guarantee would apply only within a single transaction on a single network, not across multiple chains.

• Workflow Verification: Assertions could be used to ensure that multi-step workflows reach their intended final state. This could include verifying that unused tokens are returned to the user, that temporary token approvals are revoked, or that specific state variables are updated correctly across a sequence of operations. This adds a layer of robustness to complex dApp interactions.

Shaping the Future of Ethereum Security

The development of native transaction assertions is an integral part of the Ethereum Foundation’s Trillion Dollar Security initiative, a comprehensive effort aimed at securing the immense economic value — currently trillions of dollars in market capitalization and Total Value Locked (TVL) — that resides on the Ethereum network. This initiative acknowledges that as Ethereum scales and becomes the backbone for global finance, its security infrastructure must evolve to meet the highest standards.

The design of these critical features is still in active development, and community input is highly valued. The Ethereum Foundation actively encourages wallet developers, protocol teams, security researchers, and other stakeholders to engage in the ongoing discussions. Those interested in exploring specific use cases, providing feedback, or contributing to the research can reach out via email at [email protected] or join the EIP-7906 discussion thread on Ethereum Magicians (ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130).

By collaboratively refining and implementing native transaction assertions, the Ethereum community can significantly enhance user protection, foster greater trust in decentralized applications, and solidify Ethereum’s position as a secure and reliable platform for the future of finance and beyond. This initiative represents a clear commitment to proactively addressing the sophisticated security challenges of a rapidly expanding decentralized ecosystem.