As part of the ongoing Trillion Dollar Security initiative, the Ethereum Foundation is actively investigating native transaction assertions as a critical next step to enforce the final outcomes of blockchain transactions. Operating alongside Clear Signing, this research aims to address persistent user experience and security risks such as blind signing and transaction uncertainty.
The core issue stems from how the Ethereum Virtual Machine (EVM) operates. The network executes transactions precisely as authorized, without inherently validating whether the resulting state matches a user’s expectations. While a signature serves as a binding commitment to a request, the ultimate economic and technical outcome relies heavily on the underlying code and network state encountered during execution. Over the history of the ecosystem, significant capital has been lost not only because users mistakenly approved malicious actions, but also because intended requests produced undesirable, unforeseen results.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize transaction failures into two primary vulnerabilities: intent mismatches and outcome mismatches.
Intent mismatches occur when a compromised frontend or interface supplies a signing request that differs drastically from what a user believes they are authorizing. High-profile security breaches, such as the Bybit incident and the BadgerDAO attack, underscore this danger. In the Bybit event, signers authorized the replacement of a Safe’s core implementation contract due to a manipulated interface. Similarly, BadgerDAO users inadvertently granted attackers broad permissions to drain their token balances because the presented transaction payload was covertly altered.
Outcome mismatches represent a distinct challenge where a user approves an exact request, but shifting market states or narrow execution limits yield a result that directly conflicts with their economic goals or standing safety policies. A prominent example involves an Aave and CoW collateral swap, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Due to thin liquidity for a trade of that magnitude and stringent gas ceilings that rejected complex quotes during verification, the protocol processed a single verified quote returning a fraction of the expected value. Despite a severe price impact warning displayed by the interface, the user signed the transaction and suffered an immense financial loss.
In all three scenarios, the fundamental missing element was a trusted rule governing the resulting state—one defined independently of the transaction builder and strictly enforced during execution. Currently, Ethereum lacks a generalized native mechanism for onchain code to inspect the comprehensive set of net state changes and emitted events produced by a transaction before it is finalized.
What a Signature Does Not Control
When a user signs an Ethereum transaction, they commit to specific parameters including the target address, value, and calldata. However, the EVM evaluates this call against whatever contract code and network state exist at the exact moment of inclusion, which may have shifted significantly since the moment of signing. Consequently, net balance shifts, storage alterations, and event emissions often diverge from initial assumptions.
The targeted contract, or any secondary contract it interacts with, may rely on proxy patterns where the implementation logic is altered prior to execution. Furthermore, transaction ordering introduces susceptibility to manipulation. Sandwich attacks, for instance, can drastically shift a liquidity pool’s price immediately before a swap executes without altering the user’s signed transaction data.
Where Today’s Defenses Stop
The blockchain ecosystem has deployed several defensive mechanisms to mitigate these risks, though each possesses distinct limitations. Clear Signing initiatives strive to provide human-readable interpretations of raw calldata, yet they depend entirely on accurate decoding and the user’s ability to recognize discrepancies.
Transaction simulation offers another layer of protection by predicting outcomes against a specific chain state. However, because network conditions evolve rapidly before inclusion, the simulated state can differ from the final execution environment. In the Radiant Capital exploit, both the wallet interface and simulation tools displayed the intended legitimate transaction, while localized malware substituted a malicious payload at the precise moment of signing.
Existing contract checks and wallet guards enforce rules during EVM execution, such as Uniswap’s slippage protection via minimum output amounts or Safe’s post-execution hooks. While effective within narrow parameters, these systems require developers to anticipate which state variables to monitor in advance. Because they typically rely on explicit functions exposed by target contracts, they struggle to inspect unexposed storage slots, such as hidden implementation addresses in proxy contracts, and remain incapable of auditing the full scope of net state changes.
How Native Transaction Assertions Work
Native transaction assertions propose a structural solution by allowing onchain code to inspect the complete set of net state changes after a transaction’s primary actions have run. Utilizing read-only logic, an assertion evaluates starting and final values against a predefined rule. If the criteria are not met, the entire transaction reverts.
These rules are embedded directly within the transaction payload and signed alongside the core actions. They can regulate net changes to native balances, storage slots, newly deployed contracts, and emitted logs. By establishing rigid boundaries—such as capping spending, blocking unauthorized token approvals, enforcing minimum receiving amounts, or preserving control logic—assertions ensure that execution conforms strictly to pre-approved parameters.
However, the origin of the rule remains paramount. If a compromised frontend generates the assertion, security guarantees fail. Consequently, effective rules must originate from independently verified user intent, established account policies, or immutable protocol logic.
Three Design Choices and EIP-7906
Implementing native transaction assertions requires deliberate architectural choices regarding EVM data exposure, access mechanisms, and execution phases. Developers must determine whether to expose state modifications, events, or both, alongside deciding whether assertion code should enumerate entries, query specific values, or copy full change sets into memory.
One leading proposal addressing these requirements is EIP-7906, which builds upon the frame transactions introduced in EIP-8141. While EIP-8141 establishes an ordered sequence of validation and action steps, EIP-7906 introduces a read-only POST_TX frame executed at the conclusion of the transaction to verify outcomes.
EIP-7906 exposes state changes as net differences in native ETH balances and storage, alongside newly deployed contract code hashes. Specialized opcodes provide access to this data: TXTRACE enumerates net changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies event payloads into memory. Restricted strictly to the POST_TX static call frame, these opcodes evaluate execution results safely. If a rule violation occurs, the transaction reverts while remaining recorded onchain with a failed status, ensuring the gas payer is charged for consumed computational resources to deter spam.
The Assertion Has to Be Required
Because EIP-7906 does not mandate assertions for all transactions by default, transaction builders retain the technical ability to omit them. To achieve robust security, client wallets must automatically append required assertions derived from simulations or standing user policies for every constructed frame transaction.
Similarly, decentralized protocols seeking to protect their users must programmatically verify that incoming calls originate from frame transactions containing exact, valid assertions. Interacting applications and solvers must adopt compatible transaction structures, highlighting that already deployed immutable contracts cannot retroactively incorporate this verification layer.
Where Transaction Assertions Could Help and Future Outlook
Beyond bolstering standard user security, native transaction assertions offer powerful utility for delegated account abstraction and automated agents. By constraining not just the permissions granted to an automated agent, but the explicit economic outcome of its actions, users can safely delegate complex financial operations. Protocols can likewise enforce standardized safety checks for solver networks, guaranteeing minimum acceptable outcomes while granting solvers the flexibility to optimize routing within a single network transaction.
Research into native transaction assertions continues to evolve under the Ethereum Foundation’s Trillion Dollar Security initiative. Wallet developers, protocol engineers, and researchers interested in contributing to the design and shaping future implementation discussions are encouraged to engage with the core research initiatives and community improvement threads.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
