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 a transaction’s intended final outcome. This development is being pursued in parallel with advancements in "Clear Signing" technology, aiming to provide users with unprecedented control and clarity over their on-chain activities.
This in-depth report delves into the fundamental reasons why a seemingly valid digital signature on an Ethereum transaction does not always guarantee the desired result. It will illuminate how proposed native transaction assertions could offer robust protection to users in scenarios where current security measures fall short. Furthermore, it will examine the intricate design choices underpinning these assertions, with a particular focus on EIP-7906 (Transaction Assertions via State Diff Opcode) as a leading candidate for implementation.
The Two Faces of Transaction Failure: Intent and Outcome Mismatches
The core of the problem lies in the fundamental operational principles of the Ethereum Virtual Machine (EVM). The EVM executes transactions precisely as authorized, without an inherent capacity to interpret the user’s intent or judge the desirability of the outcome. A digital signature serves as a commitment to a specific request, but its ultimate consequence is contingent upon the smart contract code and the prevailing state of the blockchain at the moment of execution. Tragically, numerous users have incurred substantial financial losses due to two primary categories of failure: approving a transaction that differed from their understanding, or executing a transaction whose intended outcome was subverted by unforeseen contract interactions or state changes.
Intent Mismatch: When Signatures Mislead
The first scenario, an "intent mismatch," has been starkly illustrated by several high-profile security incidents. The Bybit incident and the BadgerDAO attack serve as cautionary tales. In both these cases, attackers exploited compromised front-end interfaces to present users with signing requests that were deceptively different from what users believed they were authorizing. For instance, in the Bybit incident, users who believed they were approving routine operations inadvertently authorized the replacement of the Safe wallet’s core implementation contract. Similarly, users targeted in the BadgerDAO attack granted attackers broad permissions to spend their tokens, a far cry from their original intent. These attacks underscore the vulnerability of users when the perceived action and the actual authorized action diverge, often due to malicious manipulation of the user interface.
Outcome Mismatch: The Unforeseen Consequences of Execution
The second category, an "outcome mismatch," arises when a user approves a transaction based on the information presented, but its execution, influenced by the contract’s logic or the state of the network, leads to an unintended and detrimental result. A striking example of this occurred during a collateral swap involving Aave and CoW (Cow Protocol). A user intended to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the Aave liquidity for this substantial amount was insufficient. Compounding this issue, CoW Swap’s gas ceiling mechanism rejected more complex quotes during verification, leaving only one verified quote for roughly 329 aEthAAVE. Despite the interface displaying a stark 99.9% price impact warning and requiring explicit confirmation that the entire value could be lost, the user proceeded with the transaction. The consequence was receiving tokens valued at approximately $36,000, a fraction of the intended value.
In all these instances, a critical element was missing: a trusted rule governing the resulting state of the blockchain, defined independently of the transaction builder and rigorously enforced during execution. For the Bybit case, such a rule would have mandated that the approved Safe implementation contract remain unaltered. For BadgerDAO users, a rule could have restricted new token approvals exclusively to verified Badger contracts. The Aave user’s situation could have been safeguarded by a rule establishing a minimum acceptable output, calculated independently of the quote presented by the Aave interface. In a solver-based flow like CoW Swap’s, the signed order or settlement protocol itself would also need to incorporate such an assertion. The fundamental limitation is that the current Ethereum protocol lacks a general mechanism for on-chain code to inspect the comprehensive set of net state changes and events generated by a transaction.
The Limits of a Signature: What Ethereum Doesn’t Control
A user’s signature on an Ethereum transaction serves as a definitive commitment to the specified action, encompassing the target contract, the value involved, and the accompanying calldata. However, the EVM’s execution of this call is strictly against the smart contract code and the blockchain state as they exist at the precise moment the transaction is processed. This state can, and often does, differ from the conditions that were present when the user initially signed the transaction. Consequently, the net balance adjustments, storage modifications, and any emitted events can deviate significantly from the user’s expectations.
The intricate interplay between the signed request, the executed code, and the prevailing state dictates the transaction’s outcome. This process can be influenced by several factors:
- Dynamic Contract Code: The target contract, or another contract it interacts with, might employ a proxy pattern. If the underlying implementation contract is upgraded or altered before the transaction executes, the code that ultimately runs could be different from what the user inspected and approved.
- Transaction Reordering: The order in which transactions are processed by miners or validators can dramatically alter the state encountered by a user’s call. For instance, a "sandwich attack" can manipulate the price of an asset in a decentralized exchange pool before a user’s swap transaction is executed, even if the signed transaction itself remains unchanged.
Current Defenses: Where Today’s Safeguards Reach Their Limits
While the Ethereum ecosystem has developed several security mechanisms to mitigate risks, these existing defenses have inherent limitations when confronting sophisticated attacks or unforeseen circumstances.
Clear Signing: A Step Towards Transparency
One such defense is "Clear Signing." This technology aims to enhance user understanding by providing a clear, human-readable explanation of the action requested by the transaction’s calldata. However, its effectiveness hinges on two critical factors: the accuracy of the calldata decoding and the signer’s ability to recognize when the decoded action deviates from their intended purpose. If the decoding is flawed or the user fails to grasp the implications of the decoded action, Clear Signing alone may not prevent a malicious transaction.
Simulation: A Glimpse into the Future, Not a Guarantee
Transaction simulation, another common practice, predicts a transaction’s effects by executing it against a snapshot of the chain’s state. While valuable, this method is not foolproof. The crucial caveat is that 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 ultimately signed might differ from the one that was simulated. The case of Radiant Capital exemplifies this vulnerability. In this incident, malware on the signers’ machines intercepted and substituted a malicious payload at the time of signing, even though both the wallet interface and the simulation had accurately reflected the intended transaction.
Contract Checks and Wallet Guards: Targeted Vigilance
Smart contracts and wallet software often incorporate "contract checks" and "wallet guards" to enforce rules during EVM execution. For instance, decentralized exchanges like Uniswap will typically revert a swap if the output falls below a user-defined amountOutMinimum. Similarly, Safe’s checkAfterExecution hook allows a guard to inspect an account’s state post-execution and revert transactions that violate pre-defined rules for owners or configuration settings.
However, these guardrails operate by checking specific, pre-selected states. They require advance knowledge of which state variables to monitor. To assess the state of another contract, they rely on the functions that contract explicitly exposes. 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 inspect the implementation slot, leaving a potential blind spot.
The fundamental limitation of these existing defenses is their inability to interrogate the transaction’s complete set of net state changes. A guard can confirm that a particular balance remains unchanged, but it lacks the capability to query the EVM about all other modifications that occurred. This oversight means that effects outside the guard’s narrowly defined scope can go unnoticed, potentially leading to unintended consequences.
The Promise of Native Transaction Assertions: Enforcing Intended Outcomes
Native transaction assertions represent a paradigm shift in on-chain security. This proposed mechanism would empower on-chain code to scrutinize the entire spectrum of net state changes after a transaction’s actions have been completed. An assertion would function as read-only logic, comparing initial and final values against a user-defined rule. If this rule is violated, the transaction’s actions would be reverted.
Crucially, the assertion rule would be embedded within the transaction itself and signed alongside the intended actions. This ensures that the rule is an integral part of the authorized operation and cannot be tampered with by a compromised component. The assertion’s scope would be comprehensive, encompassing net changes to balances, storage, deployed code, and any emitted events. This allows for the enforcement of a wide range of conditions, such as:
- Minimum Output Guarantees: Requiring a minimum amount of an asset to be received in an exchange.
- Spending Caps: Limiting the total amount of funds that can be spent.
- Approval Restrictions: Preventing new token approvals from being granted.
- Control Logic Preservation: Ensuring that an account’s core control mechanisms remain intact.
- Permitted State Changes: Allowing only a specifically defined set of modifications to the blockchain state.
The effectiveness of an assertion, however, is critically dependent on the provenance of its rule. A compromised front-end could craft an assertion that facilitates an attack rather than preventing it. Therefore, a truly robust and trustworthy assertion must originate from independently verified user intent, a pre-established account policy, or the core logic of a protocol that cannot be altered by a compromised intermediary.
Key Design Considerations for Transaction Assertions
The development of native transaction assertions necessitates careful consideration of several design choices that will dictate their functionality and integration within the EVM:
1. Information Exposure: What Data Becomes Accessible?
The EVM must be able to expose relevant information about the transaction’s execution. This could include a detailed record of all state changes, all emitted events, or a combination of both. The granularity of this information is paramount to enabling comprehensive checks.
2. Access Mechanisms: How is the Data Retrieved?
Several methods could be employed for assertion code to access the transaction’s outcome data:
- Enumeration: Providing a list of all state changes and events.
- Specific Lookups: Allowing the assertion to query for the starting and final values of particular storage slots or balances.
- Full Copying: Transferring the entire set of changes into the assertion’s accessible memory.
3. Opcode Placement and Scope: Where Can Assertions Be Executed?
The placement and scope of the opcodes (low-level EVM instructions) used for assertions are critical:
- Transaction Type Restrictions: Assertions might be limited to specific types of transactions, such as "frame transactions" designed for enhanced control.
- Execution Phase Limitations: Opcodes could be restricted to run only during a particular phase of transaction execution, such as after all other operations are complete.
- Universal Accessibility: Alternatively, assertion opcodes could be permitted anywhere within the EVM’s execution flow, offering maximum flexibility.
EIP-7906: A Concrete Proposal for Transaction Assertions
A prominent technical proposal leading the charge in this area is EIP-7906: Transaction Assertions via State Diff Opcode. This Ethereum Improvement Proposal builds upon the framework established by EIP-8141, which introduced "frame transactions." Frame transactions are designed to encapsulate an ordered sequence of validation and action steps.
EIP-7906 enhances this by introducing a read-only POST_TX frame. This frame is specifically designated for checking the transaction’s ultimate outcome after all other operations have concluded. The design of EIP-7906 aims to provide a comprehensive view of the transaction’s impact:
- State Changes: It reports net differences in native ETH balances and storage slots. If a storage slot is written multiple times but ultimately reverts to its original value, it will not appear in the state diff. Crucially, it also records newly deployed contracts and their code hashes.
- Events: Emitted events are also captured, providing another layer of observable data.
To access this information, EIP-7906 proposes three new EVM opcodes:
TXTRACE: This opcode enumerates the net state changes and emitted events, offering a high-level overview.TXDIFF: This opcode allows for the retrieval of specific starting and final values for particular addresses and storage slots, enabling targeted checks.EVENTDATACOPY: This opcode facilitates copying the data associated with an emitted event into the assertion’s memory for detailed analysis.
These opcodes are designed to function exclusively within the POST_TX frame. This ensures that the assertion logic operates as a static call – meaning it can read data but cannot modify the blockchain state. If the assertion’s rule is violated, the entire execution body of the transaction is reverted. However, the transaction itself remains on the blockchain with a "failed" status. Importantly, the gas payer is still charged for the gas consumed during the execution attempt. This mechanism is crucial for preventing attackers from spamming the network with deliberately failing transactions for free.
EIP-8141 is slated for inclusion in the upcoming "Hegot" network upgrade. EIP-7906, while having advanced to the "Considered for Inclusion" stage, has not yet been confirmed for this upgrade, indicating ongoing evaluation and refinement.
The Imperative of Required Assertions
A critical aspect of EIP-7906’s current design is that it does not mandate the inclusion of an assertion in every transaction. This presents a potential vulnerability: an attacker or a compromised component could omit the assertion, thereby circumventing the intended security checks.
To effectively leverage transaction assertions, two key requirements emerge:
For User Transactions: Wallet-Level Enforcement
For an individual user’s transactions, the wallet software must be responsible for ensuring that every frame transaction it constructs includes the necessary assertion. This assertion rule could be derived from:
- Wallet Simulations: The wallet could run its own simulations of the transaction’s potential outcomes and derive assertion rules based on these simulations.
- Standing Policies: Users could define overarching policies for their accounts, dictating the types of transactions or state changes that are always permissible or forbidden.
For Protocol-Level Protection: Contractual Verification
Protocols that wish to protect their sensitive functions must implement a robust verification mechanism. This would involve ensuring that any call to a protected function originates from a frame transaction that contains the exact required assertion. The protocol should reject:
- Ordinary Transactions: Transactions that do not utilize the frame transaction structure.
- Frame Transactions with Missing or Incorrect Assertions: Transactions that employ the frame structure but lack the specific assertion mandated by the protocol.
This requirement implies that callers and integrations would need to adopt compatible frame transaction structures. Consequently, an already deployed, immutable contract would not be able to retroactively enforce this new check without a contract upgrade.
Broader Implications and Future Use Cases for Transaction Assertions
Beyond enhancing individual user security and protocol integrity, native transaction assertions hold the potential to unlock a range of advanced functionalities and address complex blockchain interactions:
Strengthening Delegation and Agent Control
The ability to delegate authority to agents or smart contracts is a powerful feature of blockchain technology. However, it necessitates careful control over the agent’s permissions. Transaction assertions can significantly bolster this by allowing users to define granular rules for the outcomes of each transaction executed by an agent. This would enable users to constrain not only what an agent is permitted to do but also the specific results its actions can produce. For instance, a user could delegate trading authority to an agent but assert that no more than a certain amount can be spent in a single trade, or that specific types of tokens can never be approved.
Protocol-Defined Safety Standards
Protocols could leverage transaction assertions to enforce standardized safety checks for all users interacting with a particular function. This would ensure a baseline level of security across the user base, regardless of individual wallet configurations or the specific front-end used. For example, a lending protocol might require all users to include an assertion that guarantees their collateral remains within acceptable risk parameters.
Enhanced Solver Execution and Cross-Chain Coordination
In decentralized finance (DeFi) ecosystems that rely on complex execution strategies, such as those involving "solvers" that find optimal trading routes, assertions can provide crucial guarantees. A protocol could specify the desired outcome of a multi-step trading process, while leaving the solver the freedom to determine the most efficient path to achieve it. This ensures that while the execution method is flexible, the final result adheres to predefined safety criteria.
While a single transaction assertion provides guarantees only within the context of one transaction on one network, the underlying principles could eventually be extended to address cross-chain workflows. This would involve developing mechanisms for assertions to be verifiable across multiple blockchains, ensuring continuity of security guarantees in a multi-chain future.
Workflow Completion and State Cleanup
Assertions can also be employed to verify that complex workflows reach their intended final state. For example, after a series of operations, an assertion could check that any unused tokens have been correctly returned to the user and that any temporary token approvals have been revoked, thereby cleaning up the user’s account state and minimizing residual risk.
Shaping the Future of Ethereum Security
The development of native transaction assertions is an ongoing process, actively being shaped by the Ethereum Foundation’s Trillion Dollar Security initiative. This initiative is actively seeking input from wallet developers and protocol teams who are the primary stakeholders and potential users of these new security primitives.
Discussions are underway to explore the diverse use cases and refine the design of these critical security features. Interested parties are encouraged to engage with the research team by contacting [email protected] to contribute to the ongoing dialogue and help steer the direction of this vital development. Furthermore, active participation in the EIP-7906 discussion thread on Ethereum Magicians provides a platform for technical feedback and collaborative problem-solving.
Further information on risk controls and the priority workstreams within the Trillion Dollar Security initiative can be found at trilliondollarsecurity.org, offering a comprehensive overview of Ethereum’s commitment to enhancing the security and resilience of its ecosystem.
