Layla Zulfa
The Ethereum Foundation’s "Trillion Dollar Security initiative," a comprehensive effort to bolster the security and trustworthiness of the world’s leading smart contract platform, has identified critical vulnerabilities stemming from blind signing and transaction uncertainty. In response, the initiative is actively exploring native transaction assertions as a foundational next step to ensure a transaction’s final outcome aligns with user intent. This innovative approach, designed to complement existing safeguards like Clear Signing, seeks to fundamentally redefine transaction integrity within the Ethereum ecosystem.
The Pervasive Threat: When Signed Transactions Go Awry
The inherent architecture of Ethereum, while powerful and flexible, presents a unique challenge: it executes precisely what a user authorizes, without an intrinsic mechanism to verify if the final result matches the user’s desired outcome. A digital signature on the Ethereum blockchain commits a user to a specific request, but the ultimate impact of that request is profoundly influenced by the smart contract code and the prevailing blockchain state at the moment of execution. This disjunction between initial intent and final outcome has, unfortunately, led to substantial financial losses for users, manifesting in two primary forms: intent mismatch and outcome mismatch.
Intent mismatch occurs when a user approves a transaction believing it to be one thing, only for it to execute an entirely different, often malicious, action. This vector has been exploited in high-profile incidents. For instance, the Bybit incident, widely reported in the security community, saw a compromised frontend manipulate signing requests. Users, believing they were approving standard operations, unwittingly authorized the replacement of a Safe wallet’s critical implementation contract. Similarly, the BadgerDAO attack, a significant exploit that led to millions in losses, involved a compromised frontend tricking users into granting attackers broad permissions to spend their tokens. In both cases, the users’ signatures were valid, but the underlying intent presented to them by the compromised interface was fundamentally different from what was executed on-chain.
The second, equally perilous, scenario is an outcome mismatch. Here, the user genuinely approves the transaction as presented, but the operational limits of the request or the dynamic state of the blockchain allow for an undesirable outcome that conflicts with their economic goals or established safety policies. A stark illustration of this was the Aave and CoW collateral swap event. A user initiated a swap for approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was critically thin for such a large trade. Compounding the issue, CoW’s gas ceiling mechanism rejected more complex, potentially safer, quotes during verification, leaving only one viable, albeit highly unfavorable, quote for roughly 329 aEthAAVE. Despite the interface prominently displaying a 99.9% price impact warning and requiring explicit confirmation that the entire value could be lost, the user proceeded with the signature. The result was a devastating loss, with the user receiving tokens worth only about $36,000 from a transaction intended for over $50 million.
These incidents underscore a critical systemic deficiency: the absence of a universally trusted, on-chain rule system that can inspect the full spectrum of net state changes and events produced by a transaction and enforce a desired outcome. Such a system would have, for example, prevented the Bybit Safe implementation from changing without explicit, verified approval, or limited token approvals for Badger users to only known, legitimate Badger contracts. In the Aave case, it would have allowed the user to set a minimum acceptable output, independently verified, ensuring the transaction would revert if that threshold wasn’t met.
Understanding the Limits of a Signature
A user’s cryptographic signature on Ethereum commits to a specific transaction request, encompassing parameters such as the target contract address, the value of ETH to be sent, and the calldata (the instructions for the smart contract). However, the Ethereum Virtual Machine (EVM) executes this call against the contract code and the blockchain’s state at the precise moment the transaction is included in a block. This state is dynamic and can evolve significantly between the time a user signs a transaction and its eventual execution.
Consider a scenario where the target contract uses a proxy pattern. The underlying implementation contract, which dictates the actual logic, could be updated or even maliciously swapped after a user signs a transaction but before it executes. This means the code that ultimately runs might be entirely different from what the user inspected and intended to interact with. Furthermore, transaction ordering, a crucial aspect of blockchain mechanics, can dramatically alter the state a user’s call encounters. For instance, a "sandwich attack" in decentralized finance (DeFi) involves a malicious actor front-running a user’s trade with their own transaction and then back-running it, effectively manipulating the pool’s price to their advantage, all without altering the user’s original signed transaction. The user’s request remains unchanged, but the economic outcome is severely impacted by external factors.
Current Security Measures and Their Inadequacies
The Ethereum ecosystem has developed several layers of defense against these complex threats, but each possesses inherent limitations that native transaction assertions aim to overcome.
One primary defense is Clear Signing. This mechanism attempts to translate raw calldata into human-readable actions, allowing users to understand what they are approving. It relies on accurate decoding libraries and the user’s ability to discern if the presented action aligns with their intent. However, Clear Signing is vulnerable to sophisticated attacks where malicious actors can craft calldata that appears innocuous when decoded but performs harmful actions, or where the decoding itself is compromised. Moreover, it cannot predict or prevent adverse outcomes caused by changes in contract state or external transaction ordering.
Transaction Simulation offers another layer of protection. Wallets and security tools often simulate a transaction’s effects against a chosen snapshot of the blockchain state. This provides a prediction of the outcome, including balance changes and potential errors. While valuable, simulations are not foolproof. The actual chain state can change between the simulation and the transaction’s inclusion in a block, rendering the prediction inaccurate. More critically, simulations are susceptible to malware. In the case of Radiant Capital, a wallet interface and its simulation correctly displayed the intended transaction, yet malware on the user’s machine surreptitiously substituted a malicious payload at the crucial signing stage, bypassing all pre-signing checks.
Contract Checks and Wallet Guards represent on-chain defenses. Protocols like Uniswap implement amountOutMinimum checks, reverting a swap if the output falls below a user-specified threshold. Smart contract wallets, such as Safe (formerly Gnosis Safe), utilize checkAfterExecution hooks, allowing a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined rules for owners or configuration. While powerful, these approaches are limited in scope. They require developers to anticipate and hardcode specific state checks in advance. They also depend on target contracts exposing relevant functions to read their storage; a proxy contract, for example, might not expose its implementation address through a public function, making it impossible for a guard to directly read the critical implementation slot. Most significantly, existing on-chain checks cannot inspect the full set of net state changes generated by a transaction. A guard can verify if a specific balance remains unchanged, but it cannot ask the EVM for a comprehensive list of everything that changed, leaving unforeseen side effects undetected.
Native Transaction Assertions: A New Paradigm for On-Chain Security
Native transaction assertions are designed to address these critical gaps by enabling on-chain code to inspect the complete set of net state changes after a transaction’s primary actions have been executed. At its core, an assertion functions as a read-only logic gate that compares the blockchain’s state before and after a transaction. If this comparison reveals that the outcome violates a predefined rule, the entire transaction’s actions are automatically reverted.
Crucially, the assertion rule itself is included within the transaction and signed by the user, alongside the primary actions. This ensures that the user explicitly agrees not only to the action but also to the conditions under which that action is deemed acceptable. These rules can be highly granular and comprehensive, covering:
- Net changes to native ETH balances and ERC-20 token balances.
- Modifications to storage slots.
- Changes in contract code or newly deployed contracts.
- Specific emitted events.
This allows for the enforcement of vital security policies, such as requiring a minimum amount received in a swap, capping spending limits, blocking unauthorized new token approvals, preserving an account’s control logic (e.g., ensuring a Safe’s implementation contract remains unchanged), or permitting only a specified, narrow set of changes. The workflow is conceptually straightforward: the user signs a transaction that includes both the desired action and a set of assertions. The transaction executes. Before finalization, the assertion logic runs, inspecting the post-execution state. If any assertion fails, the entire transaction (including the initial actions) is reverted, as if it never happened, protecting the user from unintended consequences.
A critical aspect of this design is the source of the assertion rule. A compromised frontend could, theoretically, craft a malicious assertion that permits an attack. Therefore, a truly effective rule must originate from an independently approved user intent, a standing account policy (e.g., set by a smart contract wallet), or robust protocol logic that cannot be tampered with by a compromised component. This ensures the assertion acts as a genuine safeguard, rather than another point of failure.
EIP-7906: A Concrete Proposal for Implementation
One leading proposal for integrating native transaction assertions into Ethereum is EIP-7906 (Transaction Assertions via State Diff Opcode). This Ethereum Improvement Proposal builds upon the framework introduced by EIP-8141, which defines "frame transactions." Frame transactions allow for an ordered sequence of validation and action steps within a single transaction. EIP-7906 extends this by introducing a read-only POST_TX frame, specifically designed to run at the very end of a transaction’s execution to check its final outcome. EIP-8141 is currently scheduled for inclusion in the upcoming Hegotá network upgrade, while EIP-7906 has advanced to "Considered for Inclusion" status, indicating significant progress towards its potential integration.
The EIP-7906 design is meticulous in its approach to exposing relevant information to the assertion logic. It provides granular details on:
- State Changes: Reported as net differences in native ETH balances and storage. Crucially, if a storage slot is written to multiple times but ultimately reverts to its original value, it will not appear as a change, focusing only on the net impact. Similarly, newly deployed contracts and their associated code hashes are made available for inspection.
- Events: All emitted events during the transaction’s execution are also exposed.
To facilitate access to this rich information, EIP-7906 introduces three new EVM opcodes (low-level instructions):
TXTRACE: This opcode allows the assertion code to enumerate (iterate through) all net state changes and emitted events, providing a comprehensive overview.TXDIFF: This opcode enables targeted retrieval of starting and final values for specific addresses and storage slots, allowing for precise checks.EVENTDATACOPY: This opcode allows assertion code to copy the data of a specific event into memory for further analysis.
These powerful opcodes are intentionally restricted to operate only within the POST_TX frame. Furthermore, the POST_TX frame executes as a static call, meaning it cannot modify the blockchain state itself. This read-only characteristic is vital for security, ensuring that the assertion logic cannot inadvertently (or maliciously) alter the outcome it is meant to verify. If an assertion rule is violated, the entire execution body of the transaction reverts. However, the transaction itself remains in the block with a "failed" status, and the gas payer is still charged for the gas consumed up to the point of reversion. This crucial design choice prevents attackers from exploiting the system by submitting deliberately failing transactions for free, which could otherwise be used to clog the network.
The Indispensable Role of Mandatory Assertions
While EIP-7906 provides the technical capabilities for native transaction assertions, its effectiveness hinges on their mandatory adoption. The current proposal does not inherently require transactions to include an assertion, leaving a potential loophole for malicious transaction builders to omit them.
To ensure widespread protection, several mechanisms would need to be in place:
- Wallet Enforcement: For a user’s own transactions, their wallet software must be designed to automatically include the necessary assertions. This rule could be derived from a real-time simulation performed by the wallet or from a standing security policy predefined by the user for all their transactions (e.g., "never approve a token transfer greater than X amount," or "always ensure my Safe implementation contract remains unchanged").
- Protocol-Level Requirements: Decentralized applications (dApps) and smart contracts could be designed to mandate specific assertions for interactions with their protected functions. A protocol might, for example, verify that an incoming call originates from a frame transaction containing a specific, required assertion. It would then reject ordinary transactions or frame transactions with missing or incorrect assertions. This would necessitate callers and integrated services to adopt compatible frame transactions. A significant consideration here is that already deployed, immutable contracts could not retroactively add this check, highlighting the need for forward-thinking design in new deployments.
Broader Implications and Future Horizons
Beyond the immediate and critical security benefits for individual users and protocols, native transaction assertions unlock a wealth of possibilities for enhancing the overall functionality and trustworthiness of the Ethereum ecosystem.
- Strengthened Delegation: When users delegate control to an agent (e.g., a smart contract or another address) to act on their behalf, assertions can significantly enhance security. While existing delegation systems can limit which contracts an agent uses, how much it spends, or the duration of its permissions, assertions can add granular, outcome-based rules to each transaction. This means users can constrain not only what the agent is allowed to do but also what outcomes those actions must produce, providing a much higher degree of safety and control.
- Protocol-Defined Safety Checks: Protocols could define their own universal safety checks, requiring all callers using frame transactions to adhere to them. This ensures a consistent security baseline for all interactions, reducing the attack surface.
- Enhanced Solver Execution: In complex decentralized exchange (DEX) environments, where "solvers" find optimal trading routes, protocols could specify a required outcome (e.g., a minimum output amount) while granting the solver flexibility in choosing the execution path. This provides a guaranteed outcome for the user while maintaining efficiency. It is important to note, however, that this guarantee would apply only within a single transaction on a single network and would not extend to multi-chain transactions.
- Workflow Verification: Assertions could be used to ensure that multi-step workflows reach their intended final state, for example, confirming that unused tokens are returned to the user or that any remaining token approvals are revoked after a specific operation. This automates the verification of complex transactional logic.
Shaping the Future: A Call to Action
The development of native transaction assertions represents a significant leap forward in Ethereum’s security architecture. As part of the Ethereum Foundation’s "Trillion Dollar Security initiative," these solutions are still in their design phase, emphasizing the need for collaborative development. The Foundation is actively seeking input from the very wallet and protocol teams who would be the primary beneficiaries and implementers of these features. Engaging with the community is paramount to ensuring that the final design is robust, practical, and addresses real-world challenges. Interested parties are encouraged to reach out to [email protected] to explore use cases and contribute to the research and design process. Additionally, developers and researchers can join the ongoing discussions on the EIP-7906 discussion thread on Ethereum Magicians, providing valuable feedback that will directly influence the evolution of this critical security upgrade.
Further details on risk controls and priority work within the broader initiative can be found at trilliondollarsecurity.org, underscoring Ethereum’s unwavering commitment to building a more secure and trustworthy decentralized future. Native transaction assertions are poised to be a cornerstone of this future, empowering users with unprecedented control and certainty over their on-chain interactions.
