Layla Zulfa
The Ethereum Foundation’s ambitious Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as critical user experience risks, prompting the exploration of native transaction assertions as a pivotal next step to enforce a transaction’s final outcome, working in concert with the previously introduced Clear Signing. This significant development underscores a concerted effort to fortify the security posture of the Ethereum ecosystem, which, with its vast Total Value Locked (TVL) and daily transaction volume, represents a financial landscape of immense global importance. The initiative aims to provide users with an unprecedented level of assurance that their on-chain actions will yield the precise, desired results, thereby mitigating risks associated with malicious frontends, unexpected state changes, and complex smart contract interactions.
The core of the problem lies in the fundamental operational mechanics of Ethereum, where the blockchain executes exactly what a user authorizes through a cryptographic signature, without inherent judgment on whether the resulting state aligns with the user’s intent. A signature on Ethereum commits to a specific request—comprising the target contract, the value transferred, and the calldata (instructions for the contract)—but the ultimate outcome of that request is profoundly influenced by the prevailing code and state of the network at the moment of execution. This separation between user intent, signed transaction, and final outcome has, on numerous occasions, led to significant financial losses for users. These unfortunate incidents typically fall into two categories: an intent mismatch, where the user approves something fundamentally different from what they believed, or an outcome mismatch, where the approved request still leads to an undesirable or economically detrimental result due to unforeseen market conditions or state changes.
The Genesis of Transaction Uncertainty: Case Studies in Catastrophic Mismatches
The history of decentralized finance (DeFi) on Ethereum is unfortunately punctuated by high-profile incidents that vividly illustrate the perils of transaction uncertainty. These events serve as a stark reminder of the urgent need for more robust on-chain security mechanisms.
One prominent example of an intent mismatch occurred during the Bybit incident, where attackers compromised a frontend interface. Unsuspecting signers, believing they were executing routine operations, inadvertently authorized the replacement of a Safe (formerly Gnosis Safe) implementation contract. This malicious change, unbeknownst to the users at the time of signing, granted attackers control over the Safe’s logic. Similarly, the BadgerDAO attack saw users granting broad token spending permissions to an attacker via a compromised frontend. In both scenarios, the cryptographic signature was valid, authenticating the transaction as originating from the legitimate user. However, the content of what was signed had been subtly altered, leading to an outcome drastically different from the users’ initial belief. In these cases, a trusted on-chain rule, independent of the transaction builder, that mandated the approved Safe implementation remain unchanged or restricted new token approvals only to verified Badger contracts, would have averted the catastrophe.
The other critical category, an outcome mismatch, is exemplified by the Aave and CoW collateral swap. A user initiated a swap of approximately $50.4 million in aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was severely insufficient for a trade of that magnitude. Furthermore, CoW Swap’s gas ceiling mechanism rejected more complex, potentially safer quotes during its verification process, leaving only one highly unfavorable verified quote of roughly 329 aEthAAVE. Despite the interface displaying a glaring 99.9 percent price impact warning and requiring explicit user confirmation of potential total value loss, the user proceeded to sign the transaction. The result was a devastating loss, with the user receiving tokens valued at merely $36,000. Here, the user signed precisely what was presented, yet the execution environment and prevailing market state conspired to produce an outcome that fundamentally contradicted their economic goal. A user-defined rule, setting a minimum acceptable output independently verified on-chain, would have prevented this catastrophic loss.
Crucially, in all these instances, the Ethereum blockchain, by its design, lacked a general, native mechanism for on-chain code to thoroughly inspect the entire set of net state changes and events generated by a transaction. This limitation leaves a critical gap in the user protection framework.
What a Signature Does Not Control: The Volatility of Execution Context
A user’s signature on Ethereum cryptographically binds them to a specific action—a call to a target contract, a value transfer, and specific calldata. However, the Ethereum Virtual Machine (EVM) executes this call against the contract code and state present at the time the transaction runs, not necessarily at the time the user signed it. This distinction is vital because the state can be highly dynamic. The resulting net balance changes, storage modifications, and emitted events can therefore diverge significantly from user expectations.
Consider a scenario where the target contract uses a proxy pattern. The underlying implementation contract, which defines the actual logic, can be upgraded or changed after a user signs a transaction but before it is executed on-chain. This means the code that ultimately runs might be entirely different from what the user initially inspected and implicitly trusted. Furthermore, transaction ordering can profoundly alter the state a user’s call encounters. For instance, a "sandwich attack" in decentralized exchanges (DEXs) can manipulate a liquidity pool’s price immediately before and after a user’s swap executes. The user’s signed transaction remains unchanged, but the economic outcome is severely degraded by front-running and back-running transactions. These examples highlight that while a signature confirms what a user wants to do, it offers no inherent guarantee of how the blockchain’s dynamic environment will process that action or what the final consequences will be.
The Current Security Landscape: Strengths and Blind Spots
Several layers of defense are currently employed to protect Ethereum users, each offering valuable but ultimately incomplete protection against the full spectrum of transaction risks.
Clear Signing, a key initiative aimed at enhancing user understanding, attempts to translate opaque hexadecimal calldata into human-readable actions. It explains to the user precisely what action the calldata requests (e.g., "Approve 1000 USDC to Uniswap Router"). This mechanism relies heavily on accurate decoding by the wallet or interface and the user’s ability to recognize if the decoded action deviates from their intent. While essential for preventing basic intent mismatches, it cannot foresee or prevent outcomes altered by dynamic state changes or malicious code updates after signing.
Transaction Simulation offers another layer of defense. Wallets and security services can simulate a transaction’s effects against a chosen chain state, providing a preview of potential outcomes. However, this simulation is merely a prediction. The actual chain state can change dramatically between the moment of simulation and the transaction’s eventual inclusion in a block. Moreover, sophisticated malware can substitute a malicious payload at the moment of signing, as tragically demonstrated in the Radiant Capital incident. In this case, both the wallet interface and the simulation displayed the intended, legitimate transaction, but malware on the signer’s machine stealthily replaced it with a fraudulent one just as the user clicked "sign." The simulation was correct for the displayed transaction, but not for the signed one.
Contract Checks and Wallet Guards enforce rules during EVM execution. Protocols like Uniswap implement checks such as amountOutMinimum, reverting a swap if the output falls below a user-defined threshold. Smart contract wallets like Safe utilize checkAfterExecution hooks, allowing a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined safety policies (e.g., "no changes to owner configuration"). While effective for specific, pre-defined conditions, these approaches require choosing which state variables to check in advance. They also depend on the target contract exposing functions to read relevant storage. For instance, balanceOf() makes balance checks straightforward, but a proxy contract might not expose its implementation address through a function, preventing a guard from directly reading a critical implementation slot.
The fundamental limitation across all these existing defenses is their inability to inspect the full set of net state changes generated by a transaction. A guard can confirm that a specific balance remains unchanged, but it cannot ask the EVM what else was modified across the entire state tree. Consequently, unforeseen or indirectly affected state changes, not explicitly targeted by the guard’s design, can go unnoticed, leaving potential attack vectors open.
Pioneering a New Defense: Native Transaction Assertions
Native transaction assertions represent a paradigm shift in Ethereum’s security architecture. This proposed mechanism would empower on-chain code to comprehensively inspect the entire set of net state changes after a transaction’s primary actions have been executed. An assertion functions as read-only logic that compares the initial and final values of state elements against a predefined rule. If this rule is violated, the entire transaction’s actions are automatically reverted, ensuring that undesirable outcomes never become permanent on the blockchain.
Crucially, the assertion rule is included within the transaction itself and cryptographically signed alongside its actions. This ensures that the user’s intent regarding the outcome is immutable and enforced on-chain. These rules can be highly granular and versatile, covering:
- Balance Changes: Requiring a minimum amount received in a swap or capping maximum spending.
- Storage Modifications: Blocking new token approvals, preserving an account’s critical control logic (e.g., proxy implementation addresses), or permitting only a specified, whitelisted set of changes.
- Newly Deployed Contracts: Ensuring only authorized contracts are deployed.
- Emitted Events: Verifying specific events were emitted (or not emitted) as expected.
The power of assertions lies in their ability to act as an on-chain firewall, validating the result of a transaction against a predefined safety policy. The diagram below illustrates how assertions would integrate into the transaction lifecycle, checking the outcome and reverting the transaction’s actions if any rules fail.
[Image: How assertions on Ethereum check the outcome and revert the transaction’s actions if the rules fail] (This refers to the image in the original article)
The source of the assertion rule is as critical as the rule itself. A compromised frontend, capable of manipulating the primary transaction, could equally inject a malicious assertion that permits the attack. Therefore, a truly useful rule must originate from an independently approved source of user intent, a standing account policy (e.g., defined in a smart contract wallet), or protocol logic that cannot be unilaterally altered by a compromised client-side component. This independent validation is paramount to the effectiveness of native transaction assertions.
EIP-7906: A Technical Blueprint for State Diff Opcode
The technical implementation of native transaction assertions is being explored through various proposals, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate. This Ethereum Improvement Proposal builds upon the "frame transactions" concept introduced in EIP-8141.
EIP-8141 defines a new transaction type that encapsulates an ordered sequence of validation and action steps within a single transaction. EIP-7906 extends this by adding a crucial, read-only POST_TX frame at the very end of this sequence. This POST_TX frame is specifically designed to inspect the transaction’s final outcome. EIP-8141 is currently scheduled for inclusion in the upcoming Hegotía upgrade, signaling a broader architectural shift towards more structured transaction types. EIP-7906, having advanced to "Considered for Inclusion," is a strong contender for future upgrades, though its final confirmation is pending.
The design of EIP-7906 exposes both state changes and emitted events. State changes are reported as net differences:
- Native ETH Balances: Changes in ETH holdings.
- Storage: Net modifications to storage slots. A slot written to multiple times within a transaction will only appear once with its starting and final values. If a slot reverts to its original value, it will not appear in the diff at all.
- Newly Deployed Contracts: Identification of new contracts and their code hashes.
To access this critical information, EIP-7906 proposes three new EVM opcodes (low-level instructions):
TXTRACE: This opcode allows enumeration of all net state changes and emitted events, providing a comprehensive overview.TXDIFF: This opcode enables retrieval of starting and final values for specific addresses and storage slots, allowing targeted checks.EVENTDATACOPY: This opcode facilitates copying an event’s data into memory for detailed inspection.
These opcodes are deliberately restricted to function only within a POST_TX frame, which executes as a static call. This crucial design choice ensures that the assertion logic can inspect the outcome without inadvertently introducing new state changes itself. If an assertion rule within the POST_TX frame 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 to prevent attackers from exploiting assertions by crafting deliberately failing transactions to force builders to perform free computation.
The Mandate for Assertions: Implementation Challenges and Opportunities
While EIP-7906 provides the technical foundation, it does not mandate the inclusion of an assertion in every transaction. This leaves a critical gap: who ensures the assertion is present and correct?
For a user’s own transactions, the responsibility largely falls on the wallet provider. Wallets must evolve to ensure that every frame transaction they construct includes a required assertion. This assertion could be dynamically generated based on a simulation run by the wallet, or it could be derived from a standing security policy that the user has configured to apply to all their transactions (e.g., "never approve more than $X to a new contract"). This places a significant burden and opportunity on wallet developers to integrate these new capabilities seamlessly and securely.
For protocols, the situation is more nuanced. A protected function within a smart contract could be designed to verify that any incoming call originates from a frame transaction containing the exact required assertion. It would then reject ordinary transactions or frame transactions with missing or incorrect assertions. This would force callers and integrations to adopt compatible frame transactions. However, a significant challenge arises with already deployed, immutable contracts, which cannot be updated to incorporate this new check. This suggests a gradual adoption curve, where new protocols or upgraded versions of existing protocols would be the primary beneficiaries.
Broader Implications and Future Horizons
Beyond the immediate security benefits for individual users and protocols, native transaction assertions unlock a range of broader use cases, promising a more secure and predictable Ethereum ecosystem.
One compelling application is the strengthening of delegation. When users delegate authority to an agent (e.g., a smart contract or a third-party service) to act on their behalf, they typically impose constraints on what the agent can do (e.g., which contracts it can interact with, how much it can spend, the duration of permissions). Assertions can add a powerful layer of control by allowing users to define rules for the outcome of each delegated transaction. This means a user can constrain both the actions an agent may take and the specific results those actions must produce, creating a more robust and trustworthy delegation framework.
Protocol-defined safety checks can also become universal. A protocol could define its own critical safety rule (e.g., "no more than X% price slippage on a swap") and require every caller using a frame transaction to include and pass this assertion. This ensures a consistent level of safety across all interactions with the protocol. In complex solver-based execution models (common in MEV-resistant systems), the protocol could specify the required outcome for a trade, granting the solver maximum flexibility in determining the optimal execution path, while still guaranteeing the user’s desired result. It’s important to note that this guarantee would apply only within a single transaction on a single network, not covering multi-chain operations.
Assertions could also play a vital role in workflow verification. Complex multi-step operations could be designed with final assertions to ensure the workflow reaches its intended end state, with all intermediate steps successfully completed, unused tokens returned to the user, and any temporary token approvals revoked. This provides a robust mechanism for ensuring the integrity of intricate on-chain processes.
Ethereum’s "Trillion Dollar Security" Vision: A Collaborative Future
The Ethereum Foundation’s Trillion Dollar Security initiative is a testament to the community’s unwavering commitment to enhancing the safety and reliability of the network. The pursuit of native transaction assertions, alongside ongoing efforts like Clear Signing, signifies a proactive stance against the evolving threats in the decentralized landscape. By addressing fundamental issues like blind signing and transaction uncertainty, the initiative aims to cultivate an environment where users can interact with confidence, knowing that the blockchain itself provides a robust layer of protection for their digital assets and financial intentions. This long-term vision seeks to cement Ethereum’s position as a secure and trusted global settlement layer.
The design and implementation of solutions for native transaction assertions are still in active development. The Ethereum Foundation emphasizes the collaborative nature of this endeavor, urging wallet and protocol teams—the ultimate users and beneficiaries of these advancements—to engage directly in shaping the design. Stakeholders are invited to explore use cases, provide feedback, and contribute to the ongoing research by contacting [email protected] or joining the public discussion on the EIP-7906 discussion thread on Ethereum Magicians. Further information on the broader risk controls and priority work of the initiative can be found at trilliondollarsecurity.org. The future of secure and predictable on-chain interactions hinges on this collective effort to embed user intent directly into the very fabric of Ethereum’s transaction execution.
