How native transaction assertions could enforce a transaction’s final outcome

The Ethereum ecosystem, a cornerstone of decentralized finance (DeFi) and Web3 innovation, is taking a significant leap forward in user protection with the exploration of native transaction assertions. This critical development, spearheaded by the Ethereum Foundation’s "Trillion Dollar Security initiative," aims to address fundamental vulnerabilities inherent in the current transaction model, specifically blind signing and the uncertainty surrounding transaction outcomes. By introducing a mechanism to programmatically enforce a transaction’s final state, Ethereum seeks to mitigate substantial financial risks for users and enhance the overall integrity of the network. This comprehensive article delves into the motivations behind this initiative, the technical solutions proposed, and the profound implications for the future of decentralized applications.

Unpacking the Problem: The Peril of Unforeseen Outcomes

At its core, the problem stems from a disconnect between a user’s intent when signing a transaction and the actual outcome produced on the blockchain. Unlike traditional financial systems where a signature guarantees a specific, pre-defined result, an Ethereum signature commits only to a request – a set of instructions (calldata) directed at a target contract with a specific value. The execution of these instructions, however, is dynamic. It depends on the contract’s code, the prevailing network state at the moment of execution, and even the order in which transactions are processed. This inherent flexibility, while powerful, opens doors for malicious actors and unintended consequences, leading to two primary categories of failure: intent mismatch and outcome mismatch.

Intent Mismatch: When What You Sign Isn’t What You See

Intent mismatch occurs when a user believes they are authorizing one action, but the underlying transaction data, often obscured or manipulated, requests something entirely different. This vulnerability is frequently exploited through compromised frontends or sophisticated malware that injects malicious payloads at the point of signing.

A stark example of this was the Bybit incident, a critical security event that highlighted the dangers of blind signing. In this attack, users of the Bybit exchange who were interacting with a Safe (formerly Gnosis Safe) multisig wallet were led to believe they were performing routine operations. Unbeknownst to them, a compromised frontend had subtly altered the transaction data. Instead of approving a benign operation, the signers authorized the replacement of the Safe’s implementation contract – a deeply privileged action that could hand over control of vast assets. The users’ signatures were valid, but the intent presented to them visually was entirely different from the intent encoded in the transaction. This incident underscored how a valid cryptographic signature alone offers no protection if the signer is unaware of the true nature of the data being signed.

Similarly, the BadgerDAO attack in December 2021 saw users collectively lose approximately $130 million in cryptocurrencies. The sophisticated phishing attack involved a malicious script injected into the BadgerDAO website’s frontend. When users attempted to interact with the legitimate platform, the compromised frontend presented a seemingly normal transaction. However, the embedded malicious code injected an additional, hidden transaction that granted the attacker permission to spend the users’ tokens. Users, seeing what appeared to be their intended interaction, proceeded to sign these transactions. The signatures were valid for the malicious approval, leading to the draining of funds from their wallets without their explicit informed consent regarding the token approval.

Outcome Mismatch: When the Intended Request Goes Awry

Outcome mismatch, on the other hand, occurs even when the user signs precisely the transaction they intended, but the resulting state change on the blockchain deviates significantly from their economic goal or safety policy. This can happen due to volatile market conditions, insufficient liquidity, or adversarial transaction ordering (e.g., sandwich attacks).

The Aave and CoW collateral swap incident serves as a cautionary tale for outcome mismatch. A user aimed to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. While the user’s intention was clear – a significant exchange of assets – the underlying market conditions for aEthAAVE liquidity were extremely thin, making a trade of that size highly problematic. Furthermore, CoW Protocol’s gas ceiling during verification rejected more complex, potentially safer quotes, leaving only one highly unfavorable quote for a mere 329 aEthAAVE. Despite a clear 99.9% price impact warning displayed by the interface, and a requirement for the user to confirm potential total value loss, the user proceeded to sign the transaction. The result was a devastating loss, with the user receiving tokens valued at only around $36,000 instead of the anticipated multi-million dollar exchange. In this scenario, the signed request was precisely what the user was shown, but the final outcome was economically catastrophic and entirely contrary to their financial objective.

In all three instances – Bybit, BadgerDAO, and Aave/CoW – a fundamental missing element was a trusted, on-chain rule that could inspect and enforce the result of the transaction, independently of the transaction builder or the initial signing interface. For Bybit, such a rule would have prevented the Safe’s implementation contract from being changed. For BadgerDAO, it would have restricted new token approvals to only officially published Badger contracts. For the Aave user, a rule could have specified a minimum acceptable output for the aEthAAVE received, calculated independently of any frontend quote, thereby reverting the transaction if the output fell below the threshold. The critical limitation identified across the board is Ethereum’s lack of a native, general mechanism for on-chain code to examine the full set of net state changes and events produced by a transaction.

The Limits of Current Defenses

Ethereum’s development community has not been oblivious to these risks. Several defenses are currently employed to protect users, but each has inherent limitations:

• Clear Signing: This approach aims to humanize transaction data by decoding the raw calldata into a readable format, explaining the action the transaction requests. While a significant improvement over opaque hexadecimal strings, Clear Signing relies on accurate decoding and, crucially, on the user’s ability to recognize when the presented action deviates from their intent. It cannot, however, guarantee the outcome of that action, nor can it protect against a compromised frontend feeding a user a falsely decoded, yet maliciously structured, transaction.

• Simulation: Wallets and DApps frequently employ transaction simulation, which predicts a transaction’s effects by executing it against a selected chain state (e.g., the current block state or a future state with pending transactions). Simulations offer a powerful preview of potential outcomes. However, the chain state can change between the simulation and actual inclusion in a block, rendering the simulation inaccurate. More critically, as seen in the Radiant Capital incident, sophisticated malware on a user’s machine can substitute a malicious payload at the moment of signing, even if both the wallet interface and a prior simulation showed the intended, legitimate transaction. The simulation reflects the intended transaction, but not necessarily the signed one.

• Contract Checks and Wallet Guards: These on-chain mechanisms enforce rules during EVM execution. For instance, decentralized exchanges like Uniswap include amountOutMinimum parameters, which revert a swap if the output falls below a specified minimum. Similarly, Safe (Gnosis Safe) incorporates a checkAfterExecution hook, allowing a "guard" contract to inspect the account’s state after the transaction has run and revert if its predefined rules are violated. While effective for specific, pre-determined checks, these defenses require knowing which state to check in advance. They often rely on specific functions exposed by other contracts (e.g., a token’s balanceOf function for balance checks). If a contract (like a proxy’s implementation address) doesn’t expose a specific piece of state through a function, a guard cannot directly inspect that storage slot. Furthermore, a fundamental limitation is that these checks cannot inspect the full set of net state changes. A guard can confirm a particular balance is unchanged, but it cannot query the EVM for everything else that changed, leaving unexpected side effects potentially unnoticed.

The diagram illustrating how the signed request, code, and state determine the outcome effectively highlights the current vulnerability: a signature acts on the request, but the outcome is a function of the dynamic execution environment. This critical gap necessitates a more robust, native solution.

Native Transaction Assertions: Enforcing Desired Outcomes

Native transaction assertions represent a paradigm shift in how users can protect their assets on Ethereum. This proposed mechanism would allow on-chain code to inspect the entire set of net state changes after a transaction’s actions have been executed. Essentially, an assertion is a piece of read-only logic that compares the state before a transaction to the state after its execution against a predefined rule. If this rule is violated, the entire transaction (including its actions) is reverted, effectively preventing unwanted outcomes.

Crucially, this rule is included in the transaction itself and signed alongside its intended actions. This means the user explicitly authorizes not just the action, but also the conditions under which that action is deemed acceptable. The scope of these assertions is broad, capable of covering:

• Net changes to ETH balances: Ensuring a maximum amount of ETH spent or a minimum amount received.
• Storage modifications: Verifying that critical contract parameters remain unchanged (e.g., a Safe’s implementation address), or blocking new token approvals beyond a certain threshold.
• Newly deployed contracts and their code hashes: Preventing unauthorized contract deployments from a specific address.
• Emitted events: Checking for specific events that confirm or deny an expected action (e.g., a successful Transfer event).

The diagram showcasing how assertions check the outcome and revert transactions if rules fail vividly illustrates this protective layer. This powerful capability allows users to define a "safety perimeter" around their transactions, ensuring that even if the execution environment changes or a malicious input is introduced, the transaction will only succeed if the predefined safety conditions are met.

A crucial consideration for assertions is the source of the rule. A compromised frontend could, theoretically, craft a malicious assertion that permits an attack. Therefore, a useful rule must originate from an independently approved user intent, a standing account policy (e.g., defined by a smart contract wallet), or immutable protocol logic that cannot be altered by a compromised component. This emphasizes the need for robust wallet interfaces and secure methods for users to define and manage their assertion policies.

Design Choices and EIP-7906

The design of native transaction assertions involves several critical decisions regarding how the Ethereum Virtual Machine (EVM) exposes state change information, how assertion code accesses this data, and where these new opcodes can operate.

EIP-7906: A Concrete Proposal

One prominent approach is outlined in EIP-7906 (Transaction Assertions via State Diff Opcode), which builds upon the concept of "frame transactions" introduced in EIP-8141. EIP-8141 defines a new transaction type that contains an ordered sequence of validation and action steps, allowing for more complex, multi-stage transactions. EIP-7906 extends this by adding a read-only POST_TX frame at the very end of this sequence. This POST_TX frame is specifically designed to check the transaction’s outcome.

Current Status: EIP-8141 is currently scheduled for inclusion in the upcoming Hegotá upgrade, indicating a strong commitment to this foundational transaction type. EIP-7906, which leverages EIP-8141, has advanced to the "Considered for Inclusion" stage, signaling its high priority but awaiting final confirmation for a future network upgrade.

Technical Details of EIP-7906:

• Exposed Information: The design proposes exposing both net state changes and emitted events. State changes are reported as net differences in native ETH balances and storage. Crucially, if a storage slot is written to multiple times within a transaction, it appears as a single entry with its starting and final values. If a slot ends with its original value, it’s not reported at all, optimizing for efficiency. Newly deployed contracts and their code hashes are also reported.
• New Opcodes: Three new EVM instructions (opcodes) are introduced to access this information:
  • TXTRACE: Enumerates all net state changes and events. This allows for iterative inspection of all modifications.
  • TXDIFF: Retrieves starting and final values for specific addresses and storage slots, enabling targeted checks.
  • EVENTDATACOPY: Copies an event’s data into memory, allowing assertions to react to specific events.
• Execution Context: These new opcodes are strictly limited to execution within a POST_TX frame, which runs as a STATICCALL. This restriction is vital: it ensures that assertions can inspect the outcome without themselves modifying the state, preserving the integrity of the execution.
• Reversion Mechanism: If an assertion within the POST_TX frame fails, 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 gas consumed up to the point of failure. This design choice is crucial for network stability, preventing attackers from exploiting deliberately failing transactions to force builders (block producers) to perform free computation.

The Imperative of Required Assertions

While EIP-7906 provides the capability for native transaction assertions, it does not mandate their inclusion in every transaction. This implies a critical dependency on widespread adoption and enforcement mechanisms.

For user-initiated transactions, the responsibility falls heavily on wallets. A secure wallet must ensure that every frame transaction it constructs includes the necessary assertions. These rules could be derived from a real-time simulation performed by the wallet, or from a standing policy pre-configured by the user (e.g., "never spend more than X ETH," "never approve new tokens for unknown contracts," "always receive at least Y tokens in a swap"). This necessitates a new generation of "assertion-aware" wallets that empower users to define and manage these critical safety parameters.

For protocol-level security, protected functions within smart contracts would need to verify that incoming calls originate from a frame transaction that contains the exact required assertion. Such a function would reject ordinary transactions or frame transactions with missing or incorrect assertions. This would force callers and integrations to adopt compatible frame transactions. A significant challenge here lies with already deployed, immutable contracts, which cannot be updated to add this check retrospectively. This highlights a "cold start" problem for existing protocols, suggesting that new protocols or upgradeable contracts would be the early adopters.

Broader Implications and Future Applications

Beyond directly addressing blind signing and transaction uncertainty, native transaction assertions open a vast array of possibilities for enhancing the security, functionality, and trustworthiness of the Ethereum ecosystem:

• Strengthening Delegation: When users delegate authority to an agent (e.g., a smart contract or another wallet) to act on their behalf, assertions can provide granular control over the outcome of the agent’s actions. Beyond limiting which contracts an agent can interact with, how much it can spend, or the duration of its permissions, assertions can enforce specific post-execution conditions for each transaction. This means a user could constrain both what the agent may do and what its actions must ultimately produce.
• Protocol-Defined Safety: Protocols could define their own universal safety checks, requiring every caller using a frame transaction to adhere to these rules. This standardizes security across all interactions with the protocol.
• Solver-Based Execution Enhancement: In complex solver-based execution models (common in MEV-resistant trading), protocols could specify the required outcome of a transaction (e.g., a minimum token output), while leaving the specific route or execution strategy to the solver. This offers a powerful guarantee to users while maintaining flexibility for optimized execution. It is important to note, however, that this guarantee would apply only within a single transaction on a single network, not across multi-chain operations.
• Workflow Verification: Assertions could verify that multi-step workflows reach their intended final state. For example, they could ensure that any unused tokens are returned to the user, or that temporary token approvals granted during a complex interaction are automatically revoked post-execution. This prevents lingering vulnerabilities from forgotten approvals.
• Enhanced Auditability and Compliance: By explicitly defining and enforcing transaction outcomes on-chain, assertions could significantly improve the auditability of smart contract interactions and potentially aid in compliance efforts by providing verifiable guarantees about financial flows.
• Increased Institutional Adoption: For institutional players, the ability to programmatically enforce transaction outcomes and mitigate unforeseen risks is a critical factor for increasing confidence and facilitating broader adoption of decentralized technologies. Reducing the "unknown unknowns" associated with on-chain interactions aligns more closely with traditional risk management frameworks.

Shaping the Future of Ethereum Security

The "Trillion Dollar Security initiative" at the Ethereum Foundation is not merely a name; it reflects the immense value locked in the ecosystem and the existential importance of robust security measures. Solutions like native transaction assertions are pivotal in realizing this vision, moving Ethereum towards a future where user intent is not just signed, but truly protected.

The design of these foundational security primitives is an ongoing, collaborative effort. The Ethereum Foundation actively seeks input from the wallet development community, protocol teams, and security researchers who will be the primary users and beneficiaries of these advancements. Engaging with the process, whether by exploring specific use cases with the Trillion Dollar Security team via [email protected] or by participating in the ongoing EIP-7906 discussion thread on Ethereum Magicians, is crucial to shaping a more secure and predictable future for Ethereum.

As the network continues to evolve, initiatives like this underscore the commitment to making Ethereum not only the world’s leading decentralized platform but also its most secure. By transforming transaction uncertainty into verifiable assurance, native transaction assertions promise to unlock new levels of trust and functionality for millions of users worldwide. More information on risk controls and priority work can be found at trilliondollarsecurity.org.