The Ethereum Foundation’s ambitious "Trillion Dollar Security" initiative has pinpointed blind signing and transaction uncertainty as significant user experience risks within the Ethereum ecosystem. In response, the initiative is actively exploring the implementation of native transaction assertions, a novel mechanism designed to rigorously enforce the intended final outcome of a transaction. This endeavor aims to complement existing security measures like "Clear Signing" by providing a deeper layer of assurance for users.
This comprehensive investigation delves into the fundamental reasons why a seemingly valid cryptographic signature on an Ethereum transaction does not inherently guarantee the desired result. It further examines how proposed native transaction assertions could shield users from risks that current security protocols are unable to address. The article will also explore the design considerations underpinning these assertions, highlighting EIP-7906, or "Transaction Assertions via State Diff Opcode," as a leading potential approach.
The Perilous Gap: When Signatures Don’t Guarantee Intent
At the heart of the issue lies the fundamental operational model of the Ethereum Virtual Machine (EVM). The EVM operates with a strict adherence to programmed logic; it executes precisely what is authorized, without any inherent understanding or judgment of the user’s ultimate intent. A digital signature on an Ethereum transaction serves as a commitment to a specific request, but its actual consequence is contingent upon the smart contract code and the prevailing state of the blockchain at the moment of execution. This disconnect has unfortunately led to substantial financial losses for users who have either inadvertently approved actions different from their understanding or whose intended actions have resulted in unforeseen and detrimental outcomes.
These failures can be broadly categorized into two critical scenarios: intent mismatch and outcome mismatch.
Intent Mismatch: The Deception in the Details
The first category, intent mismatch, refers to situations where a user signs a transaction believing it will perform one action, but the underlying code or compromised interface presents a different, often malicious, action. This was starkly illustrated in high-profile incidents such as the Bybit exploit and the BadgerDAO attack.
In the Bybit incident, a compromised frontend interface presented users with a signing request that, when executed, differed significantly from what the users perceived they were approving. The compromised request authorized the replacement of the Safe wallet’s implementation contract, effectively giving attackers control over the wallet’s functionalities. Similarly, in the BadgerDAO attack, users were tricked into granting an attacker permission to spend their tokens by approving seemingly innocuous transactions presented by a manipulated interface. These events underscore the critical need for users to be able to trust that what they see is precisely what they are signing, and that the underlying code hasn’t been tampered with.
Outcome Mismatch: The Unintended Consequences of Execution
The second scenario, outcome mismatch, occurs when a user signs a transaction with a clear intent, but the execution environment—either due to the contract’s logic, the network’s state, or external factors—leads to a result that contradicts their economic goals or established safety policies.
A striking example of this occurred in a collateral swap involving Aave and CoW (CowSwap). A user intended to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the available Aave liquidity for such a substantial trade was insufficient. Compounding this issue, CoWSwap’s gas ceiling mechanism rejected more complex quotes during verification, leaving only one verified quote that resulted in roughly 329 aEthAAVE. Despite the interface displaying a stark 99.9 percent price impact warning and explicitly requiring the user to confirm that the entire value could be lost, the user proceeded to sign the transaction. The ultimate outcome was that the user received tokens valued at approximately $36,000, a fraction of their intended stake.
In all these egregious cases, a crucial element was missing: a trusted, independently verifiable rule governing the resulting state of the transaction. Such a rule would need to be defined separately from the transaction builder and rigorously enforced during execution. For instance, in the Bybit case, a rule would have mandated that the approved Safe implementation contract remain unchanged. For Badger users, a rule could have stipulated that new token approvals are only permitted for officially published Badger contracts. In the Aave/CoW scenario, a rule might have enforced a minimum acceptable output value, calculated independently of the quote provided by Aave’s interface. Crucially, in a solver-based flow like CoWSwap, the signed order or the settlement protocol itself would also need to incorporate and enforce such an assertion. The current Ethereum architecture lacks a general mechanism for on-chain code to inspect the complete set of net state changes and events generated by a transaction, leaving this critical gap unaddressed.
What a Signature Does Not Control: The Dynamic Nature of Ethereum
It is imperative for users to understand that a signature on the Ethereum network commits to the specific action requested, including the target contract, the value being transferred, and the accompanying calldata. However, the execution of this call by the EVM occurs against the smart contract code and the state of the blockchain as they exist at the precise moment the transaction is processed. This state can and often does change between the time a transaction is signed and when it is executed. Consequently, the net balance changes, storage modifications, and any emitted events can diverge significantly from what the user initially anticipated.
The interplay between the signed request, the code, and the state is dynamic. A target contract, or another contract it interacts with, might utilize a proxy pattern. If the underlying implementation contract of this proxy is updated before the transaction is executed, the code that actually runs could be entirely different from what the user inspected and approved at the time of signing. Furthermore, transaction ordering, a key characteristic of blockchain networks, can dramatically alter the state a user’s call encounters. For example, a "sandwich attack," where a malicious actor strategically places transactions before and after a user’s intended swap, can manipulate the price of an asset pool before the user’s transaction is executed, without altering the signed transaction itself. This demonstrates how external factors, beyond the user’s direct control or foresight, can profoundly impact transaction outcomes.
Where Today’s Defenses Fall Short
While the Ethereum ecosystem has implemented several security measures to protect users, these defenses have inherent limitations when confronting the full spectrum of potential risks.
Clear Signing and Simulation: Valuable but Not Foolproof
One such defense is "Clear Signing," a feature designed to provide users with a more human-readable explanation of the action requested by the calldata. This approach relies heavily on the accuracy of calldata decoding and, crucially, on the user’s ability to recognize when the explained action deviates from their intended purpose. However, this system is not infallible; it hinges on the signer’s vigilance and understanding.
Simulation, another common defense, attempts to predict a transaction’s effects by executing it against a selected snapshot of the blockchain’s state. While useful, simulations are susceptible to discrepancies. The chain state can evolve between the time of simulation and the actual inclusion of the transaction in a block. Moreover, the transaction that is eventually signed might differ from the one that was simulated. The case of Radiant Capital serves as a poignant example. In this incident, both the wallet interface and the simulation presented the intended transaction to the user. However, malicious software present on the signers’ machines intercepted and substituted a malicious payload at the critical moment of signing, completely undermining the simulation’s protective value.
Contract Checks and Wallet Guards: Limited Scope of Inspection
Contract-level checks and wallet guards offer additional layers of security by enforcing rules during EVM execution. For instance, decentralized exchanges like Uniswap typically revert a swap if the output falls below a user-defined amountOutMinimum. Similarly, platforms like Safe utilize checkAfterExecution hooks, allowing a guard to inspect the account’s state post-execution and revert transactions that violate predefined rules for owners or configurations.
Despite their utility, these mechanisms are often limited by the scope of information they can access. They require pre-defined rules and often depend on the functions exposed by other contracts. While a token’s balanceOf function makes balance checks straightforward, a proxy contract might not expose its implementation address through a public function. In such cases, a guard cannot directly read the implementation slot, hindering its ability to perform comprehensive checks. Critically, these existing defenses cannot inspect the complete set of net state changes and events produced by a transaction. A guard might verify that a specific balance remains unchanged, but it lacks the capability to query the EVM about all other modifications that occurred. This means that effects not specifically designed for the guard to check can go unnoticed, leaving vulnerabilities open.
The Promise of Native Transaction Assertions
Native transaction assertions represent a paradigm shift in Ethereum’s security architecture. This proposed mechanism would empower on-chain code to inspect the entire spectrum of net state changes that occur after a transaction’s actions have been executed. An assertion would function as a read-only logical check, comparing the initial and final values of various blockchain elements against a set of predefined rules. If these rules are violated, the transaction’s actions would be reverted.
The assertion itself would be an integral part of the transaction, signed alongside the primary actions. This assertion could encompass a wide range of conditions, including net changes to balances, storage modifications, newly deployed contracts, and emitted events. It could enforce crucial conditions such as requiring a minimum received amount, capping total spending, preventing the issuance of new token approvals, preserving an account’s control logic, or permitting only a narrowly defined set of state changes. The diagram below illustrates how these assertions would meticulously check the transaction’s outcome, triggering a reversion if the established rules are not met.
The integrity of the assertion’s source is as critical as the assertion itself. A compromised frontend could easily craft an assertion designed to facilitate an attack. Therefore, a truly effective rule must originate from independently approved user intent, a steadfast account policy, or protocol logic that cannot be altered by a compromised component.
Key Design Considerations for Transaction Assertions
The development of native transaction assertions necessitates careful consideration of several fundamental design choices. These include determining precisely what information the EVM should expose regarding transaction outcomes, defining how assertion code can access this information, and specifying where within the EVM execution lifecycle these assertion opcodes can be invoked.
The information exposed could encompass a broad range of data, including state changes, emitted events, or both. The access methods for this information might vary, offering options such as enumerating all relevant entries, allowing for the lookup of specific values, or copying the entire set of changes into memory for processing. Furthermore, the opcodes responsible for executing these assertions could be restricted to particular transaction types or specific execution phases within the EVM, or they could be made available for use across any part of the EVM execution flow.
EIP-7906: A Concrete Pathway Forward
One of the most promising avenues for implementing native transaction assertions is through EIP-7906, which builds upon the framework established by EIP-8141’s "frame transactions." A frame transaction is designed to contain an ordered sequence of validation and action steps. EIP-7906 proposes adding a read-only POST_TX frame at the conclusion of this sequence. This POST_TX frame would be specifically tasked with verifying the transaction’s outcome. EIP-8141 is slated for inclusion in the upcoming "Hegot" network upgrade, while EIP-7906 has progressed to the "Considered for Inclusion" stage, indicating significant momentum but no definitive confirmation for an immediate upgrade.
The design of EIP-7906 envisions exposing both state changes and events. State changes would be reported as net differences in native ETH balances and storage, alongside information about newly deployed contracts and their respective code hashes. For instance, if a storage slot is written to five times during a transaction, it would be represented as a single entry detailing its starting and final values. If a slot reverts to its original value, it would not be included in the report, thus optimizing data representation.
To facilitate access to this information, EIP-7906 introduces three new opcodes, essentially new instructions for the EVM:
TTRACE: This opcode would enumerate all net state changes and events that occurred during the transaction.TXDIFF: This opcode would retrieve the starting and final values for specific addresses and storage slots.EVENTDATACOPY: This opcode would enable the copying of an event’s associated data into memory for further processing.
These opcodes would operate exclusively within the POST_TX frame, which executes as a static call at the very end of the transaction. This static nature ensures that the assertion can inspect the outcome without altering the blockchain’s state. If the assertion’s rules are violated, the entire execution body of the transaction would revert. However, the transaction itself would remain in the block with a "failed" status, and importantly, the gas payer would still be charged for the gas consumed during the execution. This charge is a critical anti-abuse measure, preventing attackers from submitting deliberately failing transactions for free to disrupt network operations.
The Imperative of Required Assertions
A crucial aspect of EIP-7906 is that it does not mandate the inclusion of an assertion in every transaction. This leaves the decision of whether to include an assertion to the transaction’s creator.
For user-initiated transactions, it will be incumbent upon wallet providers to ensure that every frame transaction they construct incorporates the necessary assertion. This assertion could be derived from a simulation performed by the wallet or from a pre-established, standing policy that governs all of the user’s transactions.
For protocols, protected functions must incorporate checks to verify that incoming calls originate from frame transactions that include the precise, required assertion. This would involve rejecting ordinary transactions and frame transactions that are missing an assertion or contain an incorrect one. This requirement would necessitate that callers and integrations utilize compatible frame transactions. It is important to note that this check could not be retroactively applied to already deployed, immutable contracts.
Broader Applications of Transaction Assertions
Beyond enhancing security for individual users and protocols, native transaction assertions hold the potential to unlock a range of other valuable use cases.
Strengthening Delegation and Authorization
Assertions could significantly bolster the security of delegation mechanisms. When users grant agents the authority to act on their behalf, they often wish to impose specific limitations, such as restricting the contracts the agent can interact with, capping the amount of funds it can spend, or defining the duration of its permissions. Transaction assertions could introduce robust rules for the outcome of each transaction executed by an agent, thereby enabling users to precisely constrain both what the agent is permitted to do and the ultimate consequences of its actions.
Protocol-Defined Safety Guarantees
Protocols could leverage transaction assertions to define their own mandatory safety checks, ensuring that every caller utilizing a frame transaction adheres to the same security standards. In complex execution environments like solver networks, a protocol could specify the exact required outcome for a transaction while allowing the solver the flexibility to determine the optimal route to achieve that outcome. This guarantee would be confined to a single transaction on a specific network, thus not extending to cross-chain workflows.
Workflow Completion and Cleanup
Assertions could also be employed to verify that a multi-step workflow reaches its intended final state. This could include ensuring that any unused tokens are returned to the user and that any remaining token approvals are revoked upon completion of the process, thereby leaving the user’s accounts in a clean and secure state.
Shaping the Future of Ethereum Security
The ongoing development of native transaction assertions is a critical component of the Ethereum Foundation’s Trillion Dollar Security initiative. The design and implementation of these powerful new tools are still in progress, and the initiative is actively seeking input from wallet and protocol teams who stand to benefit from their adoption. Interested parties are encouraged to reach out to [email protected] to discuss potential use cases and contribute to shaping this vital research. Furthermore, active participation in the EIP-7906 discussion thread on ethereum-magicians.org offers a platform to engage with the technical details and influence the direction of this important development.
For more in-depth information on risk controls and priority workstreams within the Trillion Dollar Security initiative, please visit trilliondollarsecurity.org. The successful integration of native transaction assertions promises to usher in a new era of enhanced security and user confidence within the Ethereum ecosystem.
