As the decentralized finance ecosystem continues to scale toward mass institutional and retail adoption, the Ethereum Foundation’s Trillion Dollar Security initiative has spotlighted critical user experience risks that have long plagued onchain interactions. Specifically, researchers are turning their attention to the persistent dangers of blind signing and transaction outcome uncertainty. To address these vulnerabilities head-on, the initiative is actively exploring the implementation of native transaction assertions as a foundational next step to enforce a transaction’s final execution outcome, working alongside complementary defenses like Clear Signing.
This comprehensive exploration focuses on a fundamental architectural reality of public blockchains: holding a valid cryptographic signature does not always guarantee the transaction result a user actually intended. By examining historical security breaches and market incidents, security researchers are investigating how native transaction assertions could protect everyday users and protocols alike in scenarios where current defenses fall short. Central to this discussion is EIP-7906—which proposes Transaction Assertions via State Diff Opcode—serving as one prominent technical approach currently moving through the Ethereum Improvement Proposal pipeline.
Two Ways a Signed Transaction Can Go Wrong
The root of the issue lies in the deterministic nature of how Ethereum operates at the protocol level. The Ethereum Virtual Machine (EVM) executes instructions precisely as authorized by the caller, without possessing any inherent awareness of whether the resulting economic or state outcome aligns with the user’s subjective intent. A cryptographic signature acts as a binding commitment to a specific request, but its ultimate effect is entirely dependent on the smart contract code and ledger state encountered during execution. Over the history of the network, users have suffered catastrophic financial losses either because they inadvertently approved an action entirely different from what they believed they were signing, or because a legitimate request executed under market conditions that produced an unwanted and damaging result.
The first major failure category is an intent mismatch, a perilous phenomenon vividly illustrated by high-profile security breaches such as the Bybit incident and the BadgerDAO attack. In both of these notorious security events, compromised frontend interfaces successfully supplied signing requests that deceptively differed from the actions users thought they were reviewing and approving. During the Bybit security breach, authorized signers signed transactions that inadvertently replaced their Safe account’s underlying implementation contract. Similarly, users interacting with BadgerDAO during their attack unknowingly granted malicious actors broad, unconstrained permissions to drain their deposited tokens.
The second major failure category involves an outcome mismatch. In this scenario, the user genuinely approves the exact request presented to them by the interface, but the execution limits or the prevailing ledger state still permit a final result that starkly conflicts with their financial goals or foundational safety policies. A prominent example of this dynamic occurred during the Aave and CoW collateral swap incident. A user submitted a transaction attempting to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Unfortunately, the available liquidity for AAVE on the market was far too thin to support a trade of that massive magnitude without catastrophic slippage. Furthermore, CoW Protocol’s strict gas ceiling rejected more complex, multi-route quotes during verification, leaving a single verified quote yielding roughly 329 aEthAAVE. Although the user interface displayed an alarming 99.9 percent price impact warning and required explicit confirmation that the entire value could potentially be lost, the user signed the transaction regardless, ultimately receiving tokens valued at a mere $36,000.
What tied these three disparate incidents together was the glaring absence of a trusted rule governing the resulting state—a rule defined independently of the transaction builder and strictly enforced directly during EVM execution. In the Bybit scenario, a robust rule would have mandated that the approved Safe implementation contract remain entirely immutable and unchanged. For a BadgerDAO user, an effective rule would have restricted new token spending approvals exclusively to officially published and audited Badger smart contracts. In the Aave collateral swap case, a protective rule would have enforced a strict minimum acceptable output threshold calculated independently of the quote displayed by the user interface, while also requiring supporting protocol infrastructure like solver networks or settlement protocols to enforce the assertion natively.
Currently, Ethereum lacks a generalized mechanism that allows onchain code to inspect the full scope 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 a transaction, their cryptographic signature commits strictly to the explicit request parameters, including the designated target contract address, attached value, and raw calldata. However, the EVM executes this call against whatever contract code and state happen to be present at the exact moment the transaction is included in a block. Because blockchain states are dynamic and fluid, the environment may have drifted significantly since the moment the transaction was originally signed. Consequently, the resulting net balance shifts, storage modifications, and emitted protocol events can diverge wildly from expectations.
The target smart contract, or any secondary contract it interacts with during execution, may rely on proxy patterns where the underlying implementation contract changes unexpectedly before the transaction runs. As a result, the executing code can differ from the code the user initially inspected. Furthermore, transaction ordering within a block remains a persistent variable. A classic sandwich attack, for instance, can maliciously manipulate a decentralized exchange liquidity pool’s price immediately before a user’s swap executes, altering the economic reality of the trade without modifying a single byte of the signed transaction payload.
Where Today’s Defenses Stop
The Ethereum ecosystem has progressively deployed several defensive mechanisms to mitigate these risks, but each possesses inherent boundaries. One primary defense is Clear Signing, an initiative designed to humanize raw calldata so users can clearly understand the specific actions requested by a transaction. However, Clear Signing ultimately relies on accurate decoding logic and depends entirely on the signer correctly recognizing whether the decoded action matches their true intent.
Another common defense is transaction simulation, which predicts the downstream effects of a transaction by evaluating it against a selected snapshot of the chain state. Despite its utility, the chain state is prone to shifting prior to block inclusion, and a malicious actor can substitute a completely different transaction payload at the moment of signing. This vulnerability was starkly demonstrated in the Radiant Capital post-mortem, where both the wallet interface and the pre-execution simulation accurately displayed the intended, harmless transaction, while malware operating locally on the signers’ machines covertly substituted a malicious payload at the exact moment of signature generation.
Contract-level checks and wallet security guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a swap if the final output falls below a pre-specified amountOutMinimum parameter. Similarly, the Safe multi-signature wallet ecosystem utilizes a checkAfterExecution hook, allowing a designated security guard contract to inspect an account’s state variables after execution concludes and revert transactions that violate established rules concerning account owners or configuration parameters.
Nevertheless, both of these approaches require developers to anticipate and choose which specific state variables to check in advance. To read another contract’s storage, these guards depend entirely on the explicit public functions exposed by that contract. While checking a standard ERC-20 token balance via balanceOf is straightforward, a proxy contract is not obligated to expose its implementation address through a standard public function. Without such an exposed interface, a security guard is fundamentally blocked from reading the implementation storage slot directly. Crucially, these existing checks remain incapable of inspecting a transaction’s complete set of net state changes, meaning that unforeseen side effects or malicious modifications outside the scope of the pre-programmed guard can slip through undetected.
How Native Transaction Assertions Work
Native transaction assertions represent a paradigm shift by enabling onchain code to inspect the comprehensive set of net state changes after all transactional actions have finished executing. An assertion leverages specialized read-only logic to compare the initial starting values and the final resulting values of the ledger against a predefined rule. If the outcome fails to satisfy the specified rule, the entire transaction’s actions are immediately reverted.
Under this model, the governing rule is embedded directly within the transaction payload and signed alongside the core execution actions. These assertions can govern net modifications across native ETH balances, contract storage slots, deployed bytecode, newly created smart contracts, and emitted protocol events. A rule can be configured to mandate a strict minimum received amount, cap token spending, block unauthorized token approvals, preserve an account’s control logic, or whitelist an explicit set of allowable changes.
However, the provenance of the rule is just as critical as the automated check itself. A compromised user interface or malicious frontend could theoretically write an assertion that covertly permits an exploit. Therefore, for a transaction assertion to be genuinely protective, the governing rule must originate from an independently verified user intent, a standing account security policy, or foundational protocol logic that cannot be manipulated by compromised client-side components.
Three Design Choices
Designing a native transaction assertion framework for the Ethereum protocol requires resolving three core architectural questions concerning what information the EVM exposes, how assertion code accesses that data, and where the necessary opcodes are permitted to execute.
First, protocol designers must determine whether the exposed information should encompass net state changes, emitted events, or both. Second, access mechanisms must be established, ranging from iterating through entries and querying specific values to copying the complete set of modifications directly into memory. Third, protocol engineers must decide whether the new opcodes should be restricted exclusively to specific transaction types and dedicated execution phases, or if they can be invoked freely anywhere within the EVM execution environment.
EIP-7906 as a Possible Solution
A prominent technical proposal addressing these challenges is Ethereum Improvement Proposal 7906 (EIP-7906), which builds directly upon the frame transactions framework defined in EIP-8141. A frame transaction encapsulates an ordered sequence of validation steps followed by execution actions. EIP-7906 proposes appending a dedicated, read-only POST_TX frame at the very end of the transaction lifecycle specifically designed to evaluate the transaction’s final outcome. While EIP-8141 has progressed toward the Hegot upgrade, EIP-7906 has advanced to "Considered for Inclusion," though its official inclusion in an upcoming network upgrade remains unconfirmed.
The proposed design of EIP-7906 exposes both comprehensive state changes and event logs. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed smart contracts and their corresponding code hashes. For instance, if a specific storage slot is written to five separate times during the course of a transaction, it is reported as a single net entry capturing only its starting value and its final value. If a storage slot ultimately reverts to its original value by the end of the transaction, it does not appear in the diff at all.
To interact with this data, the proposal introduces three specialized EVM instructions, or opcodes. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves the starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies the raw data of an event directly into memory.
Crucially, these opcodes are designed to function exclusively within the POST_TX frame, which executes as a static call at the conclusion of the transaction. This architecture allows the assertion logic to inspect the final execution outcome without modifying ledger state. If an assertion rule is violated, the entire execution body of the transaction reverts, but the transaction record remains permanently embedded in the block with a failed status, and the gas payer is charged for all gas consumed up to that point. This economic enforcement is vital to prevent malicious actors from spamming network builders with deliberately failing transactions for free.
The Assertion Has to Be Required
A key architectural nuance of EIP-7906 is that it does not inherently mandate that every transaction must include an assertion, meaning transaction builders retain the technical capability to omit them entirely.
To protect everyday user transactions, wallet software must take on the responsibility of ensuring that every frame transaction it constructs incorporates the necessary validation assertion. This rule can be dynamically generated via local wallet simulations or enforced through a standing security policy applicable to all outgoing transactions.
Conversely, for decentralized applications and smart contract protocols wishing to protect their users, protected protocol functions must explicitly verify that incoming calls originate from a frame transaction containing the exact, required assertion. Such protocols must outright reject standard legacy transactions as well as any frame transactions featuring missing or improperly configured assertions. Consequently, protocol callers and ecosystem integrations must adopt compatible frame transactions, and legacy smart contracts that are already immutable cannot retroactively add this validation check without a migration path.
Where Transaction Assertions Could Help
Beyond fortifying immediate user security and protocol safety, native transaction assertions unlock powerful new capabilities across the Ethereum ecosystem. For instance, they can substantially strengthen cryptographic delegation and account abstraction use cases. When users grant authorized agents or automation bots the ability to act on their behalf, they typically constrain which contracts the agent can interact with, how much capital it can spend, and how long its permissions remain valid. Transaction assertions add a critical layer of control by enforcing strict boundaries on the ultimate economic outcome of each transaction, constraining both the actions an agent can perform and the state changes those actions produce.
Protocols can also define standardized security rules, mandating identical safety checks for every incoming user interacting through a supported frame transaction. In sophisticated solver-based execution flows, a protocol could specify the required output state while leaving third-party solvers completely free to determine the optimal routing path to achieve it. While this guarantee applies strictly within the confines of a single transaction on a single network—and thus cannot natively span multi-chain cross-rollup pathways—assertions can also verify that complex multi-step workflows successfully reach their intended final state, ensuring that unspent tokens are reliably returned to the user and lingering token approvals are automatically revoked.
Help Shape the Design
Research and engineering surrounding native transaction assertions remain active components of the Ethereum Foundation’s Trillion Dollar Security initiative. Foundation researchers are eager to collaborate with wallet developers, protocol engineers, and security professionals who would ultimately implement and rely on these standards. Teams interested in exploring these use cases and contributing to ongoing research can reach out directly via email or participate in the public EIP-7906 community discussion threads. Additional information concerning ongoing risk controls and priority security initiatives can be found through official initiative portals.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
