As part of the ongoing Ethereum Foundation’s Trillion Dollar Security initiative, core researchers and developers are examining advanced cryptographic and protocol-level solutions to address persistent user experience vulnerabilities, specifically blind signing and transaction uncertainty. To safeguard users against unexpected outcomes, the initiative is actively exploring native transaction assertions as a crucial next step. These programmatic guardrails are designed to enforce a transaction’s final outcome directly at the protocol level, working in tandem with broader ecosystem efforts like Clear Signing.
The core motivation behind this research is a fundamental reality of how the Ethereum Virtual Machine operates. The EVM executes instructions precisely as they are authorized, without evaluating whether the net result aligns with the user’s actual economic or operational intentions. While a cryptographic signature legally commits a user to a specific request, the ultimate outcome depends heavily on the prevailing smart contract code and ledger state encountered at the exact moment of execution. Over the history of the network, significant capital has been lost not only because users mistakenly authorized malicious requests, but also because intended transactions produced unintended, adverse results due to dynamic onchain variables.
Two Ways a Signed Transaction Can Go Wrong
Security analysts generally categorize these execution failures into two distinct phenomena: intent mismatches and outcome mismatches. The first category involves discrepancies between what a user believes they are authorizing and the actual payload submitted to the network. High-profile security breaches, such as the Bybit incident and the BadgerDAO attack, underscore this vulnerability. In both instances, compromised frontends or malicious execution environments supplied signing requests that radically differed from user expectations. During the Bybit security event, affected signers inadvertently authorized the replacement of a Safe multi-signature wallet’s core implementation contract. Similarly, BadgerDAO users unknowingly granted malicious actors sweeping allowances to drain their token balances.
The second category, an outcome mismatch, occurs when a signer accurately authorizes a valid request, but external conditions, liquidity limitations, or underlying protocol state variables yield an economic result that directly conflicts with the user’s objectives. A prominent example of this dynamic played out in the Aave and CoW collateral swap event. In that scenario, a user initiated a transaction to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Due to thin liquidity pools for AAVE at that magnitude, coupled with gas ceiling constraints during CoW’s verification process that rejected more complex quotes, only a single verified quote of roughly 329 aEthAAVE remained viable. Although the user interface displayed a severe 99.9 percent price impact warning and required explicit confirmation that the entire value could be jeopardized, the transaction proceeded, resulting in an execution yielding a fraction of the intended value.
In each of these notable security failures, the missing architectural component was a trusted, immutable rule governing the resulting state—one defined independently of the transaction builder and strictly enforced during execution. If Bybit’s signers had access to a programmatic rule preventing unauthorized implementation changes, the breach would have been blocked. If BadgerDAO users could have enforced token approval boundaries tied strictly to verified protocol contracts, the drain would have failed. Likewise, an automated assertion safeguarding the Aave trade could have enforced a strict minimum acceptable output independent of interface displays. Currently, however, Ethereum lacks a generalized native mechanism allowing onchain code to inspect the full aggregate net state changes and emitted events produced within a single transaction before final settlement.
What a Signature Does Not Control
To understand why these vulnerabilities persist, it is essential to examine the precise limitations of an Ethereum signature. When a user signs a transaction, they cryptographic commit to specific parameters, including the target address, value payload, and calldata. However, the EVM executes this call against whatever contract code and storage state happen to be active when the transaction is processed by block builders. Because ledger conditions fluctuate constantly, the resulting balance shifts, storage modifications, and emitted logs frequently diverge from initial expectations.
This discrepancy is driven largely by proxy patterns and transaction ordering mechanics. Many modern smart contracts utilize proxy architectures where the underlying implementation logic can be upgraded or altered prior to execution, meaning the code that ultimately runs may differ significantly from what the user initially inspected. Furthermore, adversarial transaction ordering—such as frontrunning or sandwich attacks—can manipulate automated market maker pool prices or state variables immediately before a user’s transaction settles, completely altering the financial outcome without changing a single byte of the signed calldata.
Where Today’s Defenses Stop
The Ethereum ecosystem has deployed several important defense mechanisms to mitigate these risks, but each possesses inherent boundaries. Clear Signing initiatives strive to translate raw calldata into human-readable intent, though their effectiveness relies entirely on accurate decoder logic and the user’s ability to spot anomalies. Transaction simulation tools attempt to predict outcomes against a specific snapshot of chain state, but state can shift between simulation and block inclusion, and sophisticated malware can swap payloads on a user’s local machine right at the moment of signing, as observed in the Radiant Capital post-mortem.
At the execution level, protocol guards and contract-level checks offer additional safety nets. Decentralized exchanges like Uniswap utilize parameters such as amountOutMinimum to automatically revert swaps if slippage thresholds are breached, while multi-signature frameworks like Safe employ post-execution hooks to inspect account states and rollback unauthorized configuration changes. Yet, these traditional approaches require developers to anticipate and hardcode specific state variables in advance. They rely entirely on exposed functions—such as a token’s balanceOf—and struggle to verify hidden storage slots like proxy implementation addresses without explicit interface support. Crucially, these existing defenses cannot inspect the comprehensive set of net state changes produced across an entire transaction, leaving complex secondary effects vulnerable to exploitation.
How Native Transaction Assertions Work
Native transaction assertions represent a paradigm shift by enabling 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 ledger values against final outcomes measured against a predetermined rule. If the execution violates the specified rule, the transaction automatically reverts.
Crucially, these assertion rules are bundled directly into the transaction and cryptographically signed alongside the primary actions. They can govern net changes across native balances, storage slots, contract code, newly deployed contracts, and emitted event logs. An assertion can enforce rigid economic parameters—such as guaranteeing a minimum token output, capping total spending, blocking unexpected token approvals, or preserving account control logic. However, security researchers emphasize that the origin of the rule is just as vital as the check itself; if a compromised frontend interface generates the assertion, it could easily be manipulated to permit an attack. Therefore, viable rules must originate from independently verified user intent, standing account policies, or immutable protocol logic beyond the reach of compromised intermediaries.
EIP-7906 as a Possible Solution
Among the architectural proposals currently under consideration, Ethereum Improvement Proposal (EIP-7906) stands out as a leading technical approach. Building directly upon the frame transactions defined in EIP-8141, EIP-7906 introduces a specialized, read-only POST_TX execution frame positioned at the very end of a transaction to evaluate its overall outcome. While EIP-8141 has advanced toward inclusion in the upcoming Hegot network upgrade, EIP-7906 currently holds a "Considered for Inclusion" status as research and community discussions continue.
The EIP-7906 framework exposes comprehensive net state changes and emitted events to the execution environment. State modifications are reported as net differences in native ETH balances and storage slots, alongside details of newly deployed contracts and their respective code hashes. To optimize efficiency, repeated modifications to a single storage slot are consolidated into a single entry comparing initial and final values, while slots that return to their original state are omitted entirely.
To interact with this data, the proposal introduces three new EVM opcodes. The TXTRACE instruction enumerates net state changes and events, TXDIFF retrieves specific starting and final values for designated addresses and storage slots, and EVENTDATACOPY copies event log data directly into memory. Operating exclusively within the static POST_TX frame, these instructions allow assertion logic to inspect outcomes without risking unintended state mutations. If an assertion fails, the primary execution body reverts entirely, but the transaction remains recorded onchain with a failed status, ensuring that block builders are appropriately compensated for consumed gas and preventing denial-of-service vectors where malicious actors flood the network with free, failing transactions.
Broad Applications and Ecosystem Collaboration
Beyond mitigating blind signing and state manipulation, native transaction assertions unlock new capabilities across various blockchain use cases. They can significantly strengthen delegation models by allowing users to place rigorous programmatic constraints on automated agents, restricting not only which contracts an agent may interact with, but also the exact economic boundaries of the resulting transaction outcome. Similarly, decentralized protocols could enforce mandatory safety checks across solver-based routing architectures, guaranteeing specific user outcomes while leaving solvers free to optimize execution paths within strict safety parameters.
Because these solutions remain in active development under the Ethereum Foundation’s Trillion Dollar Security initiative, researchers are actively seeking feedback from wallet developers, protocol engineers, and infrastructure teams. Stakeholders interested in contributing to the research or exploring practical integration pathways can reach out via email to the initiative or participate in the ongoing EIP-7906 community discussion threads. Additional documentation regarding high-priority security work and risk controls is accessible through the official Trillion Dollar Security platform.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
