The Ethereum Foundation’s ambitious Trillion Dollar Security initiative has flagged blind signing and underlying transaction uncertainty as critical user experience and security risks facing the ecosystem today. As part of an ongoing effort to harden user protections alongside features like Clear Signing, developers and researchers are exploring the implementation of native transaction assertions. This mechanism is designed to strictly enforce a transaction’s final outcome before it is committed to the blockchain, offering a powerful safety net where current security defenses ultimately fall short.
This initiative addresses a fundamental challenge in blockchain mechanics: obtaining a valid cryptographic signature does not inherently guarantee that the transaction execution will yield the result a user intended. By introducing native transaction assertions, the Ethereum community hopes to protect users from unexpected execution paths, malicious frontends, and unfavorable market conditions. Proposals such as EIP-7906, which utilizes a State Diff Opcode, represent one potential technological pathway toward achieving this goal onchain.
Two Ways a Signed Transaction Can Go Wrong
The root of the issue lies in how Ethereum processes transactions. The Ethereum Virtual Machine (EVM) executes commands precisely as authorized, without evaluating whether the final economic or operational result aligns with what the user actually wanted. While a signature serves as a binding commitment to a request, the actual outcome depends entirely on the code and state encountered at the exact moment of execution. Historically, users have suffered significant financial losses due to two distinct categories of failures: intent mismatches and outcome mismatches.
An intent mismatch occurs when a user approves a request that differs significantly from what they believed they were authorizing. Prominent examples of this vulnerability include high-profile security incidents such as the Bybit compromise and the BadgerDAO attack. In both instances, compromised frontends supplied signing requests that masked the true nature of the operation. Bybit signers inadvertently authorized the replacement of a Safe implementation contract, while BadgerDAO users unknowingly granted malicious actors permission to drain their token balances.
Conversely, an outcome mismatch happens when the signer approves a valid, correctly displayed request, but external conditions or execution limits produce a result that directly conflicts with their financial goals or standing safety policies. A striking illustration of this occurred during a collateral swap involving Aave and CoW Swap, where a user attempted to swap roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was vastly insufficient for a trade of that scale—and because CoW’s gas ceiling rejected complex quotes during verification—only a single verified quote yielding about 329 aEthAAVE remained.
Although the interface warned of a 99.9 percent price impact and required explicit confirmation that the entire value could be lost, the user signed the transaction regardless, ultimately receiving tokens valued at around $36,000. In all three scenarios—Bybit, BadgerDAO, and the Aave collateral swap—the underlying system lacked a trusted rule governing the resulting state that was defined independently of the transaction builder and enforced directly during execution.
A proper rule in the Bybit case would have mandated that the approved Safe implementation contract remain unchanged. For BadgerDAO users, automated policies would have restricted token approvals exclusively to verified, published contracts. For the Aave user, a hard rule would have enforced a minimum acceptable output calculated independently of the interface quote. Currently, Ethereum lacks a generalized mechanism that allows onchain code to inspect the full set of net state changes and emitted events produced by a transaction before it finalizes.
What a Signature Does Not Control
When a user signs an Ethereum transaction, their cryptographic signature commits strictly to the requested action, including the target contract, value, and calldata. However, the EVM executes this call against the specific contract code and state present at the moment the transaction is processed by the network. Because blockchain state is dynamic, conditions can change dramatically between the time of signing and the time of execution. Consequently, net balance shifts, storage updates, and emitted events can deviate sharply from expectations.
The target contract, or any secondary contracts it interacts with, may rely on proxy patterns where the implementation address changes prior to execution. This means the code that ultimately runs can differ from what the user inspected in their wallet interface. Furthermore, transaction ordering introduces severe vulnerabilities, such as sandwich attacks, which can maliciously shift a liquidity pool’s price immediately before a swap executes without altering the user’s signed transaction data in any way.
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 calldata requests in human-readable terms, yet they depend entirely on accurate decoding and the user’s ability to spot discrepancies between the displayed action and their true intent.
Simulation tools predict transaction outcomes using a selected chain state, but that state can shift before inclusion, and the transaction ultimately signed may differ from the one originally simulated. A stark example of this vulnerability occurred during the Radiant Capital exploit, where both the wallet interface and the simulation accurately displayed the intended transaction, but malware residing on the victims’ machines substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also enforce specific rules during EVM execution. For instance, Uniswap automatically reverts a swap if the output falls below a predefined parameter known as amountOutMinimum. Similarly, Safe accounts utilize a checkAfterExecution hook that enables a security guard to inspect account state post-execution and revert transactions that violate established rules.
However, these existing approaches require developers to anticipate and choose which specific state variables to check in advance. Reading another contract’s storage depends entirely on the functions that contract chooses to expose. While checking a token balance via balanceOf is relatively straightforward, proxy contracts are not required to expose their implementation addresses through a readable function. Without a direct interface, a security guard cannot read the implementation slot directly. Crucially, these legacy checks remain incapable of inspecting a transaction’s comprehensive set of net state changes, meaning unforeseen modifications can easily slip past unobserved.
How Native Transaction Assertions Work
To bridge these security gaps, native transaction assertions would empower onchain code to inspect the complete set of net state changes immediately after a transaction’s primary actions have executed. Utilizing read-only logic, an assertion evaluates starting and final values against a predefined rule. Should the rule fail, the transaction’s actions automatically revert.
This rule is embedded directly within the transaction data and signed alongside its execution steps. It can encompass net modifications to native ETH balances, storage slots, and smart contract code, as well as newly deployed contracts and emitted events. Rules can be tailored to enforce minimum received amounts, cap spending limits, block unauthorized token approvals, preserve account control logic, or restrict operations to a permitted set of state alterations.
The reliability of an assertion depends heavily on its origin. A compromised frontend could theoretically draft a fraudulent assertion that permits an attack, underscoring the necessity for rules to originate from independently verified user intent, robust standing account policies, or immutable protocol logic that malicious components cannot manipulate.
Three Design Choices and EIP-7906
Implementing native transaction assertions requires navigating three fundamental design choices: determining what information the EVM exposes, establishing how assertion code accesses that data, and deciding where the corresponding opcodes can run. Potential data points range from raw state changes to specific event logs, while access mechanisms could involve entry enumeration, direct value lookups, or copying full change sets into memory. Additionally, developers must decide whether these opcodes should be restricted to specific transaction types or execution phases, or permitted universally across the EVM.
A leading proposal addressing these challenges is EIP-7906, which builds upon the foundational frame transactions outlined in EIP-8141. While EIP-8141 introduces an ordered sequence of validation and action steps and is scheduled for the Hegot upgrade, EIP-7906 introduces a dedicated, read-only POST_TX frame positioned at the conclusion of a transaction to evaluate its final outcome. EIP-7906 has advanced to being "Considered for Inclusion" in upcoming protocol updates.
The EIP-7906 design exposes both state changes and event data, reporting state modifications as net differences in native ETH balances and storage alongside newly deployed contract code hashes. For instance, a storage slot modified multiple times within a single transaction is reported as a single entry reflecting only its initial and final values. If a storage slot ultimately reverts to its original value, it is omitted entirely.
Three new EVM opcodes facilitate this verification process: TXTRACE to enumerate net state changes and events, TXDIFF to retrieve starting and final values for specific addresses and storage slots, and EVENTDATACOPY to copy event data into memory. These opcodes function exclusively within a POST_TX frame executing as a static call at the end of the transaction, ensuring assertions can inspect outcomes without altering blockchain state. If an assertion rule is violated, the execution body reverts, but the transaction remains recorded on the blockchain with a failed status, and the gas payer is charged for consumed resources. This economic deterrent prevents malicious actors from forcing block builders to process deliberately failing transactions for free.
The Assertion Has to Be Required
Because EIP-7906 does not inherently mandate that every transaction include an assertion, transaction builders retain the technical ability to omit them. Consequently, robust implementation requires wallets to ensure that every frame transaction they construct incorporates the necessary assertion, derived either from automated pre-execution simulations or strict standing account policies.
For decentralized protocols, protecting high-value functions requires verifying that incoming calls originate from frame transactions containing the exact required assertion, while automatically rejecting standard transactions or frame transactions featuring missing or incorrect rules. This necessitates compatible frame transaction structures across all callers and protocol integrations, noting that already deployed immutable contracts cannot retroactively incorporate this verification check.
Where Transaction Assertions Could Help
Beyond fortifying foundational user and protocol security, native transaction assertions unlock valuable utility across various web3 domains. In the realm of account delegation, where users authorize third-party agents to act on their behalf, assertions introduce deterministic outcome constraints. Users can limit not only which contracts an agent interacts with and how much capital they spend, but also what specific economic results their actions must produce.
Protocols can leverage assertions to enforce uniform safety checks across all interactions via frame transactions. In solver-based routing architectures, a protocol can specify a mandatory final outcome while granting solvers the flexibility to optimize the execution path. Although these guarantees remain confined to a single transaction on a single network—and thus cannot cover cross-chain routing workflows—assertions ensure that complex operations successfully reach their intended states, returning unused funds and revoking lingering token approvals automatically.
Help Shape the Design
The development of native transaction assertions remains an active area of research under the Ethereum Foundation’s Trillion Dollar Security initiative. Developers, wallet providers, and protocol engineers interested in utilizing these upcoming security primitives are encouraged to contribute to the research. Stakeholders can reach out via email at [email protected] to explore practical use cases or participate in the ongoing discussions on the Ethereum Magicians EIP-7906 thread. Further information regarding priority security work and risk controls is available at trilliondollarsecurity.org.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
