Ethereum Foundation Explores Native Transaction Assertions to Mitigate User Experience Risks

As part of the broader ongoing efforts of the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers have identified blind signing and transaction uncertainty as critical user experience risks facing the network. To combat these persistent vectors of vulnerability, the initiative is actively exploring native transaction assertions as a fundamental next step designed to enforce a transaction’s final outcome. This proposed paradigm shift would work hand-in-hand with emerging standards like Clear Signing to offer a robust layer of protection that safeguards users where conventional defenses currently fall short.

The core problem centers on why a valid cryptographic signature does not always guarantee the specific transaction result a user intended to execute. By diving into the mechanics of how native transaction assertions could protect funds, developers are evaluating various design choices, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a primary and promising approach to solving long-standing execution anxieties across the ecosystem.

Two Ways a Signed Transaction Can Go Wrong

The root of the issue stems fundamentally from how Ethereum executes instructions. The Ethereum Virtual Machine (MVM) executes requests precisely as they are authorized, operating without intrinsic judgment regarding whether the ultimate result matches what the user actually desired. A cryptographic signature acts as an unyielding commitment to a requested operation, but its actual outcome is entirely dependent on the specific smart contract code and ledger state it encounters at the exact moment of execution. Over the history of the network, users have lost substantial sums either because they approved a request that differed significantly from what they believed they were signing, or because a thoroughly intended request still produced an economic result that conflicted entirely with their goals.

The first major failure mode is an intent mismatch, a dangerous phenomenon vividly illustrated by security breaches such as the Bybit incident and the notorious BadgerDAO attack. In both of these high-profile security compromises, a compromised frontend or malicious injection supplied a signing interface request that quietly differed from what users thought they were approving. Specifically, Bybit signers inadvertently authorized replacing their Safe multi-sig implementation contract, while BadgerDAO users unknowingly granted an attacker extensive permissions to spend their underlying tokens.

The second major category of failure is an outcome mismatch. In this scenario, the signer accurately approves the exact request they were shown, but structural limits or the underlying state it runs against still permit a final execution result that heavily conflicts with their economic strategy or standing safety policies. A clear example of this occurred during an Aave and CoW collateral swap event. A user attempted to execute a swap of approximately $50.4 million worth of aEthUSDT for aEthAAVE. Unfortunately, native liquidity for AAVE was far too thin to support a trade of that unprecedented magnitude.

At the same time, CoW Protocol’s internal gas ceiling mechanisms rejected more complex quotes during the verification phase, leaving a single verified quote of roughly 329 aEthAAVE. Although the user interface properly displayed a dramatic 99.9 percent price impact warning and explicitly required the user to acknowledge that the entire transaction value could be lost, the user signed the transaction anyway and ultimately received tokens valued at roughly $36,000.

All three of these distinct historical cases shared a common architectural vulnerability: they lacked a trusted, programmatic rule governing the resulting state, one defined independently of the transaction builder and strictly enforced directly during execution. In the Bybit scenario, an ideal rule would have required the approved Safe implementation contract to remain completely immutable and unchanged. For a Badger user, an automated rule would have restricted new token approvals exclusively to officially published and audited Badger contracts. In the Aave scenario, a protective rule would have enforced a strict minimum acceptable output, calculated independently of the localized quote shown by the Aave interface—keeping in mind that within such solver-based routing flows, the signed order or CoW settlement protocol itself would likewise need to mandate the assertion.

At present, Ethereum possesses no generalized native mechanism enabling onchain code to inspect the full, comprehensive set of net state changes and emitted events produced by an executing transaction.

What a Signature Does Not Control

When an Ethereum user signs a transaction, their signature commits strictly to the explicit action requested, including the designated target address, transferred value, and associated calldata. However, the EVM executes this call against whatever contract code and ledger state happens to be present at the exact block height when the transaction is finally processed, which may have shifted dramatically since the moment the user originally signed. Consequently, the resulting net balance modifications, storage updates, and emitted event logs can diverge wildly from expectations.

The target contract specified by the user, or alternatively another contract invoked deeper within the call stack, may utilize an upgradeable proxy pattern whose underlying implementation changes before execution occurs. As a result, the active code running on-chain can differ fundamentally from what the user inspected or verified beforehand. Furthermore, transaction ordering within a block can drastically alter the state environment encountered by the call. A classic example is a sandwich attack, where a malicious front-running transaction maliciously shifts a liquidity pool’s pricing curve right before a user’s pending swap executes, all without altering a single byte of the user’s signed transaction payload.

Where Today’s Defenses Stop

The Ethereum ecosystem has progressively deployed several defensive mechanisms to mitigate these risks. One prominent approach is Clear Signing, a standard engineered to decode and clearly explain to the user precisely what action the raw calldata requests. Naturally, Clear Signing relies heavily on accurate decoding pipelines and depends on the user correctly recognizing whether the displayed action deviates from their actual intent.

Another common defense layer is transaction simulation, which attempts to predict a transaction’s post-execution effects using a selected, contemporary chain state. However, chain state is inherently fluid and can change before block inclusion, meaning the transaction ultimately processed can diverge from the one that was previously simulated. A stark reminder of this limitation occurred during the Radiant Capital security incident, where both the user wallet interface and the underlying simulation engine accurately displayed the intended, benign transaction, while localized malware operating on the signers’ machines substituted a malicious payload precisely at the moment of signing.

Contract-level checks and wallet security guards also enforce hard rules during EVM execution. Uniswap interfaces, for instance, automatically configure transactions to revert if a swap’s final output drops below a pre-calculated amountOutMinimum threshold. Similarly, Safe’s checkAfterExecution hook enables a designated guard to inspect an account’s state configuration immediately following execution and revert transactions that violate established rules concerning account owners or parameters.

However, both of these approaches require developers and users to choose which specific state variables to check in advance. To read another contract’s storage slots, they are entirely dependent on the specific view functions that the target contract exposes. While checking a token contract’s balanceOf function is relatively straightforward, an arbitrary proxy contract is under no obligation to expose its underlying implementation address through a public getter function. Lacking such a dedicated interface, a traditional security guard is fundamentally blocked from reading the implementation storage slot directly.

Crucially, these existing checks are fundamentally incapable of inspecting a transaction’s complete set of net state changes. While a guard can verify that a specific asset balance remains untouched, it cannot broadly query the EVM to discover what else unexpectedly shifted, leaving unintended side effects completely undetected.

How Native Transaction Assertions Work

Native transaction assertions represent a fundamental architectural leap by allowing onchain code to inspect the full, aggregate set of net state changes occurring after all of a transaction’s primary actions have finished running. An assertion utilizes specialized read-only logic to compare starting and final state values against an explicit rule set. If the evaluated rule fails to pass, the entire transaction reverts.

This rule is embedded directly within the transaction payload and is cryptographically signed alongside its core actions. It can encompass net modifications to native asset balances, storage allocations, and contract code, as well as newly deployed contracts and emitted event logs. Effectively, it can mandate a strict minimum return amount, cap maximum spending, block unauthorized new token approvals, preserve an account’s control logic integrity, or restrict execution to an explicitly whitelisted set of alterations.

The source of the governing rule is just as critical as the verification check itself. If a compromised frontend were allowed to dictate the rule, it could easily write an assertion that accommodates its own attack vector. Therefore, a genuinely useful rule must derive from an independently verified user intent, a standing account policy, or core protocol logic that a compromised component cannot tamper with or override.

Three Design Choices and EIP-7906

Designing native transaction assertions requires navigating complex technical trade-offs concerning what specific information the EVM exposes, how assertion code accesses that information, and where the associated opcodes are permitted to run. Potential design choices include deciding whether to expose state changes, events, or both; determining access patterns ranging from enumerating individual entries to looking up specific values or copying full change-sets into memory; and establishing whether new opcodes should be restricted to specific transaction types or execution phases.

One leading implementation being actively discussed is EIP-7906, which builds directly upon the frame transactions defined in EIP-8141. While a frame transaction contains an ordered sequence of validation and action execution steps, EIP-7906 introduces a dedicated, read-only POST_TX frame positioned at the very end of the transaction lifecycle specifically to check the ultimate outcome. Within the broader upgrade roadmap, EIP-8141 is scheduled for the Hegot upgrade, whereas EIP-7906 has successfully advanced to the "Considered for Inclusion" milestone, though its inclusion remains unconfirmed.

The EIP-7906 design comprehensively exposes both net state changes and event data. State variations are systematically reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts paired with their respective code hashes. Notably, a storage slot that is written to multiple times during execution appears as a single unified entry detailing its starting and final values; if a slot concludes its lifecycle matching its original value, it is omitted entirely.

Access to this detailed telemetry is granted via three new EVM instructions. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves precise starting and final values for targeted addresses and storage slots, and EVENTDATACOPY copies event payloads directly into memory. These opcodes operate exclusively within the POST_TX frame, executing as a static call at the conclusion of the transaction to inspect outcomes without mutating state. If the asserted rule is violated, the entire execution body reverts, yet the transaction remains permanently recorded within the block with a failed status, ensuring that the gas payer is properly charged for the consumed computational resources. This economic deterrent prevents malicious actors from spamming network builders with deliberately failing transactions for free.

The Assertion Has to Be Required

Because EIP-7906 does not inherently mandate that every single transaction include an assertion, transaction builders retain the technical capability to omit them entirely. To achieve robust security, user wallets must ensure that any frame transaction they construct includes the necessary validation assertions, drawing rules either from automated pre-execution simulations or from standing user security policies.

Similarly, protected functions within decentralized protocols must programmatically verify that incoming calls originate from valid frame transactions containing the exact required assertions. Protocols must reject legacy standard transactions and frame transactions bearing missing or malformed assertions. Consequently, callers and integration partners must adopt compatible frame transactions, meaning already deployed immutable smart contracts cannot retroactively add this validation check without architectural wrappers.

Beyond immediate user security, native transaction assertions unlock broader utility across the ecosystem, including strengthening account delegation models. When delegating operational authority to an automated agent, users can constrain not only which contracts the agent accesses and how much capital it spends, but also the exact economic bounds of what each transaction must produce. As the Ethereum Foundation continues refining these specifications through the Trillion Dollar Security initiative, wallet developers, protocol maintainers, and researchers are encouraged to contribute to the ongoing design discussions.