Ethereum Foundation Explores Native Transaction Assertions to Mitigate User Experience Risks

As part of the ongoing Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and security experts have identified blind signing and transaction uncertainty as critical user experience risks facing the ecosystem. To combat these persistent threats, the Foundation is actively exploring native transaction assertions as a powerful next step to enforce a transaction’s final outcome. This proposed line of defense would work alongside Clear Signing initiatives to protect users and protocols from unexpected execution results.

The core issue stems from a fundamental reality of how Ethereum operates. The Ethereum Virtual Machine (EVM) executes transactions exactly as authorized, without judging whether the resulting state matches the user’s actual intent. While a signature serves as a cryptographic commitment to a specific request, the ultimate outcome of that request depends heavily on the prevailing contract code and blockchain state encountered during execution. Over the history of the network, users have suffered significant financial losses either because they approved something entirely different from what they believed they were signing, or because a legitimate request still produced an undesirable economic result due to shifting onchain conditions.

Two Ways a Signed Transaction Can Go Wrong

Security analysts generally categorize transaction failures into two distinct scenarios: intent mismatches and outcome mismatches. The first category involves deceptive frontends or compromised interfaces, prominent examples of which include the high-profile Bybit incident and the BadgerDAO attack. In both of those historical events, compromised frontends supplied signing requests that deviated significantly from what users thought they were approving. During the Bybit incident, affected signers inadvertently authorized the replacement of a Safe multi-signature wallet’s implementation contract, whereas BadgerDAO users unknowingly granted malicious actors sweeping permissions to spend their tokens.

The second category, known as an outcome mismatch, occurs when a signer accurately approves the request shown to them, but transaction limits or real-time state changes allow an execution path that directly conflicts with their economic goals or standing safety policies. A clear illustration of this dynamic is the Aave and CoW collateral swap incident. In that event, a user initiated a transaction to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was exceedingly thin for a trade of that magnitude, and because CoW Swap’s gas ceiling mechanisms rejected complex quotes during verification, only a single verified quote of roughly 329 aEthAAVE remained viable. Although the user interface displayed a severe 99.9 percent price impact warning and required explicit confirmation that the entire value could be lost, the user proceeded to sign the transaction, ultimately receiving tokens valued at a mere $36,000.

In all three of these notable cases, the missing component was a trusted, independent rule governing the resulting state—one defined separately from the transaction builder and strictly enforced during execution. A protective rule in the Bybit scenario would have mandated that the approved Safe implementation contract remain entirely unchanged. For a BadgerDAO user, a strict policy would have permitted new token approvals exclusively for verified, published Badger contracts. In the Aave instance, an automated rule could have established a rigid minimum acceptable output calculated independently of the interface’s displayed quote, while protocol-level solver flows would have been required to honor that assertion. Currently, however, Ethereum lacks a generalized mechanism for onchain code to inspect the full scope of net state changes and emitted events produced by a single transaction.

What a Signature Does Not Control

When a user signs an Ethereum transaction, their cryptographic signature commits strictly to the requested action, including the designated target address, transferred value, and calldata payload. However, the EVM executes this call against the specific contract code and blockchain state present at the exact moment the transaction is processed by the network, which may have shifted dramatically since the moment of signing. Consequently, the resulting net balances, storage modifications, and emitted events can diverge widely from user expectations.

Furthermore, target contracts or their underlying dependencies frequently utilize proxy architectures whose implementation logic can change prior to execution, meaning the code that actually runs may differ from what the user originally inspected. Transaction ordering also introduces volatility. For instance, a classic sandwich attack can manipulate liquidity pool prices right before a user’s swap executes without altering a single byte of the user’s signed transaction data.

Where Today’s Defenses Stop

The Ethereum ecosystem has deployed several vital defenses to mitigate these risks, but each possesses inherent limitations. Clear Signing initiatives strive to explain the precise actions requested by calldata, yet they still rely heavily on accurate decoding and the signer’s ability to recognize discrepancies between the displayed action and their true intent.

Simulation tools predict a transaction’s effects using a snapshot of the chain state, but that state can shift before inclusion, or the signed transaction might differ entirely from the simulated one. In the security breach experienced by Radiant Capital, for example, both the wallet interface and the simulation accurately displayed the intended transaction, but malware running locally on the signers’ machines substituted a malicious payload at the exact moment of signing.

Existing contract checks and wallet guards enforce specific rules during EVM execution, such as Uniswap’s amountOutMinimum check or Safe’s checkAfterExecution hook, which allows an account guard to review the account state post-execution and revert transactions that violate safety parameters. However, these mechanisms require developers to choose which specific state variables to check in advance. Reading another contract’s storage depends entirely on the specific functions exposed by that contract. While a token’s balanceOf function makes standard balance checks straightforward, a proxy contract is not obligated to expose its implementation address via a public function, leaving guards unable to read the implementation slot directly. Crucially, these legacy checks cannot inspect a transaction’s comprehensive net state changes, meaning unforeseen side effects can easily bypass traditional defenses.

How Native Transaction Assertions Work

Native transaction assertions would fundamentally expand the EVM’s capabilities by allowing onchain code to inspect the full set of net state changes after a transaction’s primary actions have completed execution. Utilizing read-only logic, an assertion compares starting and final values against a predefined rule. If the established rule is violated, the transaction’s actions automatically revert.

The rule itself is embedded directly within the transaction payload and is cryptographically signed alongside its execution steps. These rules can govern net changes across native token balances, storage slots, newly deployed contracts, emitted events, and code modifications. They can enforce minimum payout thresholds, cap spending limits, block unauthorized token approvals, preserve account control logic, or restrict execution to an explicitly approved set of changes.

However, the provenance of the rule is as critical as the validation check itself. A compromised frontend interface could theoretically write a malicious assertion that permits an attack, underscoring that a truly useful rule must originate from independently verified user intent, a standing account-level policy, or immutable protocol logic that untrusted components cannot tamper with.

Design Choices and EIP-7906

Implementing native transaction assertions requires navigating complex design choices regarding what data the EVM exposes, how assertion code accesses that data, and where the necessary opcodes can execute. Potential solutions involve exposing state changes, events, or both, while access mechanisms could range from enumerating entries and looking up specific values to copying full change sets into memory.

As a prominent approach to addressing these challenges, EIP-7906 builds directly upon the frame transactions defined in EIP-8141. While EIP-8141 introduces an ordered sequence of validation and action steps, EIP-7906 appends a read-only POST_TX frame at the conclusion of the transaction lifecycle to verify the final outcome.

EIP-7906 proposes exposing both state changes and event logs, with state modifications reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. Three new EVM opcodes—TXTRACE, TXDIFF, and EVENTDATACOPY—would provide access to this data exclusively within the POST_TX frame. If an assertion rule fails, the entire execution body reverts, though the transaction remains permanently recorded on the blockchain with a failed status, ensuring that the gas payer is charged for consumed resources to prevent denial-of-service vectors.

Expanding Adoption and Future Outlook

Because EIP-7906 does not mandate transactions to include assertions by default, transaction builders could theoretically omit them. Consequently, wallets must ensure that any frame transactions they construct automatically incorporate appropriate assertions derived from local simulations or standing user policies. Similarly, protected protocol functions would need to verify that incoming calls originate from compliant frame transactions containing exact, required assertions.

Beyond strengthening user security against frontrunning, sandwich attacks, and interface compromises, native transaction assertions could enhance delegated agent execution, allow protocols to enforce uniform safety checks across solver-based routing architectures, and verify that complex workflows reach intended final states with residual funds and approvals properly managed.

Research and development surrounding native transaction assertions remain active under the Ethereum Foundation’s Trillion Dollar Security initiative. Wallet developers, protocol engineers, and researchers interested in contributing to the design discussions can engage with the community through the ongoing EIP-7906 discussion channels or connect directly with the initiative’s security researchers.