As the blockchain ecosystem scales toward securing a trillion dollars in value, the Ethereum Foundation’s Trillion Dollar Security initiative has spotlighted critical vulnerabilities surrounding blind signing and transaction uncertainty. In response to these persistent user experience risks, core researchers and developers are actively exploring the implementation of native transaction assertions. This proposed mechanism aims to enforce a transaction’s final outcome directly at the protocol level, working alongside Clear Signing initiatives to protect everyday users and sophisticated protocols alike from unexpected execution results.
The underlying issue stems from a fundamental design characteristic of Ethereum: the Ethereum Virtual Machine (EVM) executes instructions precisely as authorized, without evaluating whether the net result aligns with the user’s actual intent. When a user signs a transaction, they are committing to a specific request, but the final outcome remains vulnerable to external factors like changing blockchain state and smart contract logic encountered during execution. Over the history of the network, significant funds have been lost not only because individuals approved malicious parameters they did not understand, but also because perfectly valid requests produced unintended outcomes due to volatile market conditions or frontrunning.
Understanding these vulnerabilities requires examining how signed transactions can go wrong in practice. Incidents across the decentralized finance ecosystem generally fall into distinct categories, highlighting the urgent need for more robust execution boundaries.
Two ways a signed transaction can go wrong
The first major failure mode is an intent mismatch, a phenomenon vividly illustrated by major security breaches such as the Bybit incident and the BadgerDAO attack. In both of these high-profile events, compromised frontend interfaces supplied signing requests that differed substantially from what users believed they were authorizing. During the Bybit security event, affected signers unwittingly authorized the replacement of a Safe multi-sig implementation contract. Similarly, users interacting with BadgerDAO granted malicious actors sweeping permissions to spend tokens from their personal wallets.
The second major failure mode is an outcome mismatch. In these scenarios, the signer approves the exact request presented by the user interface, but underlying execution limits or shifting network states produce a result that directly conflicts with the user’s economic goals or pre-established safety policies. A striking example occurred during a massive collateral swap involving Aave and CoW Swap, where a user attempted to exchange approximately $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was far too shallow to support a trade of that magnitude, and CoW’s gas ceiling rejected complex quotes during verification, only a single verified quote of roughly 329 aEthAAVE remained. Although the user interface displayed a severe 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 roughly $36,000.
What links these disparate security failures is the complete absence of a trusted, immutable rule governing the resulting state—one defined entirely independently of the transaction builder and enforced natively during execution. Had a robust rule been in place during the Bybit breach, it would have legally required the approved Safe implementation contract to remain completely unchanged. For BadgerDAO users, a standing rule would have automatically restricted new token approvals strictly to verified and published Badger contracts. In the Aave collateral swap scenario, an enforceable rule could have established a rigid minimum acceptable output calculated independently of the specific quote displayed by the interface, provided that the underlying solver-based protocol supported such checks. Currently, however, Ethereum lacks a general mechanism that allows onchain code to inspect the full scope of net state changes and emitted events produced by a single transaction before it settles.
What a signature does not control
When a user signs an Ethereum transaction, their signature creates a cryptographic commitment to a specific action, including the designated recipient target, transferred value, and execution calldata. However, the EVM evaluates this call against whatever contract code and blockchain state exist at the precise moment the transaction is included in a block—conditions that may have shifted dramatically since the moment of signing. Consequently, the resulting net balance modifications, storage updates, and transaction events can diverge sharply from user expectations.
The target contract specified in a transaction, or any other contract it subsequently calls, may utilize a proxy pattern whose underlying implementation changes unexpectedly before execution takes place. This means the actual code executed can differ from what the user inspected during the signing process. Furthermore, transaction ordering within a block introduces significant unpredictability. Techniques like sandwich attacks can manipulate a liquidity pool’s price right before a swap executes, altering the economic reality of the trade without requiring any modification to the user’s signed transaction payload.
Where today’s defenses stop
The Ethereum community has deployed several defenses to mitigate these risks, yet each possesses inherent limitations. Clear Signing initiatives strive to make calldata human-readable so users understand the exact parameters of an action, but they rely heavily on accurate decoding and assume the signer will notice discrepancies between the translated request and their true intent.
Simulation tools represent another widely adopted defense, predicting a transaction’s downstream effects using a specific snapshot of the chain state. Because chain states constantly fluctuate before block inclusion, the actual execution environment can differ from the simulation environment. In the security breach suffered by Radiant Capital, for instance, both the native wallet interface and third-party simulation tools accurately displayed the intended transaction, while malware operating locally on the signers’ machines silently substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet guards also enforce specific rules during EVM execution. Protocols like Uniswap automatically revert a swap if the final output falls below a pre-set amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook that empowers a designated security guard to inspect the account’s state following execution and revert transactions that violate configuration or ownership policies. However, both of these methodologies require developers to choose which specific state variables to check in advance. To read another contract’s storage, they remain entirely dependent on the specific functions that contract chooses to expose publicly. While checking a standard token’s balanceOf function is straightforward, a proxy contract is not obligated to expose its implementation address through a public getter function. Without such an accessible interface, a traditional security guard cannot read the implementation slot directly.
Crucially, these conventional checks remain fundamentally incapable of inspecting a transaction’s comprehensive set of net state changes. While a guard can easily verify that a specific token balance remains untouched, it cannot query the EVM to discover what else may have changed during execution, leaving unintended side effects entirely undetected.
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 immediately 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 predefined rule. If the rule fails, the entire transaction reverts.
Under this model, the governing rule is embedded directly into the transaction payload and signed alongside its execution actions. These rules can encompass net modifications to native balances, storage slots, and code execution, as well as newly deployed contracts and emitted event logs. They can enforce strict financial boundaries—such as requiring a minimum token receive amount, capping total spending, blocking unauthorized token approvals, preserving account control logic, or permitting only a precisely specified set of state alterations.
However, the provenance of the rule matters just as much as the verification logic itself. If a compromised frontend interface is allowed to write the assertion rule, it can easily craft an assertion that explicitly permits the attack it intends to execute. Therefore, a genuinely useful security rule must originate from an independently verified user intent, a strict standing account policy, or core protocol logic that a compromised component cannot tamper with.
Three design choices and EIP-7906
Implementing native transaction assertions at the protocol level requires addressing several core design decisions regarding what information the EVM exposes, how assertion code accesses that data, and where the associated opcodes are permitted to execute. Developers must determine whether the exposed information should include state changes, event logs, or both. Access mechanisms might involve enumerating entries, querying specific values, or copying the full set of state changes directly into memory. Additionally, architects must decide whether the new opcodes should be restricted to specific transaction types and execution phases or made broadly available across the EVM.
A prominent approach currently under active consideration is EIP-7906, which builds directly upon the frame transactions introduced in EIP-8141. While a frame transaction structures an ordered sequence of validation and action steps, EIP-7906 introduces a dedicated, read-only POST_TX frame positioned at the very end of the transaction lifecycle specifically to evaluate the final outcome. Current development schedules place EIP-8141 under consideration for the Hegot upgrade, while EIP-7906 has advanced to "Considered for Inclusion," though its formal inclusion remains unconfirmed.
The architectural 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 contracts and their corresponding code hashes. For instance, a storage slot that is written to multiple times throughout a transaction is reported as a single entry reflecting only its initial and final values. If a storage slot ultimately reverts to its original value by the end of execution, it does not appear in the trace at all.
Access to this detailed telemetry is facilitated by three new EVM opcodes. TXTRACE enumerates net state changes and generated events, TXDIFF retrieves starting and final values for specific addresses and storage slots, and EVENTDATACOPY copies event data directly into memory. These specialized opcodes function exclusively within a POST_TX frame operating as a static call at the conclusion of the transaction. This ensures that the assertion can inspect execution outcomes without introducing unintended state modifications. If the security rule is violated, the entire execution body reverts, but the transaction remains permanently 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 forcing network builders to execute deliberately failing transactions for free.
Operational requirements and broader use cases
A critical hurdle in the implementation of EIP-7906 is that transactions are not inherently forced to include an assertion, meaning transaction builders retain the technical ability to omit them entirely. To protect user transactions, wallets must autonomously ensure that every frame transaction they construct incorporates the necessary assertion, deriving the required rule either from a local simulation or from a mandatory standing security policy.
Furthermore, protocols wishing to leverage this technology must implement protected functions that explicitly verify that incoming calls originate from a frame transaction containing the exact required assertion, rejecting ordinary transactions and improperly guarded frame transactions alike. Consequently, callers and integrations must adopt compatible frame transactions, meaning already deployed immutable contracts cannot retroactively incorporate this specific verification check.
Beyond mitigating blind signing and frontrunning risks for individual users and protocols, native transaction assertions unlock powerful new capabilities across the broader ecosystem. They can significantly strengthen delegation frameworks by allowing users to constrain agent accounts not only by limiting which contracts they can access and how much they can spend, but also by legally enforcing boundaries on what the agent’s actions must ultimately produce.
Protocols can also define standardized rules requiring identical safety checks for every caller utilizing a frame transaction. In solver-based execution architectures, for example, a protocol can specify the mandatory minimum outcome while granting solvers the freedom to determine the optimal routing path locally. However, this guarantee remains strictly bounded to a single transaction on a single network, offering no cross-chain protections. Additionally, assertions can verify that complex multi-step workflows successfully reach their intended final state, ensuring that any residual unused tokens are properly returned to the user and all lingering token approvals are automatically revoked before settlement.
As research and development surrounding native transaction assertions continue under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, core contributors are actively seeking feedback from wallet developers, infrastructure providers, and protocol teams. Stakeholders interested in exploring practical use cases and contributing to ongoing research can connect directly with the initiative or participate in the public EIP-7906 discussion threads to help shape the future of Ethereum’s execution security.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
