How native transaction assertions could enforce a transaction’s final outcome

This pivotal development signals a concerted effort by the Ethereum Foundation to fortify the security posture of the world’s leading smart contract platform, which now commands a market capitalization in the trillions. The initiative aims to address fundamental vulnerabilities that have led to significant financial losses for users and protocols alike, primarily stemming from the inherent disconnect between a user’s signed transaction request and its eventual on-chain outcome. This article delves into the complexities of these risks, the limitations of current defenses, and how native transaction assertions, particularly through proposals like EIP-7906, are poised to revolutionize user protection on Ethereum.

The Critical Flaw: Transaction Uncertainty on Ethereum

At its core, Ethereum’s operational model executes precisely what a user authorizes, without an intrinsic mechanism to verify if the resulting state changes align with the user’s initial intent. A digital signature on the Ethereum blockchain serves as an irrevocable commitment to a specific transaction request, encompassing parameters such as the target contract, value, and calldata. However, the ultimate outcome of this request is contingent upon the contract code and the prevailing state of the blockchain at the moment of execution. This critical dependency means that the signed request, while valid, can produce an unexpected or undesirable result, leading to substantial financial repercussions for users.

This vulnerability manifests in two primary forms: an intent mismatch and an outcome mismatch. An intent mismatch occurs when a user signs a transaction believing they are authorizing one action, but the actual underlying request is entirely different, often maliciously crafted. This usually happens due to compromised interfaces or sophisticated malware. Conversely, an outcome mismatch arises when the user signs the intended request, but the dynamic nature of the blockchain, coupled with the transaction’s inherent limits or the state it interacts with, still permits a final state that conflicts with the user’s economic goals or predefined safety policies.

Case Studies: Real-World Impacts of Transaction Risks

Numerous high-profile incidents underscore the urgent need for enhanced transaction certainty. These events highlight how the absence of robust on-chain outcome verification has been exploited or led to significant user losses.

Intent Mismatch: The Bybit and BadgerDAO Breaches

In instances of intent mismatch, attackers leverage compromised frontends or malware to manipulate the transaction data presented to the user. The user believes they are approving a benign action, but their signature unwittingly authorizes a malicious one.

• The Bybit Incident (Reported May 2025): While specific details remain under wraps due to ongoing security investigations, reports indicate a scenario where a compromised frontend presented Bybit signers with a seemingly innocuous transaction. Unbeknownst to them, the signed request authorized the replacement of a critical Safe (formerly Gnosis Safe) implementation contract. Had this gone undetected, it could have granted attackers control over vast amounts of assets managed by the Safe, illustrating a direct attack on a protocol’s core logic via manipulated user intent. A robust transaction assertion here would have required the Safe’s implementation address to remain unchanged after the transaction, reverting any attempt to alter it.

• The BadgerDAO Attack (December 2021): This devastating attack resulted in approximately $120 million in user funds being drained. Attackers injected malicious scripts into the BadgerDAO frontend, causing legitimate users to unknowingly approve token spending permissions to the attacker’s wallet. Users believed they were interacting with the BadgerDAO protocol as usual, but their signatures granted sweeping approvals that were subsequently exploited. A native transaction assertion could have been configured by users or the protocol itself to block any new token approvals unless they were directed to a predefined whitelist of official BadgerDAO contracts, thereby preventing the malicious approvals from taking effect.

Outcome Mismatch: The Aave and CoW Collateral Swap

An outcome mismatch demonstrates that even a correctly signed transaction, with the user fully aware of the requested action, can yield an economically disastrous result if the prevailing on-chain conditions are unfavorable or if safety parameters are insufficient.

• The Aave and CoW Collateral Swap (May 2023): In a stark illustration of outcome mismatch, a user initiated a swap on CoW Swap, intending to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was exceptionally thin for a transaction of that magnitude. Exacerbating the issue, CoW Swap’s gas ceiling mechanisms rejected more complex, potentially better-priced quotes during verification, leaving only a highly unfavorable option that offered roughly 329 aEthAAVE. Despite the interface displaying a stark 99.9% price impact warning and requiring explicit user confirmation of potential total loss, the user proceeded with the signature. The transaction executed, resulting in the user receiving tokens valued at a mere $36,000 – a catastrophic loss of over $50 million. In this scenario, a native transaction assertion could have been implemented by the user, specifying a minimum acceptable output for aEthAAVE, independently verified against reliable price feeds rather than solely relying on the trading interface’s quote. If the transaction failed to meet this minimum, it would have automatically reverted, protecting the user from such extreme slippage.

These incidents collectively highlight a critical gap: Ethereum currently lacks a general, on-chain mechanism for code to comprehensively inspect and validate the entire set of net state changes and events produced by a transaction before it is finalized.

Current Safeguards and Their Limitations

The Ethereum ecosystem has developed several layers of defense against transaction risks, but each possesses inherent limitations that native transaction assertions aim to overcome.

• Clear Signing: This defense mechanism focuses on improving transparency by translating complex calldata into human-readable actions, allowing users to understand precisely what their signature authorizes. It relies heavily on accurate decoding capabilities within wallets and the user’s vigilance in identifying discrepancies. However, clear signing primarily addresses the "intent mismatch" by clarifying the input to the transaction. It cannot predict or guarantee the outcome in a dynamic environment where contract code might change, or market conditions fluctuate drastically between signing and execution. Furthermore, sophisticated malware can still present a "clear" but malicious request.

• Transaction Simulation: Wallets and dApps often employ pre-transaction simulations, running the proposed transaction against a snapshot of the blockchain state to predict its effects. This offers a valuable foresight into potential outcomes, including balance changes and gas costs. Nevertheless, simulations are inherently susceptible to changes in chain state that occur after the simulation and before the transaction’s inclusion in a block. A malicious actor could exploit this time window through a sandwich attack, or a sudden market shift could invalidate the simulation’s predictions. Crucially, as seen in the Radiant Capital incident (October 2023), malware on a user’s machine can substitute a malicious payload at the very moment of signing, even if the wallet interface and initial simulation showed the intended transaction. The simulation itself does not bind the final transaction outcome.

• Contract Checks and Wallet Guards: These are on-chain mechanisms embedded within smart contracts or smart wallets (like Safe). For example, Uniswap swaps revert if the output falls below a user-defined amountOutMinimum threshold. Safe’s checkAfterExecution hook allows a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined rules for owners or configurations. While powerful, these checks are limited by two factors:

  1. Pre-defined State Inspection: They require developers to anticipate which specific state variables need checking in advance. If an unexpected state change occurs that isn’t explicitly checked, it can go unnoticed.
  2. Interface Dependency: To read another contract’s storage, they often depend on that contract exposing public functions. For instance, a token’s balanceOf function makes balance checks straightforward. However, if a proxy contract doesn’t expose its implementation address through a function, a guard cannot directly read the implementation slot, leaving critical changes unchecked.
     These existing checks cannot inspect the full set of net state changes produced by a transaction. A guard can confirm a specific balance remains unchanged, but it cannot query the EVM about everything else that changed across various contracts and storage slots.

Introducing Native Transaction Assertions: A Paradigm Shift

Native transaction assertions represent a fundamental shift in how Ethereum transactions can be secured. This proposed mechanism allows on-chain code to inspect the entire set of net state changes after a transaction’s primary actions have been executed. An assertion functions as a read-only piece of logic that compares the blockchain’s state before and after the transaction, enforcing a predefined rule. If this rule is violated, the entire transaction (including its primary actions) is automatically reverted.

Crucially, the assertion itself is included in the transaction and cryptographically signed alongside the primary actions. This ensures that the user’s explicit intent regarding the outcome is committed on-chain. These rules can be highly granular and comprehensive, 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 hashes.
• Emitted events.
• Requirements for a minimum amount received in a swap.
• Caps on spending or maximum allowances granted.
• Blocking new token approvals or ensuring only whitelisted approvals are made.
• Preserving an account’s control logic (e.g., preventing changes to a Safe’s owner structure).
• Allowing only a specified, limited set of changes, reverting anything else.

The power of transaction assertions lies in their ability to define a trusted rule over the resulting state, independently of the transaction builder (which could be compromised) and enforced directly during EVM execution. For example, in the Bybit incident, an assertion would have mandated that the Safe’s implementation contract address remain unchanged. In the BadgerDAO attack, an assertion could have permitted new token approvals only for a specific set of known BadgerDAO contracts. For the Aave user, an assertion would have set a minimum acceptable output for the swap, reverting the transaction if the received amount fell below this threshold.

A critical design consideration is the source of the assertion rule. For assertions to be effective against malicious actors, the rule must originate from an independently approved user intent, a standing account policy (e.g., defined in a smart wallet), or protocol logic that cannot be manipulated by a compromised frontend or transaction builder.

EIP-7906: A Concrete Proposal for Implementation

One leading proposal for implementing native transaction assertions is EIP-7906 (Transaction Assertions via State Diff Opcode), which builds upon the framework introduced by EIP-8141 (Frame Transactions).

Frame Transactions (EIP-8141)

EIP-8141 introduces a new transaction type, known as "frame transactions." These transactions allow for an ordered sequence of validation and action steps within a single transaction. This structured approach is fundamental for EIP-7906, as it provides a dedicated phase for outcome verification. EIP-8141 is a significant proposal, currently scheduled for inclusion in the upcoming Hegotá network upgrade, indicating strong developer consensus on its utility.

EIP-7906: The Assertion Mechanism

EIP-7906 extends EIP-8141 by adding a special, read-only POST_TX frame at the very end of the transaction execution flow. This POST_TX frame is where the assertion logic resides and executes, inspecting the cumulative effects of all preceding actions. The proposal has advanced to "Considered for Inclusion," signifying its importance to the core development roadmap, though its final confirmation for an upgrade is still pending.

Key features of EIP-7906:

• Comprehensive State & Event Exposure: The design exposes both net state changes and emitted events. State changes are reported as net differences in native ETH balances and storage. This means if a storage slot is written to five times but ultimately reverts to its original value, it will not appear in the reported changes, providing a clean, final-state-oriented view. Newly deployed contracts and their code hashes are also reported.
• New EVM Opcodes: Three new Ethereum Virtual Machine (EVM) instructions (opcodes) are introduced to facilitate access to this information:
  • TXTRACE: This opcode enumerates all net state changes and events that occurred during the transaction. It allows assertion logic to iterate through all modifications.
  • TXDIFF: This opcode enables direct retrieval of the starting and final values for specific addresses and storage slots, allowing for targeted checks.
  • EVENTDATACOPY: This opcode allows assertion code to copy the data associated with an emitted event into memory for inspection.
• Restricted Execution Context: These new opcodes are designed to function only within the POST_TX frame. This frame runs as a "static call," meaning it can read state but cannot modify it. This read-only restriction is crucial; it ensures that the assertion logic itself cannot introduce new vulnerabilities or unintended side effects, acting purely as a validator.
• Reversion Mechanism: If the assertion rule within the POST_TX frame fails (i.e., the outcome does not match the desired state), the entire preceding 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 failure. This mechanism is vital to prevent denial-of-service attacks, where malicious actors could flood the network with deliberately failing transactions if they incurred no cost.

The Imperative of Required Assertions

While EIP-7906 provides the technical capability for transaction assertions, its current design does not mandate their inclusion in transactions. This presents a critical challenge: if assertions are optional, a compromised transaction builder can simply omit them, circumventing the intended protection. For native transaction assertions to truly enhance security, they must be required.

Addressing the "Optional" Challenge:

• Wallet Responsibility: For user-initiated transactions, the wallet plays a crucial role. It must be engineered to ensure that every frame transaction it constructs includes the necessary assertions. These rules could be dynamically generated based on a pre-transaction simulation run by the wallet, or they could stem from standing security policies configured by the user, applying universally to all their transactions.
• Protocol Enforcement: Protocols that handle sensitive operations would need to adapt their contracts. A protected function within a protocol would have to verify that any incoming call originates from a frame transaction that contains the exact required assertion. It would need to explicitly reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach, however, faces challenges:
  • Compatibility: All callers and integrations would need to adopt compatible frame transactions and assertions, necessitating a coordinated ecosystem-wide upgrade.
  • Immutability: Already deployed, immutable smart contracts cannot retroactively add this assertion-checking logic, meaning a significant portion of existing DeFi infrastructure might not immediately benefit without complex upgrade paths or wrapper contracts.

The long-term vision involves a future where assertions are not merely a feature but a fundamental requirement for sensitive on-chain interactions, establishing a new baseline for trust and security.

Broader Implications and Future Use Cases

Beyond bolstering security against malicious attacks and unintended outcomes, native transaction assertions unlock a spectrum of advanced use cases that could reshape how users interact with and protocols operate on Ethereum.

• Strengthened Delegation: Delegation is a powerful primitive in Web3, allowing users to grant agents (e.g., bots, smart contracts, or even other users) limited permissions to act on their behalf. Current delegation models often focus on limiting what an agent can do (e.g., which contracts it can call, how much it can spend, the duration of permissions). Transaction assertions could add an unprecedented layer of control by constraining what the agent’s actions produce. For example, a user could delegate a trading bot with the assertion that any swap executed must result in a minimum profit margin or that the portfolio balance must not drop below a certain threshold.
• Standardized Protocol Safety Checks: Protocols could define their own universal safety rules using assertions. Every caller interacting with a protocol’s critical functions via a frame transaction could be required to include a specific assertion that validates the outcome according to the protocol’s safety standards. This ensures consistent security across all integrations, regardless of the user interface or intermediary involved.
• Flexible Solver Execution in DeFi: In decentralized exchange (DEX) models that rely on solvers (e.g., CoW Swap), users often sign orders that specify desired outcomes but leave the exact execution path (the "route") to the solver. Assertions could allow users or protocols to specify a precise required outcome (e.g., minimum output tokens, maximum slippage) while granting solvers maximum flexibility to find the most efficient route. This guarantees the user’s economic goal is met without dictating the execution details, optimizing for efficiency and best price. This guarantee, however, would currently be limited to a single transaction on a single network.
• Comprehensive Workflow Verification: Complex multi-step decentralized applications (dApps) often involve a sequence of transactions. Assertions could be used to verify that an entire workflow reaches its intended final state. This could include ensuring that unused tokens are returned to the user, any temporary token approvals are revoked, or specific contract states are achieved as part of a larger process. This capability significantly enhances the integrity and reliability of intricate dApp interactions.

Background Context: The Trillion Dollar Security Initiative

The "Trillion Dollar Security Initiative" by the Ethereum Foundation is not merely a catchy name; it reflects the immense value now secured by the Ethereum blockchain. With a total value locked (TVL) in DeFi often exceeding hundreds of billions of dollars, and the overall market capitalization of Ethereum and ERC-20 tokens reaching into the trillions, the stakes for security are higher than ever. The initiative was launched to proactively identify and mitigate systemic risks that could undermine user trust and financial stability within this burgeoning ecosystem. It encompasses a broad range of research and development efforts, from improving cryptography and client diversity to enhancing user experience and transaction safety. The focus on "blind signing" and "transaction uncertainty" directly addresses some of the most persistent and economically damaging attack vectors observed in recent years. This initiative signals a mature understanding that while the underlying blockchain is robust, the points of interaction – how users sign and execute transactions – remain critical areas for innovation and fortification.

A Collaborative Future: Shaping Ethereum’s Security Evolution

The development of native transaction assertions is an ongoing, collaborative endeavor. Solutions are still being designed, refined, and debated as part of the Ethereum Foundation’s overarching Trillion Dollar Security initiative. The Foundation actively seeks input and engagement from the broader Ethereum community, particularly from wallet developers, protocol teams, and security researchers who will be the primary users and beneficiaries of these advancements.

Community involvement is crucial to ensure that the proposed designs are practical, comprehensive, and address real-world pain points. Stakeholders are encouraged to contribute to the research, explore specific use cases, and provide feedback on the technical specifications. This open development model, characteristic of Ethereum, is essential for building robust and widely adopted security primitives.

For those interested in shaping the future of Ethereum’s security, the Ethereum Foundation encourages direct engagement. You can reach out to the Trillion Dollar Security initiative team at [email protected] to discuss use cases and contribute to the research. Additionally, active participation in the EIP-7906 discussion thread on Ethereum Magicians (ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130) is a vital way to influence the design and implementation of this critical EIP.

Further details on risk controls and priority work within this monumental initiative can be found at trilliondollarsecurity.org, underscoring the Foundation’s commitment to safeguarding the decentralized future. The journey towards a more secure and predictable Ethereum ecosystem is a collective one, and native transaction assertions mark a significant stride in that direction.