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

As the Ethereum ecosystem continues to handle vast amounts of capital and complex decentralized financial operations, user experience risks such as blind signing and transaction uncertainty remain critical vectors for vulnerability. Moving forward from existing risk mitigation measures, the Ethereum Foundation’s Trillion Dollar Security initiative has identified these ongoing challenges as high-priority focus areas. Alongside the ongoing rollout of Clear Signing standards, researchers and developers within the initiative are actively exploring native transaction assertions as a foundational next step to enforce a transaction’s final outcome onchain.

This development addresses a fundamental security dilemma in modern blockchain interactions: the fact that a valid cryptographic signature does not inherently guarantee the final transaction result a user actually intended. By evaluating native transaction mechanisms—with proposals like EIP-7906 serving as a prime structural approach—the community is looking at ways to protect users at the protocol layer, bridging the critical gaps where today’s wallet defenses and simulation tools ultimately stop.

Two Ways a Signed Transaction Can Go Wrong

The root of the security issue lies deep within the deterministic execution model of Ethereum. The Ethereum Virtual Machine (EVM) executes transactions precisely as they are authorized, operating without inherent knowledge or judgment regarding whether the outcome aligns with the user’s true economic desires. A digital signature commits a user to a specific request, but the actual result of that transaction is heavily dependent on the contract code and the blockchain state it encounters during execution. Over the history of the network, users have suffered significant financial losses either because they inadvertently approved a malicious action that differed from their beliefs, or because a legitimate request produced an unintended and devastating financial outcome due to changing market or execution conditions.

The first major failure mode is an intent mismatch, a dangerous phenomenon vividly demonstrated in high-profile security incidents such as the Bybit safe wallet incident and the BadgerDAO attack. In both of these security breaches, a compromised frontend or malicious actor supplied a signing request that subtly or drastically differed from what the users believed they were authorizing. During the Bybit compromise, signers authorized an action that replaced the underlying Safe multi-signature wallet implementation contract with a malicious one. Similarly, in the BadgerDAO attack, unsuspecting users granted malicious contracts broad permissions to spend their tokens. In both scenarios, the underlying vulnerability stemmed from a lack of invariant control over the transaction’s final operational structure.

The second major failure mode is an outcome mismatch. In these instances, the signer genuinely approves the exact request presented by the user interface, but underlying execution limits, pool liquidity constraints, or shifting blockchain states allow a final result that starkly conflicts with the user’s economic goals or standing risk policies. A clear example of this occurred during a collateral swap involving Aave and CoW Protocol. A user attempted to execute a massive trade swapping approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was far too thin to support a trade of that magnitude without severe slippage, and because CoW’s gas ceiling mechanisms rejected more complex split quotes during verification, only a single verified quote returning roughly 329 aEthAAVE remained viable.

Although the user interface displayed a stark 99.9 percent price impact warning and required explicit confirmation that the entire transaction value could be lost, the user ultimately signed the transaction anyway, receiving tokens worth a mere $36,000 in return. Across all three of these distinct historical cases—Bybit, BadgerDAO, and the massive Aave-CoW collateral swap—a critical safeguard was entirely missing: a trusted, independent rule governing the resulting state that is defined separately from the transaction builder and strictly enforced during EVM execution.

If a native protection rule had been active, the Bybit signers could have enforced that the approved Safe implementation contract remain completely unchanged. BadgerDAO users could have restricted token approvals exclusively to officially published protocol contracts. Furthermore, the Aave user could have established a strict minimum acceptable output calculated independently of the interface’s displayed quotes, forcing a reversion if the actual economic outcome fell below acceptable thresholds. Currently, however, Ethereum lacks a generalized native mechanism allowing onchain code to inspect the full set of net state changes and emitted events produced by a transaction before final settlement.

What a Signature Does Not Control

When a user signs a transaction on Ethereum, their cryptographic signature commits strictly to the requested action, specifying parameters such as the target address, transferred value, and execution calldata. However, the EVM executes this call against the exact contract code and blockchain state present at the precise moment the transaction is processed by the network—not necessarily the state that existed when the user originally signed. Consequently, the resulting net balance modifications, storage updates, and event logs can deviate significantly from initial expectations.

The target contract specified in a transaction, or any other contract it interacts with during execution, may rely on proxy patterns where the underlying implementation contract changes unexpectedly before the transaction is finalized. This means the code that ultimately runs can differ entirely from what the user or their wallet initially inspected. Furthermore, transaction ordering in the mempool introduces persistent uncertainty. Miner-extractable value (MEV) strategies, such as sandwich attacks, can dynamically shift a liquidity pool’s price immediately before a user’s swap executes, altering the economic reality of the trade without modifying the user’s originally signed transaction.

Where Today’s Defenses Stop

The Ethereum ecosystem has deployed several vital defenses to combat these risks, but each possesses inherent operational limitations. One prominent defense is Clear Signing, a standard designed to decode and present transaction calldata in a human-readable format so users understand what an interaction requests. Clear Signing relies heavily on accurate decoding libraries and depends entirely on the user’s ability to recognize when the displayed action contradicts their original intent.

Another common defense is transaction simulation, which predicts the effects of a transaction by testing it against a selected snapshot of the chain state prior to submission. Because chain states are highly dynamic and can shift before block inclusion, the transaction that ultimately gets executed can diverge from the one that was simulated. A stark illustration of this vulnerability occurred during the Radiant Capital exploit, where both the user’s wallet interface and the underlying simulation accurately displayed the intended transaction, but malware active on the signers’ local machines covertly substituted a malicious payload at the exact moment of signing.

Wallet guards and contract-level checks also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-calculated amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook, allowing a security guard contract to inspect the account’s state after transaction execution and automatically revert the entire transaction if it violates pre-determined rules regarding account owners or configuration parameters.

However, both approaches require developers and users to choose in advance precisely which state variables to check. To read the storage of another contract, these checks depend entirely on the specific view functions that the target contract exposes. While checking a token’s balance via a standard balanceOf function is relatively straightforward, a complex proxy contract is not required to expose its underlying implementation address through an accessible function. Without such an explicit interface, a wallet guard is fundamentally incapable of reading the implementation storage slot directly. Crucially, these existing checks cannot inspect the transaction’s complete set of net state changes, meaning that unforeseen side effects or malicious modifications outside the scope of targeted checks can easily go unnoticed.

How Native Transaction Assertions Work

To fundamentally overcome these limitations, the Ethereum Foundation’s initiative is exploring native transaction assertions. This capability would empower onchain code to inspect the full set of net state changes occurring as a result of a transaction’s actions. Utilizing read-only logic, an assertion compares starting values and final values against a predefined set of user- or protocol-defined rules. If the execution violates any condition outlined in the rule, the transaction’s actions are entirely reverted.

The assertion rule itself is embedded directly into the transaction structure and cryptographically signed alongside its primary actions. These rules can comprehensively cover net changes to native asset balances, storage slots, and contract code, as well as newly deployed contracts and emitted event logs. A user or protocol could mandate a strict minimum received amount, cap maximum spending, block unauthorized token approvals, preserve an account’s foundational control logic, or whitelist a specific set of allowable state modifications.

However, the provenance of the rule is just as critical as the verification logic itself. If a compromised frontend interface were allowed to arbitrarily write the assertion rule, it could simply craft an assertion that permits the malicious exploit to proceed. Therefore, an effective security rule must originate from an independently verified expression of user intent, a standing institutional account policy, or rigid protocol logic that a compromised component cannot manipulate.

Three Design Choices

Designing native transaction assertions at the protocol level requires complex decisions regarding how much information the EVM should expose, how assertion code accesses that data, and where the corresponding opcodes are permitted to run. Core architectural considerations include whether the exposed information should encompass state changes, emitted event logs, or both. Access options range from enumerating entries sequentially to looking up specific values directly or copying the entire set of net changes into transient memory. Furthermore, protocol designers must determine whether the new opcodes should be restricted exclusively to specific transaction types or execution phases, or if they should be made available generally across the EVM.

EIP-7906 as a Possible Solution

One of the prominent technical proposals addressing these challenges is EIP-7906, which builds natively upon the frame transactions introduced in EIP-8141. A frame transaction encapsulates an ordered sequence of distinct validation and action steps. EIP-7906 proposes appending a read-only POST_TX execution frame at the very end of the transaction lifecycle specifically designed to evaluate the transaction’s ultimate outcome.

The design of EIP-7906 exposes both comprehensive state changes and event data. Net state changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contract addresses and their corresponding code hashes. For instance, a storage slot that is written to multiple times during a complex transaction execution sequence appears as a single unified entry detailing its initial starting value and its final ending value. If a storage slot ultimately reverts to its original value by the end of the transaction, it is omitted entirely.

To provide access to this rich dataset, the proposal introduces three new EVM opcodes. The TXTRACE opcode enumerates net state changes and event logs, the TXDIFF opcode retrieves starting and final values for specific target addresses and storage slots, and the EVENTDATACOPY opcode copies specific event data directly into memory for programmatic inspection.

Crucially, these specialized opcodes operate exclusively within the POST_TX frame, which executes as a static call at the conclusion of the transaction. This ensures that the assertion can inspect the final execution outcome without altering state variables. If the underlying rule is violated, the entire execution body of the transaction reverts. Nevertheless, the transaction remains recorded within the block with a failed execution status, and the gas payer is charged for the total computational gas consumed during the attempt. This economic deterrent prevents malicious actors from spamming network builders with deliberately failing transactions for free.

The Assertion Has to Be Required

A key structural challenge with proposals like EIP-7906 is that they do not inherently mandate that every transaction include an assertion, meaning that transaction builders could theoretically leave them out entirely. To achieve meaningful security, the ecosystem must enforce their usage.

For everyday user transactions, modern wallets must take responsibility for ensuring that every frame transaction they construct includes the appropriate validation assertion. These rules can be derived automatically from simulations executed locally by the wallet or enforced via standing user security policies that govern all outgoing transactions.

For decentralized protocols, protected contract functions must independently verify that incoming calls originate from an approved frame transaction containing the exact required assertion structure. Such protocols must actively reject ordinary transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, callers and downstream integrations would be required to adopt compatible frame transactions, meaning already deployed immutable smart contracts would lack the ability to retrofit this specific check without proxy upgrades or migration paths.

Where Transaction Assertions Could Help

Beyond enhancing fundamental security for individual users and decentralized finance protocols, native transaction assertions could unlock powerful new capabilities across the Ethereum ecosystem. For example, they could significantly strengthen delegation and account abstraction workflows. When a user grants an external agent permission to act on their behalf, they typically limit which contracts the agent can interact with, how much capital it can spend, and how long its permissions remain valid. Transaction assertions would allow users to enforce strict outcome rules on every individual transaction executed by an agent, constraining both the operational actions taken and the exact economic results produced.

Protocols could similarly codify standardized safety rules, requiring identical invariant checks for every user interacting through compatible frame transactions. In solver-based execution models—such as advanced routing and intent protocols—a protocol could specify the exact required financial outcome while leaving third-party solvers completely free to determine the optimal execution route. Although this cryptographic guarantee would apply strictly within the boundaries of a single transaction on a single network, assertions could also be leveraged to verify that complex, multi-step workflows successfully reach their intended final state, ensuring that unspent tokens are safely returned to the user and any temporary token approvals are properly revoked before completion.

Help Shape the Design

Solutions surrounding native transaction assertions are actively being researched and designed as part of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback and collaboration from wallet developers, protocol engineers, and security teams who would ultimately implement and rely on these standards. Stakeholders interested in exploring specific use cases, contributing to ongoing research, or participating in technical discussions can reach out via email to [email protected] or join the ongoing EIP-7906 discussion thread on the Ethereum Magicians forum. Additional information regarding critical risk controls and priority development work is available at the official initiative portal, trilliondollarsecurity.org.