As part of the broader ongoing efforts within the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers are focusing heavily on user experience risks associated with blind signing and transaction uncertainty. To combat these persistent vulnerabilities, the initiative is actively exploring the implementation of native transaction assertions as a crucial next step. These assertions are designed to enforce a transaction’s final outcome deterministically, working alongside parallel security enhancements like Clear Signing.
The core motivation behind this research stems from a fundamental reality of how Ethereum operates: the Ethereum Virtual Machine (EVM) executes instructions precisely as they are authorized, without making any subjective judgments regarding whether the ultimate result aligns with the user’s actual intent. While a cryptographic signature firmly commits to a requested transaction action, the final economic and state outcome depends entirely on the prevailing contract code and blockchain state encountered during execution. Over the history of the network, significant user and protocol funds have been lost either because individuals approved malicious operations that sharply differed from what they believed they were signing, or because legitimate signing requests produced unintended economic outcomes due to unforeseen environmental shifts.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize these catastrophic transaction failures into two distinct scenarios: intent mismatches and outcome mismatches.
An intent mismatch occurs when the cryptographic request presented to the signer has been maliciously altered or obscured, leading the user to authorize an action fundamentally different from their mental model. High-profile incidents in the decentralized finance space, such as the security breaches involving Bybit and BadgerDAO, starkly illustrate this vulnerability. In both instances, compromised frontends or malicious vectors supplied signing requests that concealed the true nature of the operation. Bybit’s signers unknowingly authorized the complete replacement of a Safe multi-signature wallet’s core implementation contract, while BadgerDAO users inadvertently granted an attacker unlimited permission to spend their personal tokens.
Conversely, an outcome mismatch arises when a user knowingly approves a valid request, but execution parameters or shifting block states yield a result that directly conflicts with their economic goals or pre-established safety policies. A prominent example of this dynamic unfolded during a collateral swap involving Aave and CoW Protocol, where a user attempted to trade approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE market liquidity was far too thin to absorb a trade of that magnitude, and because CoW’s gas ceiling mechanisms rejected complex multi-hop quotes during verification, only a single verified quote returning roughly 329 aEthAAVE remained viable. Despite the interface displaying a severe 99.9 percent price impact warning—alongside a strict requirement to confirm that the entire transaction value could potentially be lost—the user signed the transaction anyway, ultimately receiving tokens valued at a mere $36,000.
In all such historical cases, the fundamental missing element was a trusted, immutable rule governing the resulting state—one defined completely independently of the transaction builder and strictly enforced by the protocol execution layer itself. For instance, a proper rule in the Bybit scenario would have mandated that the approved Safe implementation contract remain unchanged. For a BadgerDAO user, a protective rule would have restricted new token approvals exclusively to verified, officially published Badger contracts. For the Aave swap, a reliable rule would have enforced a strict minimum acceptable output calculated independently of the specific quotes surfaced by the frontend interface. Currently, however, Ethereum lacks a generalized native mechanism allowing onchain logic to inspect the aggregate set of net state changes and emitted events produced over the course of a transaction.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is essential to examine the precise boundaries of what an Ethereum signature actually controls. When an account holder signs a transaction, they are committing strictly to specific input data: the intended target contract, the accompanying value in native ETH, and the raw calldata payload.
However, the EVM executes this call against whatever contract code and blockchain state happen to be present at the exact moment the transaction is included in a block. Because time elapses between signing and execution, the underlying environment frequently changes. Consequently, the resulting net balance shifts, storage updates, and event logs can diverge wildly from the signer’s initial expectations.
Furthermore, target contracts—or downstream contracts invoked during execution—frequently rely on proxy patterns where the implementation address can be modified prior to execution. This means the code that ultimately runs may differ significantly from the code inspected by the user during the signing phase. Transaction ordering and miner behavior introduce additional layers of unpredictability. Mechanics like front-running and sandwich attacks can drastically alter a liquidity pool’s pricing parameters immediately before a trade executes, entirely bypassing the parameters locked inside the user’s signed transaction without altering the calldata itself.
Where Today’s Defenses Stop
The Ethereum ecosystem has progressively deployed several defensive layers to mitigate these risks, though each possesses inherent limitations.
One primary defense is Clear Signing, an initiative designed to present human-readable summaries of what calldata requests actually do. While helpful, Clear Signing relies entirely on accurate decoding pipelines and assumes that the signer possesses the technical literacy to recognize when a decoded action deviates from their original intent.
Another common defense is transaction simulation, which predicts the net effects of a transaction against a selected snapshot of the chain state prior to broadcast. Because chain states are dynamic, the state at simulation time often differs from the state at inclusion time. Moreover, sophisticated malware operating directly on a signer’s local machine can substitute a malicious payload at the exact moment of signing, leaving simulation tools powerless if the signed transaction itself is what gets executed. This exact vector was observed in the security incident involving Radiant Capital, where wallet interfaces and simulation tooling accurately displayed the intended transaction while local malware injected a malicious payload at the signing step.
Contract-level checks and wallet guards also attempt to enforce boundaries during EVM execution. For example, Uniswap interfaces automatically revert token swaps if the final output falls below a pre-specified amountOutMinimum threshold. Similarly, Safe wallet architectures utilize execution hooks like checkAfterExecution to inspect account states post-execution, reverting transactions that violate pre-configured owner or administrative settings.
Despite their utility, these existing mechanisms require developers to anticipate and select which specific state variables to check in advance. Reading another contract’s storage depends entirely on the specific view functions that the target contract chooses to expose. While checking a standard ERC-20 token’s balance via balanceOf is straightforward, custom proxy structures or complex contracts may not expose internal implementation slots through a standard function call, leaving wallet guards blind to underlying structural modifications. Most importantly, these traditional checks cannot inspect the transaction’s full aggregate set of net state changes, meaning unforeseen side effects often slip through unoticed.
How Native Transaction Assertions Work
Native transaction assertions represent a paradigm shift by empowering onchain code to inspect the complete set of net state changes after all transaction actions have fully executed. Utilizing read-only logic, an assertion evaluates starting and final state values against a predefined set of rules. Should these rules fail to be satisfied, the entire transaction reverts.
Crucially, the assertion rule is embedded directly inside the transaction payload and signed alongside the primary transaction actions. These rules can govern net changes across native asset balances, storage slots, contract code modifications, newly deployed contracts, and emitted event logs. A rule can enforce strict economic bounds—such as requiring a minimum payout amount, capping token spending, blocking unauthorized token approvals, preserving an account’s governance control logic, or permitting only a strictly enumerated set of state transitions.
The origin and integrity of the rule itself are paramount. If a compromised frontend interface were allowed to write the assertion rule, it could easily craft a rule that explicitly permits the attack it intends to execute. Therefore, a secure rule must derive from independently verified user intent, standing account security policies, or protocol-level logic that untrusted intermediary components cannot tamper with.
EIP-7906 as a Possible Solution
Within the current research landscape, EIP-7906 has emerged as a prominent candidate to implement native transaction assertions, building directly upon the frame transaction architecture defined in EIP-8141. While EIP-8141 introduces structured frame transactions containing ordered sequences of validation and action steps, EIP-7906 proposes adding a dedicated, read-only POST_TX execution frame at the very end of the transaction lifecycle specifically to evaluate the final outcome.
Under this design, the EVM exposes both net state changes and event data. State modifications are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. To maximize efficiency, a storage slot that undergoes multiple writes throughout a transaction is reported as a single entry reflecting only its initial starting value and its final ending value; if a slot concludes with its original value intact, it is omitted entirely.
Access to this structural data is facilitated by three proposed EVM opcodes. The TXTRACE instruction enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies specific event payload data directly into memory.
These inspection opcodes are strictly restricted to operate exclusively within the POST_TX frame, which executes at the transaction’s conclusion as a static call to prevent any unintended state mutations during verification. If an assertion rule is violated, the entire transaction execution body reverts. However, the transaction remains recorded on-chain with a failed status, and the gas payer is held financially accountable for the computational resources consumed. This economic constraint prevents malicious actors from spamming block builders with deliberately failing transactions for free.
The Assertion Has to Be Required
A notable nuance of the current EIP-7906 framework is that transactions are not inherently mandated to include an assertion, leaving transaction builders technically capable of omitting them.
To achieve meaningful security, user wallets must ensure that every frame transaction they construct and broadcast automatically includes the appropriate assertion, derived either from rigorous pre-execution simulation or standing user security policies. Furthermore, decentralized protocols seeking to leverage this technology must implement protective checks within their core smart contracts to verify that incoming calls originate from frame transactions containing the exact required assertion, systematically rejecting ordinary transactions or improperly configured frame variants. Consequently, while new protocols can easily integrate these checks, already deployed immutable smart contracts cannot retroactively add native assertion verification.
Where Transaction Assertions Could Help
Beyond mitigating basic user-facing blind signing risks, native transaction assertions unlock powerful capabilities across a wide array of Web3 architecture. For instance, they can significantly strengthen account delegation frameworks. When delegating operational authority to automated trading agents or autonomous accounts, users can already limit which target contracts an agent can access, how much capital it can expend, and how long its permissions remain valid. Assertions add an essential layer of determinism by constraining the actual economic and structural output of every single delegated transaction.
Protocols can similarly define standardized safety rules that must accompany every interaction utilizing a frame transaction. In solver-based routing ecosystems, a protocol can specify the exact required execution outcome while leaving decentralized solvers free to optimize the execution path. Furthermore, assertions can verify that complex multi-step workflows successfully reach their intended final state, ensuring that unused operational tokens are securely returned to the user and any temporary token approvals are promptly revoked before the block closes.
Help Shape the Design
As research into native transaction assertions continues under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, developers are actively seeking feedback from wallet providers, infrastructure engineers, and protocol architects. Teams interested in exploring these use cases and contributing to the technical research are encouraged to reach out to the initiative or participate in ongoing community discussions through the EIP-7906 development threads.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
