As part of the broader ongoing efforts within the Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers are focusing on two persistent user experience and security risks: blind signing and transaction uncertainty. To combat these vulnerabilities and establish stronger protective boundaries around execution, the ecosystem is actively exploring the implementation of native transaction assertions. Alongside complementary initiatives like Clear Signing, these new mechanisms aim to formally enforce a transaction’s final outcome onchain, providing a safety net where traditional defenses ultimately fall short.
The foundational problem facing Ethereum users lies in the deterministic nature of the Ethereum Virtual Machine (EVM). By design, the EVM executes transactions precisely as they are authorized, strictly processing the requested instructions without evaluating whether the resulting economic or state outcome aligns with the user’s actual intent. When an individual or institution signs a transaction, they are committing to a specific request. However, the final outcome of that request depends entirely on the prevailing contract code and blockchain state encountered during execution. Over the history of the network, users have suffered substantial financial losses either because they unknowingly approved an unintended action or because an intended request yielded an unfavorable, dangerous result.
These security failures generally manifest in two distinct ways: intent mismatches and outcome mismatches. Intent mismatches occur when the transaction presented to a signer differs fundamentally from what they believe they are approving, often due to a compromised user interface or application frontend. High-profile security breaches, such as the Bybit incident and the BadgerDAO attack, underscore this vulnerability. In the Bybit event, signers unwittingly authorized the replacement of a Safe multi-signature wallet’s core implementation contract, while BadgerDAO users unknowingly granted malicious actors sweeping permissions to spend their underlying tokens.
Conversely, outcome mismatches happen when a user signs an authentic request, but market conditions, liquidity constraints, or shifting blockchain states lead to a result that directly conflicts with their economic goals or internal safety policies. A prominent example of this dynamic occurred during a large-scale collateral swap involving Aave and CoW Swap. A user attempted to trade approximately $50.4 million worth of aEthUSDT for aEthAAVE tokens. Due to severely thin liquidity for AAVE at that magnitude, and with CoW’s gas ceiling rejecting more complex routing quotes during verification, only a single verified quote returning roughly 329 aEthAAVE tokens remained viable. Although the user interface displayed a severe 99.9 percent price impact warning and explicitly required confirmation that the entire transaction value could be lost, the user proceeded with the signature and ultimately received tokens valued at roughly $36,000.
In each of these critical scenarios, the core missing element was a trusted, immutable rule governing the resulting state—one defined independently of the transaction builder and rigorously enforced by the protocol layer during execution. Had such a rule been present, Bybit’s signers could have enforced that the approved Safe implementation contract remain entirely unchanged. BadgerDAO users could have restricted new token approvals exclusively to verified, published contracts. Similarly, the Aave user could have established a strict minimum acceptable output calculated independently of the interface quote, ensuring the transaction would automatically revert if market conditions degraded beyond acceptable parameters. Currently, Ethereum lacks 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 an Ethereum user signs a transaction, their signature cryptographically commits to specific parameters, including the target contract address, value, and calldata payload. However, the EVM executes this call against the exact contract code and ledger state present at the precise moment the transaction is included in a block—states that may have shifted dramatically since the moment of signing. Consequently, the resulting net balances, storage modifications, and emitted log events can deviate significantly from initial expectations.
This discrepancy introduces several vectors for unexpected behavior. The target contract, or any secondary contract it interacts with, may rely on proxy patterns where the implementation address changes prior to execution, causing the network to run code different from what the user originally inspected. Furthermore, transaction ordering within a block can alter the state environment. For instance, malicious actors can execute a sandwich attack to manipulate a decentralized exchange liquidity pool’s price immediately before a victim’s swap processes, achieving this manipulation without altering the underlying signed transaction itself.
Where Today’s Defenses Stop
To mitigate these risks, the Ethereum ecosystem has deployed various defensive layers, though each possesses inherent limitations. One primary defense is Clear Signing, which translates complex calldata into human-readable details for the signer. However, Clear Signing relies entirely on accurate data decoding and assumes the signer possesses the attentiveness to recognize when a decoded action diverges from their intended objective.
Another widespread defense is transaction simulation, which predicts the effects of a transaction using a snapshot of the current chain state. Because chain states evolve rapidly before block inclusion, the state during simulation frequently differs from the state at execution. Furthermore, sophisticated malware can actively intercept signing requests on a user’s local machine, substituting a malicious payload at the exact moment of signing while leaving the wallet interface and simulation environment displaying the benign transaction. This exact exploit vector was observed in the security breach suffered by Radiant Capital.
Contract-level checks and wallet guards also attempt to enforce safety rules during EVM execution. For example, decentralized exchanges like Uniswap automatically revert a token swap if the final output falls below a pre-configured amountOutMinimum threshold. Similarly, advanced smart contract wallets like Safe utilize execution hooks, such as checkAfterExecution, to inspect account states after code execution and revert transactions that violate predefined governance or owner policies.
Despite their utility, these existing defensive approaches have notable boundaries. They require developers to anticipate and choose which specific state variables to check in advance. To read the storage values of another contract, these guards are entirely dependent on the specific functions exposed by that contract’s public interface. While checking a token balance via a balanceOf function is straightforward, an upgradeable proxy contract is not required to publicly expose its implementation slot through a standard function call, leaving guards unable to read the address slot directly. Crucially, these isolated checks cannot inspect a transaction’s comprehensive set of net state changes, meaning unintended side effects outside the scope of targeted validations often go completely unnoticed.
How Native Transaction Assertions Work
Native transaction assertions are designed to bridge this security gap by allowing onchain code to inspect the complete set of net state changes after a transaction’s primary actions have finished running. Utilizing read-only logic, an assertion evaluates starting values against final values to ensure they comply with a strict, predetermined rule. If the rule is violated, the transaction execution automatically reverts.
The assertion rule itself is embedded directly within the transaction payload and cryptographically signed alongside its primary actions. These rules can govern net adjustments across native balances, storage slots, newly deployed smart contract code hashes, and emitted log events. By leveraging these rules, users can enforce minimum payout amounts, cap maximum spending permissions, block unauthorized token approvals, preserve account control logic, or restrict execution to an explicitly approved set of state modifications.
However, the provenance of the assertion rule is paramount. If a compromised frontend application writes the assertion rule, it can easily craft a validation parameter that permits the underlying attack. Therefore, a genuinely effective assertion rule must originate from an independently verified user intent, a rigid standing account policy, or underlying protocol logic that malicious intermediaries cannot tamper with or alter.
Three Core Design Choices
The implementation of native transaction assertions introduces complex architectural choices for Ethereum core developers. These decisions revolve around determining what specific ledger information the EVM should expose, how assertion code accesses that information, and where the corresponding instruction opcodes are permitted to run.
Design discussions consider exposing net state changes, emitted events, or both. Access mechanisms range from enumerating individual entries and looking up specific values to copying an entire set of changes directly into contract memory. Additionally, architects must determine whether new opcodes should be restricted exclusively to specialized transaction types or execution phases, or made available generally across the EVM.
EIP-7906 as a Possible Solution
A leading proposal addressing these architectural challenges is Ethereum Improvement Proposal 7906 (EIP-7906), which builds directly upon the frame transaction framework defined in EIP-8141. Under this model, a frame transaction contains a structured, ordered sequence of validation and action steps. EIP-7906 introduces a specialized, read-only POST_TX frame appended to the end of the transaction lifecycle specifically to evaluate the final outcome. While EIP-8141 has advanced toward inclusion in the upcoming Hegotá network upgrade, EIP-7906 has reached the status of "Considered for Inclusion" while research and refinement continue.
The EIP-7906 specification proposes exposing both net state changes and event logs. State alterations are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. For instance, if a specific storage slot is modified five times during a transaction’s execution, the trace reports it as a single entry reflecting only the initial starting value and the final resulting value. If a storage slot ultimately reverts to its original value by the end of the transaction, it is omitted entirely.
To interact with this data, the proposal outlines three new EVM instructions, or opcodes. The TXTRACE opcode enumerates net state changes and emitted events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies specific event log data directly into memory.
These opcodes are strictly restricted to operate within the POST_TX frame, which executes at the conclusion of the transaction as a static call to ensure the assertion cannot alter state during its inspection. If an assertion rule fails, the entire execution body of the transaction reverts, but the transaction record remains permanently logged onchain with a failed execution status. Crucially, the gas payer is still charged for the total gas consumed up to that point. This economic enforcement prevents malicious actors from spamming network builders with deliberately failing transactions for free.
The Assertion Has to Be Required
A key structural nuance of EIP-7906 is that it does not inherently force every standard transaction on Ethereum to include an assertion, meaning transaction builders retain the technical capability to omit them. Consequently, ecosystem infrastructure must adapt to enforce their usage.
For transactions initiated by individual end-users, cryptocurrency wallets must shoulder the responsibility of ensuring that every constructed frame transaction automatically incorporates the necessary assertion. These rules can be derived dynamically from automated transaction simulations executed locally by the wallet or governed by persistent security policies established by the user.
For decentralized protocols and smart contract applications, protected functions must be coded to verify that incoming calls originate exclusively from frame transactions carrying the exact required assertions. Contracts must systematically reject ordinary transactions as well as frame transactions that feature missing or malformed assertions. Consequently, callers and downstream integrations must adopt compatible frame transaction formats, meaning already deployed, immutable smart contracts cannot retroactively add this validation check without architectural upgrades.
Where Transaction Assertions Could Help
Beyond mitigating conventional security exploits, native transaction assertions offer broad utility across various emerging paradigms within the Ethereum ecosystem. For example, assertions can significantly strengthen account delegation and automated agent workflows. When an individual grants an autonomous agent permissions to act on their behalf, they typically constrain which contracts the agent can access, how much capital it can expend, and the duration of its operational permissions. Transaction assertions introduce an additional layer of constraint by governing the exact economic and state outcomes of each individual transaction, allowing users to tightly control both the actions taken by an agent and the resulting state produced.
Protocols can also define standardized validation rules, requiring uniform safety checks for every participant interacting through a compatible frame transaction. In solver-based execution architectures, a protocol can specify the precise required outcome while granting solvers the flexibility to determine the optimal routing path to achieve it. However, because transaction assertions operate within the boundaries of a single transaction on a single network, these guarantees do not natively extend across cross-chain execution bridges. Additionally, assertions can verify that complex multi-step workflows successfully reach their intended terminal states, ensuring unused tokens are automatically returned to the user and any remaining temporary token spending approvals are revoked.
Help Shape the Design
Research and development surrounding native transaction assertions remain active under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative. Core contributors are actively seeking feedback and collaboration from wallet providers, application developers, and protocol teams who would ultimately rely on these features in production. Interested stakeholders can connect with researchers via email at [email protected] to explore practical use cases, or participate directly in the ongoing technical discussions on the Ethereum Magicians forum via the EIP-7906 discussion thread. Additional information regarding ongoing risk control initiatives and priority development areas is available at trilliondollarsecurity.org.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
