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

The Ethereum Foundation, a leading proponent of the Ethereum blockchain, has intensified its focus on user security through its ambitious "Trillion Dollar Security initiative." This critical program aims to fortify the blockchain’s defenses against emergent threats, with a particular emphasis on mitigating risks associated with "blind signing" and "transaction uncertainty." The latest development in this ongoing effort involves the exploration of native transaction assertions, a groundbreaking mechanism designed to programmatically enforce the intended final outcome of a transaction directly on-chain. This initiative complements existing and forthcoming safeguards, such as "Clear Signing," promising a more robust and predictable transactional environment for all Ethereum users.

This detailed exploration delves into the inherent vulnerabilities that allow signed transactions to deviate from user expectations, the limitations of current security measures, and the proposed architecture of native transaction assertions. It will also examine the specific design choices underpinning these assertions, spotlighting EIP-7906 (Transaction Assertions via State Diff Opcode) as a promising candidate for implementation. The goal is to provide a comprehensive understanding of how these advancements could fundamentally reshape user security and trust within the Ethereum ecosystem, particularly as the network continues to scale and host an increasing volume of high-value digital assets.

The Genesis of a Security Imperative: Trillion Dollar Security Initiative

The "Trillion Dollar Security initiative," launched by the Ethereum Foundation, is a strategic response to the escalating sophistication of attacks and the growing value locked within the Ethereum network. With billions of dollars at stake, ensuring the integrity and predictability of transactions has become paramount. The initiative recognizes that while Ethereum’s underlying cryptography is robust, the interaction layer between users and the blockchain — often through third-party applications and wallets — introduces significant vectors for exploitation. Blind signing, where users approve transactions without fully understanding their underlying data, and transaction uncertainty, where the outcome can change due to external factors between signing and execution, represent critical user experience risks that undermine confidence and lead to substantial financial losses.

The initiative’s overarching goal is to achieve a state where users can interact with the blockchain with confidence, knowing that their signed intentions will be faithfully executed and their assets protected. This requires a multi-faceted approach, combining user-facing improvements like Clear Signing, which aims to provide human-readable transaction summaries, with fundamental protocol enhancements like native transaction assertions. These efforts are not merely reactive but proactive, aiming to build a resilient security framework capable of anticipating and neutralizing future threats as the Ethereum ecosystem evolves.

Understanding the Vulnerability: When Signatures Fail to Guarantee Outcomes

At the core of the problem lies Ethereum’s deterministic execution model: the Ethereum Virtual Machine (EVM) executes precisely what is authorized by a signature, without interpreting user intent or judging the desirability of the outcome. A user’s signature commits to a specific request (target contract, value, calldata), but the ultimate result is contingent upon the contract code and the blockchain’s state at the exact moment of execution. This separation creates a critical vulnerability: users can authorize a transaction believing it will yield a certain result, only for the actual outcome to diverge significantly due to factors outside their immediate control or visibility.

This divergence can manifest in two primary ways:

1. Intent Mismatch: The user believes they are approving one action, but the signed transaction, often manipulated by a compromised interface, requests something entirely different. The signature is cryptographically valid, but the user’s true intention is not reflected in the executed request.
2. Outcome Mismatch: The user approves the intended request, but external factors or unforeseen state changes cause the transaction to produce an undesirable or economically detrimental result. The request itself is correct, but its execution environment leads to an outcome that conflicts with the user’s financial goals or security policies.

These mismatches have historically led to significant financial losses, eroding user trust and highlighting the urgent need for more robust on-chain safeguards that go beyond merely verifying a signature’s authenticity.

Case Studies in Catastrophe: Real-World Examples of Intent and Outcome Mismatches

The theoretical vulnerabilities of intent and outcome mismatches are starkly illustrated by several high-profile incidents that have plagued the Ethereum ecosystem:

The Bybit Incident (Intent Mismatch)

In a notable incident affecting Bybit users and their Safe (formerly Gnosis Safe) wallets, a compromised frontend supplied malicious signing requests. Users, believing they were performing routine operations, inadvertently authorized the replacement of the Safe’s implementation contract. This is a critical security vulnerability, as changing the implementation contract effectively allows an attacker to seize control of all funds managed by that Safe. While specific financial figures for this incident are not widely publicized by Bybit, the potential for catastrophic loss was immense, underscoring how a seemingly legitimate signature could facilitate a complete compromise of assets if the underlying intent was obscured. The incident likely occurred due to a sophisticated phishing or supply chain attack targeting the frontend application, tricking users into signing a transaction that fundamentally altered their wallet’s security architecture.

The BadgerDAO Attack (Intent Mismatch)

In December 2021, the decentralized finance (DeFi) protocol BadgerDAO suffered a devastating attack resulting in losses estimated at over $120 million. The attack vector was a compromised frontend interface that injected malicious code into the legitimate web application. When users interacted with the frontend, they were presented with seemingly normal prompts. However, the malicious code intercepted these interactions, substituting the intended transaction requests with approvals that granted the attacker permission to spend users’ tokens. Specifically, the attacker gained approve permissions on various ERC-20 tokens held by users, allowing them to drain funds. Users signed these malicious approve transactions, believing they were interacting with the legitimate BadgerDAO protocol, demonstrating a severe intent mismatch. The incident highlighted the dangers of relying solely on frontend interfaces for transaction context and the need for independent verification of transaction effects.

The Aave and CoW Collateral Swap (Outcome Mismatch)

In a compelling example of an outcome mismatch, a user attempting a collateral swap between aEthUSDT and aEthAAVE on Aave, facilitated by CoW Swap, experienced a dramatic loss. The user intended to swap approximately $50.4 million worth of aEthUSDT. However, the liquidity for aEthAAVE was extremely thin for a trade of that magnitude. During the settlement process, CoW Swap’s gas ceiling also rejected more complex, potentially better-priced quotes during verification. This left only one verified quote available, offering a mere 329 aEthAAVE – an amount worth approximately $36,000. Despite the interface displaying a stark 99.9% price impact warning and requiring explicit confirmation that the entire value could be lost, the user proceeded with the transaction. This was not an intent mismatch; the user signed the transaction they were shown, but the final outcome was economically disastrous, severely conflicting with their initial goal due to market conditions and protocol limitations.

In all three scenarios, a fundamental safeguard was missing: a trusted, on-chain rule capable of inspecting and validating the resulting state changes after execution, independently of the transaction builder or frontend. For Bybit users, such a rule could have enforced that the Safe implementation contract remain unchanged. For BadgerDAO users, it could have restricted new token approvals only to officially published Badger contracts. For the Aave user, a rule could have set a minimum acceptable output for the swap, reverting the transaction if that threshold wasn’t met. Ethereum’s current architecture lacks a generalized mechanism for on-chain code to natively inspect the full set of net state changes and emitted events produced by a transaction.

What a Signature Does Not Control: The EVM’s Blind Execution

To fully grasp the necessity of transaction assertions, it’s crucial to understand the inherent limitations of an Ethereum signature. A signature cryptographically binds a user to a specific transaction request, which includes:

• Target: The address of the smart contract or external account being interacted with.
• Value: The amount of native Ether (ETH) being sent.
• Calldata: The encoded instructions for the function call on the target contract, including function selector and arguments.

However, a signature does not commit to:

• The exact contract code: If the target is a proxy contract, its underlying implementation can be updated after a transaction is signed but before it’s executed, potentially altering the code that runs.
• The exact state: The EVM executes the call against the blockchain’s current state. This state can change dramatically due to other transactions included in the same block or preceding blocks. For instance, a "sandwich attack" can front-run and back-run a user’s swap, manipulating the pool’s price and causing significant slippage, all without altering the user’s signed transaction.
• The resulting net balance and storage changes: These are the effects of the execution, not part of the signed input.

The diagram below illustrates this crucial distinction: the signed request, when combined with the prevailing code and state at execution time, ultimately determines the outcome. Without a mechanism to assert control over these outcomes, users remain vulnerable.

(Imagine a diagram here similar to the original, showing: "Signed Request" -> "Code & State at Execution" -> "Outcome" with arrows illustrating the flow.)

Current Defenses: A Necessary But Insufficient Shield

The Ethereum ecosystem has developed several layers of defense against transaction-related risks, but each has inherent limitations:

1. Clear Signing: This defense aims to translate complex calldata into human-readable explanations of the intended action. Wallets and interfaces employ decoding techniques to present users with understandable summaries (e.g., "Approve 100 USDC for Uniswap Router"). Its effectiveness hinges on accurate decoding and the user’s ability to recognize discrepancies between the displayed action and their actual intent. However, Clear Signing cannot predict or prevent an outcome mismatch, nor can it detect malicious code hidden within a legitimately decoded contract if the user doesn’t scrutinize the contract address itself.

2. Transaction Simulation: Wallets and third-party services often simulate transactions against a selected chain state to predict their effects before signing. This provides a powerful preview of potential outcomes, including balance changes and gas costs. However, simulations are inherently snapshots in time. The actual chain state can change between the simulation and the transaction’s inclusion in a block, rendering the simulation’s predictions inaccurate. Furthermore, as seen in the Radiant Capital incident (December 2023, where malware on a signer’s machine substituted a malicious payload at signing time despite correct simulation and wallet interface display), simulation cannot protect against malware that alters the transaction after it has been simulated but before it is signed and broadcast.

3. Contract Checks and Wallet Guards: These on-chain mechanisms enforce rules during EVM execution.

   • Uniswap’s amountOutMinimum: A common DeFi safeguard, Uniswap’s router reverts a swap if the received output tokens fall below a specified minimum. This is an effective, albeit narrow, form of outcome assertion.
   • Safe’s checkAfterExecution hook: Multi-signature wallets like Safe allow custom "guards" to inspect the account’s state after a transaction’s execution. These guards can revert a transaction if it violates predefined rules, such as those related to owner management or configuration.

While valuable, these contract-level checks have significant limitations:

• Pre-defined State Checks: They require choosing which specific state variables to check in advance. They cannot dynamically adapt to unforeseen changes.
• Interface Dependence: To read another contract’s storage (e.g., a token’s balanceOf), they depend on that contract exposing public functions. A proxy contract, for example, might not expose its implementation address through a function, preventing a guard from directly inspecting the critical implementation slot.
• Incomplete State Visibility: Crucially, existing on-chain checks cannot inspect the full set of net state changes produced by a transaction. A guard can verify if a particular balance remains unchanged, but it cannot ask the EVM "what else changed?" This means that unintended side effects or manipulations not explicitly covered by the guard’s design can go unnoticed and lead to successful exploits.

These defenses, while essential, operate within a framework that lacks a generalized, native ability for on-chain code to truly understand and react to the complete impact of a transaction.

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

Native transaction assertions represent a fundamental shift in Ethereum’s security paradigm. Rather than merely verifying what was signed or predicting what might happen, assertions allow on-chain code to inspect the entire set of net state changes after a transaction’s actions have run. An assertion functions as a read-only piece of logic that compares the blockchain’s state before and after a transaction’s execution against a predefined rule. If this rule is violated, the entire transaction’s actions are reverted, effectively preventing undesirable outcomes from being finalized on the blockchain.

The power of native transaction assertions lies in their comprehensive scope:

• Broad Coverage: Assertions can cover net changes to native ETH balances, contract storage, deployed code, newly deployed contracts, and even emitted events.
• Flexible Rules: They can enforce a wide array of security policies:
  • Requiring a minimum amount of tokens received in a swap.
  • Capping spending limits for a delegated agent.
  • Blocking new token approvals to unauthorized addresses.
  • Preserving an account’s critical control logic (e.g., preventing a Safe’s implementation change).
  • Allowing only a specified, whitelisted set of changes.

Crucially, the rule itself is included within the transaction and signed alongside its primary actions. This ensures that the user’s intended safety policy is an integral part of their commitment. The diagram below illustrates how assertions would function:

(Imagine a diagram here similar to the original, showing: "Signed Request + Assertion" -> "EVM Execution" -> "State Changes & Events (Outcome)" -> "Assertion Check" -> "Rule Passed: Commit Transaction" or "Rule Failed: Revert Transaction".)

However, the source of the assertion rule is as critical as the check itself. A compromised frontend could, for instance, inject an assertion that permits the attack. Therefore, for assertions to be truly effective, the rule must originate from an independently approved source, such as:

• Direct User Intent: Explicitly defined by the user during the signing process, perhaps through a secure wallet interface.
• Standing Account Policy: A pre-configured, immutable security policy associated with a user’s smart account.
• Protocol Logic: Hardcoded rules within a trusted protocol that cannot be altered by external manipulation.

This independent origination ensures that the assertion acts as a robust, tamper-resistant guardrail against both intent and outcome mismatches.

EIP-7906: A Concrete Proposal for Implementation

The conceptual framework of native transaction assertions is currently being translated into concrete technical proposals, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate. This Ethereum Improvement Proposal builds upon the foundational work of EIP-8141, which defines "frame transactions."

EIP-8141: Frame Transactions
Scheduled for inclusion in the upcoming Hegotά upgrade, 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, providing more structural flexibility and enabling advanced use cases like account abstraction. EIP-7906 leverages this framework by adding a specific "frame" for assertions.

EIP-7906: The POST_TX Frame and New Opcodes
EIP-7906 proposes adding a read-only POST_TX frame at the very end of a frame transaction. This frame is specifically designed to execute assertion logic and check the transaction’s outcome. Its key characteristics include:

• Read-Only Execution: The POST_TX frame runs as a static call, meaning it can inspect the state but cannot modify it. This is crucial for preventing malicious assertions from causing unintended side effects.
• Comprehensive State Exposure: The design exposes both net state changes and emitted events.
  • State Changes: Reported as net differences in native ETH balances and storage slots. If a storage slot is written to multiple times within a transaction, it appears as a single entry reflecting its starting and final values. Importantly, if a slot returns to its original value by the end of the transaction, it does not appear in the diff, simplifying the assertion logic.
  • Deployed Contracts: New contracts deployed and their code hashes are also exposed.
• New EVM Opcodes: Three new EVM instructions (opcodes) are proposed to provide access to this information:
  • TXTRACE: Allows enumeration of all net state changes and events. This enables generalized checks, such as "no new token approvals were granted."
  • TXDIFF: Retrieves the starting and final values for specific addresses and storage slots. This is useful for targeted checks, like "my balance of X token increased by at least Y."
  • EVENTDATACOPY: Copies an event’s data into memory, enabling assertions based on specific event emissions.

Reversion and Gas Costs: If an assertion rule within the POST_TX frame fails, 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 design choice is critical to prevent attackers from exploiting the system by submitting deliberately failing transactions for free, which could be used for denial-of-service attacks or for probing contract vulnerabilities without cost.

EIP-7906 has advanced to "Considered for Inclusion" status within the Ethereum roadmap, signifying its potential importance for a future network upgrade, though its final confirmation is pending further research and community consensus. EIP-8141’s scheduled inclusion in Hegotά provides the necessary architectural foundation.

The Imperative of Enforced Assertions

While EIP-7906 offers a powerful mechanism, it does not inherently require transactions to include an assertion. This leaves a potential gap: whoever constructs the transaction could simply omit the assertion, circumventing the security benefits. Therefore, for native transaction assertions to be truly effective, their inclusion must be enforced at various layers:

1. Wallet-Level Enforcement: For user-initiated transactions, the wallet software plays a crucial role. Wallets must be updated to ensure that every frame transaction they construct includes the necessary assertions. These rules could be derived from a real-time simulation performed by the wallet or from a standing, user-defined security policy that applies to all transactions originating from that wallet. This places the burden of assertion generation and inclusion on the trusted user agent.

2. Protocol-Level Enforcement: Smart contract protocols can mandate the use of assertions for critical functions. A protected function within a protocol could be designed to verify that any incoming call originates from a frame transaction containing a specific, required assertion. It would then reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach would require callers and integrated applications to adopt compatible frame transactions. A key challenge here is that already deployed, immutable contracts cannot be retroactively updated to add such checks, limiting immediate widespread adoption for existing protocols.

The multi-layered enforcement strategy ensures that assertions are not merely an optional feature but a mandatory safeguard where security is paramount, creating a more robust and predictable on-chain environment.

Broader Implications and the Future of Secure Transactions

Beyond the immediate security benefits for individual users and protocols, native transaction assertions unlock a spectrum of advanced use cases that could reshape how interactions occur on Ethereum:

• Strengthening Delegation: When users delegate authority to an agent (e.g., a bot, a specialized wallet, or another smart contract) to act on their behalf, assertions can provide an unprecedented level of granular control. While existing delegation mechanisms might limit which contracts an agent can interact with, how much it can spend, or for how long its permissions last, assertions add a critical layer by constraining the outcome of each transaction. Users could specify, for example, that an agent can only perform swaps that yield at least X amount of a token, or that no new token approvals are granted during the delegation period. This transforms delegation into a more secure and trustworthy process.

• Protocol-Defined Safety Checks: Protocols can leverage assertions to define their own standardized safety checks for every caller utilizing a frame transaction. This ensures a consistent level of security and compliance across all interactions with the protocol. For instance, a lending protocol could assert that a loan repayment transaction always results in a specific reduction of the outstanding debt and no unexpected collateral movements.

• Enhanced Solver Execution: In complex DeFi scenarios involving solver-based execution (e.g., intent-based architectures like CoW Swap), assertions could revolutionize how users interact with liquidity providers. A user could specify their required outcome (e.g., "I must receive at least 1000 USDC for my 1 ETH") while leaving the solver free to discover the optimal execution route across various liquidity sources. The assertion would guarantee the desired outcome, reverting the transaction if no solver could meet the specified conditions. It’s important to note this guarantee would apply within a single transaction on one network and would not inherently cover routes spanning multiple blockchains.

• Workflow Integrity: Assertions could be used to ensure that multi-step workflows reach their intended final state. For example, in a complex dApp interaction, an assertion could verify that any unused tokens are returned to the user, and all temporary token approvals granted during the workflow are revoked upon completion, preventing lingering security risks.

These diverse applications underscore the transformative potential of native transaction assertions, moving Ethereum closer to an environment where transactional predictability and user safety are guaranteed at the protocol level.

Community Engagement and the Road Ahead

The development of native transaction assertions is an active and collaborative effort within the Ethereum Foundation’s Trillion Dollar Security initiative. The successful implementation and widespread adoption of these crucial security enhancements depend heavily on community feedback and engagement. Wallet developers, protocol teams, security researchers, and end-users are encouraged to participate in shaping the design and implementation of these solutions.

The Ethereum Foundation explicitly invites interested parties to contribute to this research. Engagement opportunities include reaching out directly via email at [email protected] to explore specific use cases and help guide the research direction. Additionally, the broader Ethereum community can participate in technical discussions and provide input on the EIP-7906 discussion thread on Ethereum Magicians (ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130).

As Ethereum progresses towards its vision of a secure, scalable, and decentralized future, initiatives like native transaction assertions are pivotal. They represent a concerted effort to address fundamental user experience risks, elevate the baseline of on-chain security, and ultimately foster greater trust and adoption within the ecosystem. Further information on risk controls and priority work within the Trillion Dollar Security initiative can be found at trilliondollarsecurity.org. The ongoing dialogue and collaboration will be instrumental in bringing these vital security advancements to fruition.