Layla Zulfa
The Ethereum Foundation’s Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as a user experience risk, and is exploring native transaction assertions as a next step to enforce a transaction’s final outcome, alongside Clear Signing. This pivotal development aims to fortify the security posture of the Ethereum ecosystem, which currently secures over $350 billion in total value locked (TVL) across various decentralized finance (DeFi) protocols, non-fungible tokens (NFTs), and other applications. The push for native transaction assertions comes as part of a broader, multi-year strategic effort by the Ethereum Foundation to enhance user protection and reduce systemic risks within the burgeoning Web3 landscape, particularly in the face of increasingly sophisticated cyber threats.
The fundamental challenge stems from Ethereum’s deterministic execution model: it faithfully processes precisely what a user authorizes, without inherent mechanisms to validate if the outcome aligns with the user’s intent. A digital signature on the Ethereum blockchain serves as an irrevocable commitment to a specific transaction request, but the ultimate consequence of that request is profoundly influenced by the prevailing contract code and the state of the blockchain at the moment of execution. This disjunction between signed intent and realized outcome has, unfortunately, led to significant financial losses for users, often falling into two distinct categories: intent mismatch and outcome mismatch.
The Peril of Mismatched Intent and Outcome
The first category, intent mismatch, occurs when users unknowingly approve a transaction that fundamentally differs from what they believed they were signing. This is frequently a result of malicious front-end compromises or sophisticated malware. A stark example is the Bybit incident, where signers were tricked into authorizing a malicious replacement of a Safe’s implementation contract, granting attackers control over funds. Similarly, the BadgerDAO attack saw users unknowingly grant an attacker permission to spend their tokens, leading to substantial losses. In both scenarios, the signed request, while cryptographically valid, did not correspond to the user’s true intention, leaving them vulnerable despite their apparent approval. The attack vectors exploited the gap between the user interface’s presentation and the raw, complex bytecode that was ultimately signed.
The second category, outcome mismatch, arises even when the user approves the precise request displayed to them, but the transaction’s execution against the prevailing blockchain state or due to unforeseen limits yields a result contrary to their economic goals or safety policies. The Aave and CoW collateral swap incident serves as a sobering illustration. A user initiated a swap of approximately $50.4 million in aEthUSDT for aEthAAVE. However, the AAVE liquidity pool was critically thin for such a large trade. Compounding the issue, CoW Swap’s internal gas ceiling rejected more complex, potentially safer quotes during verification, leaving a single, highly disadvantageous option that would yield only about 329 aEthAAVE – equivalent to roughly $36,000. Despite a prominent 99.9% price impact warning on the interface, the user proceeded with the transaction, suffering a near-total loss. This case underscored the limitations of existing safeguards, where even explicit warnings might not prevent unintended outcomes if the underlying protocol or market conditions are not adequately accounted for in the signed transaction’s constraints.
In all these instances, a critical missing layer was a robust, trusted mechanism to enforce rules over the resulting state of a transaction, independent of the transaction builder and applied during execution. For the Bybit incident, such a rule could have mandated that the Safe implementation contract remain unchanged. For BadgerDAO, a rule could have restricted new token approvals only to officially published Badger contracts. In the Aave case, a rule could have set a minimum acceptable output for the swap, calculated independently of any front-end quote. The current Ethereum Virtual Machine (EVM) lacks a general, native mechanism for on-chain code to comprehensively inspect the full suite of net state changes and events generated by a transaction, making it challenging to implement such outcome-based assurances directly.
The Limitations of Current Defenses
Existing security measures, while valuable, often fall short of providing comprehensive protection against these types of risks.
Clear Signing, a key component of improving user experience, aims to translate opaque transaction calldata into human-readable actions. It relies on accurate decoding and the user’s ability to discern discrepancies between the presented action and their true intent. While crucial for preventing basic phishing, it doesn’t inherently protect against a legitimate-looking transaction that produces an undesired outcome due to external state changes or complex interactions.
Transaction Simulation offers a predictive layer, forecasting a transaction’s effects against a chosen chain state. However, simulations are inherently snapshots; the chain state can evolve significantly between simulation and actual inclusion in a block. More critically, as seen in the Radiant Capital post-mortem, sophisticated malware on a user’s machine can substitute a malicious payload at the moment of signing, bypassing both wallet interface display and pre-execution simulations, which might have shown the intended transaction. The signed transaction, therefore, differs from the one simulated, rendering the simulation ineffective.
Contract-level checks and wallet guards represent another line of defense, enforcing specific rules during EVM execution. For example, Uniswap automatically reverts a swap if the output falls below a user-defined amountOutMinimum. Safe’s checkAfterExecution hook allows a guard contract to inspect an account’s state post-execution and revert a transaction if it violates predefined rules for owners or configuration. While powerful, these approaches require defining which specific state variables to check in advance. They also depend on the target contract exposing relevant functions (e.g., balanceOf for tokens). If a proxy contract doesn’t expose its implementation address via a function, a guard cannot directly read the implementation slot, leaving a potential blind spot. Furthermore, these checks are typically narrowly focused; a guard can verify a particular balance remains unchanged, but it cannot query the EVM for all net state changes, meaning unintended side effects can go unnoticed.
Native Transaction Assertions: A New Paradigm for Security
Native transaction assertions represent a significant architectural enhancement, designed to allow on-chain code to meticulously inspect the full set of net state changes after a transaction’s primary actions have been executed. Conceptually, an assertion functions as a read-only logical gate: it compares the blockchain’s state before and after a transaction against a predefined rule. If this rule is violated, the entire transaction’s actions are reverted, effectively nullifying any undesired changes.
Crucially, this assertion rule is included in the transaction itself and signed alongside its intended actions. This ensures that the user’s approval encompasses not just the action, but also the desired outcome. The scope of these assertions is remarkably broad, capable of covering net changes to native ETH balances, contract storage, code deployments, and emitted events. This allows for highly granular control, enabling users or protocols to:
- Require a minimum amount of tokens received in a swap.
- Cap spending limits for delegated actions.
- Block new token approvals unless explicitly authorized.
- Preserve an account’s control logic (e.g., ensuring a Safe’s implementation contract remains unchanged).
- Allow only a specified, whitelisted set of changes.
The power of this approach lies in its ability to intervene after the transaction’s core logic has run but before its effects are permanently committed to the blockchain. The accompanying diagram illustrates this process: assertions check the outcome and revert the transaction’s actions if the rules fail, ensuring integrity.
The provenance of the assertion rule is paramount. A compromised front-end could, in theory, generate a malicious assertion that permits an attack. Therefore, a truly effective rule must originate from an independently approved source of user intent, a standing account policy (perhaps managed by a smart contract wallet), or protocol-defined logic that cannot be manipulated by a compromised component. This design principle ensures that the safety net itself is not vulnerable to the same attacks it aims to mitigate.
EIP-7906: A Concrete Path Forward
The design and implementation of native transaction assertions are complex, requiring careful consideration of what information the EVM exposes, how assertion code accesses it, and where these new opcodes can operate. Key design choices revolve around:
- Information Exposure: Should the EVM expose state changes, events, or both?
- Access Methods: How can assertion code access this information? Through enumeration, specific value lookups, or copying full sets of changes into memory?
- Execution Context: Should these opcodes be restricted to particular transaction types, execution phases, or allowed anywhere?
One leading proposal addressing these challenges is EIP-7906 (Transaction Assertions via State Diff Opcode). This EIP builds upon the "frame transactions" introduced in EIP-8141 (Frame Transactions). EIP-8141, currently slated for inclusion in the upcoming HegotÁ upgrade, defines a new transaction type that encapsulates an ordered sequence of validation and action steps. EIP-7906 extends this by adding a read-only POST_TX frame, which executes at the very end of the transaction specifically to check its outcome. EIP-7906 has advanced to "Considered for Inclusion," signifying its high priority and potential for integration into a future Ethereum upgrade.
EIP-7906’s design exposes both state changes and events. State changes are reported as net differences in native ETH balances and storage, alongside newly deployed contracts and their code hashes. Crucially, a storage slot that is written to multiple times within a transaction will appear as a single entry, showing only its starting and final values. If a slot ends with its original value, it does not appear in the diff at all, optimizing for relevance.
To access this crucial information, EIP-7906 proposes three new EVM instructions (opcodes):
TXTRACE: This opcode enables enumeration of net state changes and events, allowing assertion logic to iterate through all modifications.TXDIFF: This opcode retrieves the starting and final values for specific addresses and storage slots, providing direct access to targeted changes.EVENTDATACOPY: This opcode allows for copying an event’s data into memory, facilitating inspection of emitted events.
These powerful opcodes are specifically designed to operate only within a POST_TX frame, which runs as a static call. This critical design choice ensures that the assertion logic itself cannot modify the blockchain state, maintaining its integrity as a pure validation mechanism. If an assertion rule is violated, the entire execution body of the transaction is reverted. However, the transaction itself remains in the block with a failed status, and the gas payer is still charged for the consumed gas. This mechanism is vital for preventing denial-of-service attacks, where malicious actors might otherwise submit deliberately failing transactions for free, burdening the network.
The Imperative of Required Assertions
While EIP-7906 provides the technical framework, its efficacy hinges on widespread adoption and enforcement. The current proposal does not mandate that all transactions include an assertion, leaving the choice to the transaction builder. This presents a crucial challenge for implementation:
- Wallet Responsibility: For user-initiated transactions, wallets must evolve to ensure that every frame transaction they construct includes the necessary assertions. These rules could be dynamically generated based on a pre-execution simulation run by the wallet, or derived from standing security policies defined by the user (e.g., "never approve a transfer of more than X ETH," or "this contract’s implementation must remain Y").
- Protocol Integration: Decentralized protocols, particularly those managing significant assets or sensitive operations, would need to verify that incoming calls originate from frame transactions containing the exact required assertions. They would need to reject ordinary transactions or frame transactions with missing or incorrect assertions. This implies a significant upgrade path for protocols, and critically, already deployed immutable contracts would be unable to add this crucial check without a migration, highlighting a potential adoption hurdle.
Broader Implications and Future Applications
Beyond the immediate security benefits for individual users and protocols, native transaction assertions unlock a spectrum of advanced use cases that could fundamentally reshape how interactions occur on Ethereum:
- Strengthening Delegation: When users delegate authority to an agent (e.g., a multi-sig signer, a bot, or another smart contract), assertions can provide a robust layer of control. While existing methods can limit what an agent can do (which contracts it calls, spending limits, permission durations), assertions can add precise rules for what the outcome of each transaction must be. This allows users to constrain both the actions an agent may take and the resulting state changes, creating a more secure and predictable delegated environment.
- Enhanced Protocol Safety: Protocols can define and enforce their own outcome-based safety checks for every caller utilizing a frame transaction. For instance, a decentralized exchange (DEX) could require an assertion guaranteeing a minimum output amount for a swap, regardless of the path chosen by a solver. In complex solver-based execution flows, this allows the protocol to specify the desired outcome while giving the solver flexibility in determining the most efficient route. It’s important to note this guarantee applies within a single transaction on a single network, not across multiple chains.
- Guaranteed Workflow Completion: Assertions could ensure that multi-step workflows reach their intended final state. For example, after a complex DeFi interaction, assertions could verify that unused tokens are returned to the user, and any temporary token approvals are revoked, reducing residual risk.
- Preventing MEV Exploitation: By asserting specific outcome parameters (e.g., minimum output from a swap), users can potentially mitigate certain forms of Maximal Extractable Value (MEV) exploitation, such as sandwich attacks, which manipulate transaction ordering to profit at the user’s expense.
Shaping the Future of Ethereum Security
The development of native transaction assertions is a critical undertaking within the Ethereum Foundation’s Trillion Dollar Security initiative. It represents a proactive step towards building a more resilient, user-friendly, and secure blockchain ecosystem. The success of this initiative hinges on collaborative engagement from the broader Ethereum community. Wallet developers, protocol teams, and security researchers are encouraged to engage with the Ethereum Foundation to explore specific use cases, provide feedback on design choices, and contribute to the research and development efforts. Interested parties can reach out at [email protected] or join the ongoing discussions on the EIP-7906 discussion thread on Ethereum Magicians. As Ethereum continues its evolution, these foundational security enhancements are paramount to realizing its full potential as a truly decentralized and trustworthy global computing platform. Further details on risk controls and priority work can be found at trilliondollarsecurity.org.
