The Ethereum Foundation’s Trillion Dollar Security initiative has flagged blind signing and transaction uncertainty as critical user experience and safety risks facing the ecosystem. As part of its ongoing efforts to harden network security alongside developments like Clear Signing, the foundation is actively exploring native transaction assertions as a fundamental next step to enforce the final, desired outcomes of onchain transactions.
The core issue stems from a fundamental characteristic of how Ethereum operates: the network executes instructions precisely as they are authorized, without making any value judgment about whether the ultimate result aligns with the user’s actual intentions. While a cryptographic signature acts as an immutable commitment to a specific request, the execution outcome depends entirely on the dynamic code and state conditions encountered when the transaction hits the blockchain. Over the history of the network, users have suffered significant financial losses either because they mistakenly approved actions differing from their beliefs, or because their intended requests produced outcomes that clashed with their economic goals.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize these transaction failures into two distinct scenarios: intent mismatches and outcome mismatches.
An intent mismatch occurs when a compromised or malicious frontend supplies a signing request that diverges completely from what the user thinks they are approving. Prominent historical examples include the high-profile Bybit incident and the BadgerDAO attack. In the Bybit breach, signers unwittingly authorized the replacement of a Safe multi-sig implementation contract, while BadgerDAO users unknowingly granted malicious actors sweeping permissions to drain their tokens. In both situations, the cryptographic signature was valid, but the underlying intent was fundamentally hijacked at the interface level.
The second category, an outcome mismatch, happens when a signer fully approves the exact request presented to them, but the prevailing market limits or state conditions at execution still trigger a result that violates their economic strategy. A clear illustration of this is the Aave and CoW collateral swap incident. In that event, a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was vastly insufficient for a trade of that magnitude, and because CoW’s gas ceiling rejected complex quotes during verification, only a single verified quote returning roughly 329 aEthAAVE remained. Although the user interface flashed a severe 99.9 percent price impact warning and forced a manual confirmation acknowledging potential total loss, the user proceeded to sign the transaction anyway, ultimately receiving tokens valued at a mere $36,000.
In all three scenarios, the missing safeguard was a trusted rule governing the resulting state—one defined independently of the transaction builder and strictly enforced during execution. In the Bybit case, such a rule would have mandated that the approved Safe implementation contract remain entirely immutable. For a BadgerDAO user, a protective rule would have restricted new token spending allowances exclusively to verified, published protocol contracts. For the Aave swap, a hard boundary would have established a minimum acceptable output calculated independently of the interface’s displayed quote. However, Ethereum has historically lacked a generalized mechanism for onchain code to inspect the full scope of net state changes and emitted events produced by a single transaction.
What a Signature Does Not Control
When a user signs a transaction, their signature strictly commits to the requested action parameters, including the target contract, value, and raw calldata. However, the Ethereum Virtual Machine (EVM) executes this call against whatever contract code and state happen to be present at the exact moment the transaction is processed onchain, which may have shifted drastically since the moment of signing. Consequently, the resulting net balance alterations, storage modifications, and emitted events can diverge wildly from expectations.
The target contract, or any secondary contract it interacts with, may utilize a proxy pattern whose implementation address is updated prior to execution, meaning the code actually running onchain differs entirely from what the user originally audited. Furthermore, transaction ordering creates vulnerabilities such as sandwich attacks, where malicious actors manipulate liquidity pool prices right before a user’s swap executes without altering a single byte of the user’s signed transaction.
Where Today’s Defenses Stop
The ecosystem currently relies on several defensive layers, though each has inherent limitations. Clear Signing initiatives strive to translate raw calldata into human-readable descriptions, but they depend entirely on accurate decoding logic and rely on the user to manually spot discrepancies between the displayed action and their actual intent.
Transaction simulation offers another layer of protection by predicting effects against a selected snapshot of chain state. Nevertheless, chain state can change before inclusion, and malware on a signer’s local machine can swap out a legitimate payload for a malicious one after simulation completes. In the case of Radiant Capital, both wallet interfaces and simulation tools displayed the correct, intended transaction, while local endpoint malware substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also enforce rules during EVM execution. Uniswap, for example, utilizes an amountOutMinimum parameter to automatically revert a swap if the output falls short. Similarly, Safe accounts employ a checkAfterExecution hook allowing custom guards to inspect account states post-execution and revert transactions that violate safety parameters.
Despite their utility, these existing mechanisms require developers to anticipate and choose which specific state variables to check in advance. Reading another contract’s storage depends entirely on the public functions that contract chooses to expose. While a standard token’s balanceOf function makes balance verification straightforward, a proxy contract is not obligated to expose its implementation slot via a public getter function, leaving guards blind to underlying changes. Crucially, these defenses cannot inspect a transaction’s full net state changes comprehensively, meaning unforeseen effects can easily slip past unchecked.
How Native Transaction Assertions Work
Native transaction assertions aim to bridge this gap by allowing onchain code to inspect the complete set of net state changes after all transaction actions have fully executed. Utilizing read-only logic, an assertion compares starting state values against final state values according to a predetermined rule. If the outcome violates the rule, the entire transaction reverts.
This rule is embedded directly within the transaction data structure and cryptographically signed alongside its core actions. It can encompass net modifications to native balances, storage slots, newly deployed contracts, and emitted events. Effectively, it can enforce minimum received amounts, cap spending limits, block unauthorized token approvals, preserve account control logic, or restrict execution to an explicitly whitelisted set of state changes.
The origin of the assertion rule is paramount. If a compromised frontend interface were allowed to write the assertion, it could easily craft a rule that permits an attack. Therefore, a genuinely secure rule must originate from independently verified user intent, a standing account policy, or hardcoded protocol logic that malicious frontend components cannot tamper with.
Three Design Choices
Implementing native transaction assertions at the protocol level requires navigating complex architectural decisions regarding the exact information the EVM exposes, how assertion code interacts with that data, and where the associated opcodes are permitted to execute. Core developers must decide whether information should encompass state modifications, event logs, or both. Access mechanisms might involve enumerating entries, querying specific values, or copying entire change sets into memory. Additionally, the execution scope of these new opcodes must be carefully defined, determining whether they should be restricted to specific transaction types or permitted broadly across the EVM.
EIP-7906 as a Possible Solution
One prominent approach currently under discussion is Ethereum Improvement Proposal 7906 (EIP-7906), which builds directly upon the frame transactions framework introduced in EIP-8141. While EIP-8141—scheduled for the Hegotá upgrade—structures transactions into an ordered sequence of validation and action steps, EIP-7906 introduces a dedicated, read-only POST_TX frame situated at the very end of the transaction lifecycle to verify final outcomes. Although EIP-7906 has advanced to a "Considered for Inclusion" status, it is not yet officially confirmed for the upcoming upgrade.
Under this proposed design, state changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. A storage slot that undergoes multiple writes during execution is reported as a single consolidated entry detailing its initial and final values. If a slot ultimately reverts to its original value by the end of the transaction, it is omitted entirely.
Access to this telemetry is provided via three newly introduced EVM instructions, or opcodes. The TXTRACE opcode enumerates net state changes and events, TXDIFF retrieves starting and final values for targeted addresses and storage slots, and EVENTDATACOPY copies event log data directly into memory.
Crucially, these opcodes function exclusively within the POST_TX frame, executing as a static call at the conclusion of the transaction. This ensures the assertion can thoroughly inspect outcomes without introducing state mutation side effects. If a rule violation is detected, the entire execution body reverts, yet the transaction remains recorded on the blockchain with a failed status, and the gas payer is charged for all consumed gas. This economic enforcement prevents malicious actors from spamming network builders with deliberately failing transactions at no cost.
The Assertion Has to Be Required
Because EIP-7906 does not mandate that every transaction include an assertion, transaction builders retain the technical capability to omit them entirely. Consequently, wallet providers must enforce that every frame transaction they construct incorporates the necessary security assertions, drawing rules either from verified local simulations or standing user policies.
Similarly, decentralized protocols wishing to protect their users must update their smart contracts to verify that incoming calls originate from frame transactions carrying the exact required assertion. Protected functions would need to explicitly reject legacy transactions as well as frame transactions with missing or improperly configured assertions. As a result, integrations and callers would need to adopt compatible frame transactions, and already deployed immutable contracts would be unable to natively integrate this specific check without proxy upgrades.
Where Transaction Assertions Could Help
Beyond baseline user and protocol security, native transaction assertions open up robust possibilities across various Web3 use cases. For instance, they could significantly strengthen automated delegation systems. When users authorize autonomous agents to act on their behalf, they can restrict target contracts, spending limits, and permission durations. Assertions would add enforceable outcome constraints, allowing users to tightly govern not just what an agent is permitted to do, but what its actions are allowed to produce.
Protocols could likewise define standardized safety rules enforced across all callers utilizing frame transactions. In solver-based execution models, a protocol could specify the required economic outcome while giving solvers the flexibility to determine the routing path. Furthermore, assertions could verify that complex multi-step workflows reach intended final states, ensuring unspent assets are returned and dangling token approvals are automatically revoked before final settlement.
Help Shape the Design
Research and development surrounding native transaction assertions continue under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Foundation researchers are actively seeking feedback from wallet developers, protocol engineers, and security professionals interested in adopting these primitives. Stakeholders can connect via email or participate directly in community development discussions to help shape the trajectory of these security enhancements.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
