As part of the ongoing Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers have identified blind signing and transaction uncertainty as critical user experience and security risks facing the ecosystem. To address these vulnerabilities, the initiative is actively exploring native transaction assertions as a powerful next step to enforce a transaction’s final outcome. Working alongside complementary measures like Clear Signing, these proposed native rules aim to bridge a fundamental gap in how Ethereum transactions execute, providing safety nets where traditional wallet defenses and contract-level checks currently fall short.
This initiative dives deeply into why a cryptographically valid signature does not always guarantee the desired transaction result. By examining potential solutions such as EIP-7906, which introduces transaction assertions via a state diff opcode, researchers hope to give users and protocols absolute authority over the net state changes and economic realities produced by onchain actions.
Two Ways a Signed Transaction Can Go Wrong
The core structural challenge stems from the fundamental design of the Ethereum Virtual Machine (EVM). Ethereum executes transactions precisely as they are authorized, operating without intrinsic judgment regarding whether the ultimate outcome aligns with the user’s actual intent. While a signature serves as a binding commitment to a request, the final result depends entirely on the code and network state encountered at the exact moment of execution. Over the history of the network, users have suffered significant financial losses either because they approved a request that differed from what they believed they were signing, or because an intended request yielded an economic outcome that clashed with their objectives.
The first category of failure involves an intent mismatch, a danger vividly illustrated by high-profile security incidents such as the Bybit compromise and the BadgerDAO attack. In both of these events, compromised user interfaces or frontends supplied signing requests that deviated substantially from what the users thought they were approving. During the Bybit incident, signers inadvertently authorized the replacement of their Safe account’s underlying implementation contract. Similarly, BadgerDAO users granted malicious actors broad permissions to drain their token balances.
The second major category is an outcome mismatch. In these scenarios, the signer legitimately approves the exact request presented to them, but existing parameters or fluctuating network states permit an execution result that violates their economic goals or standing risk policies. A striking example occurred during an Aave and CoW collateral swap. A user attempted to trade roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE market liquidity was exceedingly thin for a trade of that magnitude, and because CoW’s gas ceiling mechanism rejected more complex quotes during verification, only a single verified quote yielding roughly 329 aEthAAVE remained viable. Although the interface displayed a dramatic 99.9 percent price impact warning and required explicit confirmation that the entire value could be lost, the user signed the transaction anyway and ultimately received tokens valued at only about $36,000.
Analyses of these events reveal a common thread: all three scenarios lacked a trusted, independent rule governing the resulting state—a rule defined separately from the transaction builder and strictly enforced during execution. In the Bybit incident, a protective rule would have mandated that the approved Safe implementation contract remain unchanged. For BadgerDAO users, a rule would have restricted new token approvals exclusively to officially published protocol contracts. In the Aave trade, a custom rule could have established a strict minimum acceptable output calculated independently of the interface quote, requiring both the signed order and the settlement protocol to uphold that constraint. Currently, however, Ethereum lacks a generalized mechanism enabling onchain code to inspect the full scope of net state changes and events generated 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, encompassing the target address, value transfer, and specific calldata payload. However, the EVM executes this call against the exact contract code and blockchain state present at the moment of inclusion, which may have shifted significantly since the moment of signing. Consequently, the resulting net balance adjustments, storage modifications, and emitted events can diverge widely from initial expectations.
The target contract—or any auxiliary contract it interacts with—may rely on proxy architecture whose implementation address changes prior to execution, meaning the code that ultimately runs can differ from what the user originally inspected. Furthermore, transaction ordering within a block can drastically alter the state encountered by a call. A classic example is a sandwich attack, where malicious front-running and back-running transactions manipulate a liquidity pool’s price immediately before a user’s swap executes, all without altering the contents of the user’s signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several important defenses to mitigate these risks, yet each possesses inherent limitations. One primary defense is Clear Signing, which translates raw calldata into human-readable terms for the user. However, Clear Signing relies entirely on accurate decoding and assumes the signer can reliably recognize if the presented action deviates from their intent.
Another common defense is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. Because chain state can change before inclusion, the transaction ultimately included in a block may differ from the one originally simulated. A stark illustration of this vulnerability occurred during the Radiant Capital exploit, where both the wallet interface and the simulation accurately displayed the intended transaction, but malware running locally on the user’s machine substituted a malicious payload at the precise moment of signing.
Contract-level checks and wallet guards also enforce specific rules during EVM execution. For instance, Uniswap automatically reverts a token swap if the final output falls below a pre-specified minimum amount. Similarly, Safe accounts utilize execution hooks like checkAfterExecution to inspect account state after execution and revert transactions that violate established rules regarding owners or system configuration.
Nevertheless, these existing approaches require developers to choose which specific state variables to check in advance. To read another contract’s storage, they depend entirely on the specific functions exposed by that contract. While checking a token balance via balanceOf is straightforward, a proxy contract is not required to expose its implementation address through a standard function. Without a direct interface, a guard cannot read the implementation storage slot directly. Crucially, these legacy checks cannot inspect the transaction’s complete set of net state changes. While a guard can verify that a specific balance remains untouched, it cannot query the EVM regarding other unforeseen modifications, leaving unexpected side effects undetected.
How Native Transaction Assertions Work
Native transaction assertions propose a transformative architecture that would allow onchain code to inspect the full set of net state changes after a transaction’s primary actions have finished executing. Utilizing read-only logic, an assertion compares starting and final values against a predefined set of rules. If the rule evaluation fails, the entire transaction reverts.
The assertion rule itself is embedded directly within the transaction and signed alongside its execution actions. These rules can comprehensively cover net changes to native ETH balances, contract storage, code deployments, newly deployed contracts, and emitted events. They can enforce strict parameters, such as requiring a minimum token payout, capping maximum spending, blocking unauthorized token approvals, preserving account control logic, or permitting only a specified whitelist of state modifications.
However, the provenance of the rule matters just as much as the validation mechanism itself. A compromised frontend or malicious actor could theoretically write an assertion that accommodates an attack rather than preventing it. Therefore, a genuinely useful assertion rule must originate from independently verified user intent, a standing account policy, or resilient protocol logic that a compromised interface cannot manipulate or bypass.
Three Design Choices
Implementing native transaction assertions at the protocol level requires complex decisions regarding what information the EVM exposes, how assertion code accesses that data, and where the necessary opcodes are permitted to run. Core design considerations include determining whether the exposed data should encompass state changes, events, or both. Access mechanisms must also be defined, ranging from enumerating individual entries and looking up specific values to copying the complete set of changes directly into memory. Additionally, developers must decide whether the new opcodes should be restricted to specialized transaction types and execution phases or made broadly available throughout the EVM.
EIP-7906 as a Possible Solution
A prominent proposal addressing these challenges is EIP-7906, which builds upon the frame transactions defined in EIP-8141. Under this framework, a frame transaction contains an ordered sequence of distinct validation and action steps. EIP-7906 introduces a read-only POST_TX frame situated at the very end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has advanced toward inclusion in upcoming network upgrades, EIP-7906 remains under active evaluation as developers weigh its specifications.
The EIP-7906 design exposes both state changes and event logs. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. For instance, a storage slot that is written to multiple times during execution appears as a single consolidated entry detailing its starting and final values. 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.
Three proposed opcodes provide access to this data within the execution environment. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies event data directly into memory. These opcodes function exclusively within the POST_TX frame, executing as a static call at the conclusion of the transaction to inspect outcomes without altering state. If an assertion rule is violated, the entire execution body reverts, but the transaction remains recorded on-chain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement prevents malicious actors from spamming block builders with deliberately failing transactions for free.
The Assertion Has to Be Required
Because EIP-7906 does not universally mandate that every transaction include an assertion, transaction builders retain the technical ability to omit them. Consequently, user wallets must ensure that every frame transaction they construct incorporates the necessary assertions, drawing rules either from recent simulations or from persistent account policies governing all outgoing activity.
Similarly, protocol-level protection requires smart contracts to verify that incoming calls originate from frame transactions containing the exact required assertions. Protected functions must reject ordinary transactions as well as frame transactions carrying missing or incorrect assertions. Consequently, callers and ecosystem integrations must adopt compatible frame transaction standards, noting that already deployed, immutable smart contracts cannot retroactively add this validation layer.
Where Transaction Assertions Could Help
Beyond fortifying security for individual users and smart contract protocols, native transaction assertions unlock broader functional use cases. For example, they could significantly strengthen automated delegation systems. When granting an autonomous agent permission to act on a user’s behalf, account holders typically restrict which contracts the agent can interact with, how much capital it may spend, and how long its permissions remain active. Transaction assertions introduce an additional layer of constraint, enabling users to dictate precise rules regarding the economic outcomes of each transaction executed by the agent.
Protocols can likewise define custom rules requiring uniform safety checks for any caller utilizing a frame transaction. In solver-based execution architectures, a protocol could specify the required final outcome while granting solvers the flexibility to determine the optimal execution route. Although this guarantee applies strictly within a single transaction on a single network—and thus cannot span multi-chain bridges—assertions can successfully verify that complex workflows reach their intended final state, ensuring unused tokens are properly returned and lingering approvals are revoked.
Help Shape the Design
Research and development surrounding native transaction assertions continue to evolve under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Researchers are actively seeking feedback and collaboration from wallet developers, security researchers, and protocol teams who would ultimately rely on these mechanisms. Interested contributors can reach out via email to explore use cases and help shape ongoing research, or participate in the public EIP-7906 discussion channels. Additional information regarding ongoing risk controls and priority initiatives can be found through official initiative portals.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
