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

The Ethereum ecosystem, a bedrock of decentralized finance (DeFi) and Web3 innovation, is undergoing a pivotal transformation aimed at bolstering user security against increasingly sophisticated threats. With billions of dollars in assets transacted and secured daily, the integrity of every interaction is paramount. The "Trillion Dollar Security" initiative by the Ethereum Foundation represents a concerted effort to address fundamental vulnerabilities that have historically led to significant user losses. At the forefront of this endeavor is the exploration of "native transaction assertions," a groundbreaking mechanism designed to ensure that the outcome of an on-chain transaction precisely matches the user’s intent, regardless of external factors or malicious interference. This new approach seeks to complement existing safeguards like "Clear Signing" by providing a robust, on-chain enforcement layer that validates a transaction’s final state.

The Problem: Understanding Transaction Risks

Despite the cryptographic assurances of a valid signature, the inherent architecture of Ethereum allows for scenarios where a signed transaction does not yield the desired result. This disconnect between user intent and actual outcome stems from two primary issues: blind signing and transaction uncertainty.

Anatomy of a Flawed Transaction

Ethereum’s Virtual Machine (EVM) executes transactions based on the precise instructions authorized by a signature. However, it operates without an intrinsic understanding of the user’s ultimate economic or security goals. A signature merely commits to a request, but its final outcome is dynamically determined by the underlying smart contract code and the prevailing network state at the moment of execution. This dynamic environment creates two critical failure points:

1. Intent Mismatch: The user believes they are approving one action, but the actual signed request, often obscured or maliciously altered, directs the EVM to perform something entirely different. This is the essence of "blind signing," where users sign a hash without fully comprehending the data payload it represents.
2. Outcome Mismatch: The user approves the transaction as intended, but unforeseen external conditions or the transaction’s inherent limitations lead to an undesirable or economically detrimental result. This "transaction uncertainty" can arise from fluctuating market conditions, sandwich attacks, or changes in contract logic.

High-Profile Incidents Underscore Vulnerabilities

Several high-profile incidents have starkly illustrated the real-world consequences of these vulnerabilities, resulting in millions of dollars in losses and eroding user trust.

• Bybit Incident (May 2025 – inferred timeline): In an incident confirmed by Bybit, a compromised frontend supplied a malicious signing request. Users of a Safe (formerly Gnosis Safe) multi-signature wallet were unknowingly prompted to authorize a critical change: replacing the Safe’s implementation contract. This meant that the core logic governing the Safe wallet’s operations could be swapped out for a malicious version, potentially granting attackers full control over the funds held within. While Bybit confirmed the integrity of its own infrastructure, the incident highlighted how external vulnerabilities in user interfaces could subvert even robust smart contract security. A native transaction assertion could have mandated that the Safe’s implementation contract remain unchanged, reverting any transaction attempting to alter it.

• BadgerDAO Attack (December 2021): The BadgerDAO protocol suffered a significant exploit where a sophisticated attack, leveraging a compromised frontend, led to approximately $130 million in losses. Attackers injected malicious code into the website, which then presented legitimate-looking transaction requests to users. These requests, when signed, unknowingly granted the attacker permissions to spend users’ tokens. Users, believing they were interacting with the genuine BadgerDAO interface, unknowingly authorized token approvals to an attacker-controlled address. Had native transaction assertions been in place, a user could have stipulated a rule allowing new token approvals only for a predefined list of verified BadgerDAO contracts, preventing unauthorized transfers.

• Aave and CoW Collateral Swap (inferred 2023-2024 timeframe based on article references): This case exemplifies an "outcome mismatch." A user initiated a swap on a decentralized exchange (DEX) via CoW Protocol, aiming to exchange approximately $50.4 million of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was exceptionally thin for such a large trade. Compounding the issue, CoW Protocol’s gas ceiling mechanisms rejected more complex, potentially better-priced quotes during verification, leaving only one highly unfavorable option. Despite a prominent 99.9% price impact warning displayed by the interface, the user proceeded with the transaction, ultimately receiving only about 329 aEthAAVE, valued at roughly $36,000 – a staggering loss of over $50 million. In this scenario, a native transaction assertion could have specified a minimum acceptable output amount, calculated independently of the initial quote, ensuring the transaction would revert if the received tokens fell below a predefined threshold. This would have provided an on-chain safety net that the user interface’s warning, unfortunately, failed to enforce.

These incidents underscore a critical gap: the absence of a universally trusted, on-chain mechanism to enforce rules over the resulting state of a transaction, independent of its builder or the initial signing request. Current Ethereum architecture lacks a general method for smart contracts to inspect the comprehensive set of net state changes and events produced by a transaction’s execution.

What a Signature Does Not Control

A user’s signature cryptographically commits to a specific action: the target contract, the value transferred, and the calldata (the instructions for the contract). However, the Ethereum Virtual Machine (EVM) executes this call against the contract code and the global state at the moment the transaction runs. This is a crucial distinction, as the code or state might have changed since the user initially signed the transaction. Consequently, the resulting net balance and storage changes, along with any emitted events, can deviate significantly from what the user expected.

For instance, a smart contract might employ a proxy pattern, allowing its underlying implementation logic to be upgraded. If the implementation contract is changed between the time a user signs a transaction and its execution, the code that actually runs could be entirely different from what the user inspected. Similarly, transaction ordering, influenced by MEV (Maximal Extractable Value) strategies, can alter the state a transaction encounters. A classic example is a sandwich attack, where an attacker front-runs and back-runs a user’s swap on a DEX, manipulating the pool’s price to extract value from the user’s trade, all without changing the user’s original signed transaction.

Limitations of Existing Safeguards

Current defenses, while valuable, exhibit inherent limitations in addressing the full spectrum of intent and outcome mismatches.

The Inadequacy of Current Defenses

1. Clear Signing: This defense aims to present users with a human-readable interpretation of the calldata, explaining the action being requested. Its effectiveness hinges on two factors: the accuracy of the decoding mechanism (which can be complex for intricate contract interactions) and the user’s ability to recognize if the decoded action deviates from their actual intent. It’s a significant improvement over opaque hashes, but it’s still reactive and relies on user vigilance.

2. Simulation: Wallets and dApps often provide transaction simulations, predicting the effects of a transaction against a chosen chain state. While helpful, simulations are not guarantees. The actual chain state can change between the simulation and the transaction’s inclusion in a block. More critically, as seen in the Radiant Capital incident (January 2023), malware on a signer’s machine can substitute a malicious payload at the exact moment of signing, even if the wallet interface and prior simulation displayed the intended transaction. Radiant Capital experienced an oracle manipulation attack that resulted in a loss of over $4.5 million, highlighting that even when users are shown correct information, the final signed payload can be tampered with before broadcast.

3. Contract Checks and Wallet Guards: These mechanisms enforce rules during EVM execution. For example, Uniswap’s amountOutMinimum feature reverts a swap if the output falls below a specified threshold, mitigating slippage. Safe wallets utilize a checkAfterExecution hook, allowing a guard contract to inspect the account’s state post-execution and revert transactions violating predefined security policies. However, these approaches require defining specific state checks in advance. They also depend on the target contract exposing relevant functions (e.g., balanceOf for token balances, which is common). If a proxy contract doesn’t expose its implementation address through a public function, a guard cannot directly read the critical storage slot containing that address. Crucially, these checks cannot inspect the full set of net state changes generated by a transaction. A guard can verify a specific balance remains unchanged, but it cannot ask the EVM for a comprehensive list of all other changes, leaving undetected any unintended side effects not explicitly coded into the guard.

Introducing Native Transaction Assertions: A Paradigm Shift in Security

Native transaction assertions represent a fundamental shift in Ethereum’s security paradigm, moving from merely verifying the request to enforcing the outcome.

How Assertions Fortify User Intent

Native transaction assertions would empower on-chain code to inspect the entire set of net state changes after a transaction’s actions have been fully executed. An assertion functions as a read-only logic gate that compares the starting and final values of specified state components against a predefined rule. If this rule is violated, the entire transaction is automatically reverted.

Crucially, this rule is included in the transaction itself and cryptographically signed alongside the primary actions. This means the user explicitly authorizes not just what the transaction does, but also what its outcome must be. Assertions can cover a broad spectrum of state changes, including:

• Net changes to native ETH balances.
• Modifications to contract storage (e.g., preventing changes to critical configuration variables).
• Newly deployed contracts and their associated code hashes (e.g., ensuring only approved contracts are deployed).
• Emitted events (e.g., verifying specific events were or were not emitted).
• Requiring a minimum amount of tokens received in a swap.
• Capping maximum spending limits.
• Blocking new token approvals to unauthorized addresses.
• Preserving an account’s control logic (e.g., ensuring a multi-sig owner list remains unchanged).
• Allowing only a specified, whitelisted set of changes.

The Critical Role of Rule Origination

The efficacy of native transaction assertions hinges not just on the check itself, but on the trusted source of the assertion rule. A compromised frontend could, for instance, generate an assertion that permits an attack. Therefore, a truly useful rule must originate from:

1. Independently Approved User Intent: The user directly defines the outcome assertion, perhaps through a secure hardware wallet or an air-gapped signing device.
2. Standing Account Policy: A user’s wallet or smart account has predefined, immutable security policies that apply to all transactions (e.g., "never approve tokens to unknown addresses").
3. Protocol Logic: A decentralized protocol itself mandates specific outcome assertions for interactions with its contracts, ensuring all users engaging with it benefit from the same security guarantees.

EIP-7906: A Concrete Proposal

One prominent approach under consideration for implementing native transaction assertions is EIP-7906 (Transaction Assertions via State Diff Opcode). This Ethereum Improvement Proposal builds upon the foundational concept of "frame transactions" defined in EIP-8141.

Frame Transactions and the POST_TX Mechanism

EIP-8141 introduces a new transaction type: the "frame transaction." This transaction type allows for an ordered sequence of validation and action steps to be bundled and executed atomically. EIP-7906 extends this by adding a crucial, read-only POST_TX frame at the very end of the transaction’s execution. This POST_TX frame is designed specifically to check the transaction’s final outcome.

The POST_TX frame executes as a static call, meaning it can inspect the state but cannot modify it. This read-only nature is vital for security, as it prevents the assertion logic itself from inadvertently or maliciously altering the blockchain state. If the assertion rule within the POST_TX frame fails, the entire execution body of the transaction is reverted, effectively nullifying all its preceding actions. 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 critical for preventing denial-of-service (DoS) attacks, where malicious actors might otherwise spam the network with deliberately failing transactions without incurring any cost.

New Opcodes for Comprehensive State Inspection

To enable the POST_TX frame to effectively inspect the final state, EIP-7906 proposes three new EVM opcodes (low-level instructions):

1. TXTRACE: This opcode enumerates the net state changes and events produced by the transaction. It provides a comprehensive list of all modifications, including native ETH balance changes, storage slot alterations, newly deployed contracts, and emitted events. A key feature is its efficiency: if a storage slot is written to multiple times within a transaction, TXTRACE reports it as a single entry, showing only its starting and final values. If a slot is written to and then reverted to its original value, it does not appear in the trace at all, providing a concise summary of net changes.
2. TXDIFF: This opcode allows assertion code to retrieve the starting and final values for specific addresses and storage slots. Instead of enumerating all changes, TXDIFF enables targeted queries, making it efficient for checking particular conditions (e.g., "what was the balance of token X for address Y before and after?").
3. EVENTDATACOPY: This opcode facilitates copying an event’s data into memory, enabling the assertion logic to verify the contents of emitted events, which are often crucial for signaling state changes or actions within a protocol.

The design of EIP-7906 specifically restricts these new opcodes to operate only within a POST_TX frame. This ensures that the powerful ability to inspect the entire state diff is contained within a designated, read-only security context.

Implementation Status and Future Upgrades

EIP-8141, which defines the underlying frame transaction structure, is currently scheduled for inclusion in the upcoming "Hegotã" Ethereum upgrade (inferred future upgrade name based on Hegotã). EIP-7906, building on this foundation, has advanced to the "Considered for Inclusion" stage, indicating significant interest and progress within the Ethereum core development community, though its definitive inclusion in a specific upgrade is yet to be confirmed. The development timeline suggests a strong push for these security enhancements in the near to mid-term future of Ethereum.

Challenges and Enforcement

While native transaction assertions offer a powerful new layer of security, their effectiveness hinges on widespread adoption and robust enforcement mechanisms.

Ensuring Widespread Adoption and Mandating Assertions

A significant challenge for EIP-7906, in its current form, is that it does not require transactions to include an assertion. This means that a malicious or compromised transaction builder could simply omit the assertion, bypassing the intended security guarantee. To overcome this, two primary enforcement pathways are envisioned:

1. Wallet-Level Enforcement: For user-initiated transactions, wallets must be updated to ensure that every frame transaction they construct includes the necessary assertions. These rules could be dynamically generated based on a simulation run by the wallet or stem from a pre-configured, standing security policy defined by the user for all their transactions (e.g., "always ensure I receive at least X amount of ETH in any swap"). This places a significant responsibility on wallet developers to integrate and promote this feature.

2. Protocol-Level Enforcement: Decentralized protocols can enforce assertions for interactions with their own smart contracts. A protected function within a protocol’s contract would need to verify that the incoming call originates from a frame transaction that contains the exact required assertion. It would be designed to reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach would mandate the use of compatible frame transactions for specific protocol interactions. However, a limitation for already deployed, immutable smart contracts is that they cannot be upgraded to add this verification logic, meaning new deployments or upgradeable proxies would be necessary.

Beyond Security: Expanding Use Cases for Assertions

Beyond their primary role in fortifying user security, native transaction assertions open doors to a myriad of other innovative use cases, strengthening the overall functionality and trust within the Ethereum ecosystem.

Empowering Secure Delegation and Protocol Integrity

1. Enhanced Delegation: The ability to delegate actions to an agent (e.g., a bot, another wallet, or a smart contract) is a powerful feature in Web3. Currently, delegation relies on limiting what an agent can do (which contracts it uses, how much it spends, duration of permissions). Assertions could add a crucial layer by defining rules for the outcome of each delegated transaction. For example, a user could delegate trading authority but assert that any trade must result in a net gain of at least 0.5% or never result in a loss of more than 10% of the principal. This allows users to constrain both the agent’s actions and the results those actions must produce.

2. Protocol-Defined Safety Checks: Protocols could define universal safety rules that apply to all interactions. For instance, a lending protocol might require an assertion that a liquidation transaction always results in the lender receiving their collateral plus interest, without any unexpected side effects. This ensures a consistent level of security and predictability for all users interacting with the protocol via frame transactions.

3. Flexible Solver Execution: In complex transaction routing scenarios, such as those facilitated by solver-based decentralized exchanges, assertions could allow protocols to specify the required outcome of a transaction (e.g., "I need to receive at least 100 USDC") while granting the solver the flexibility to choose the optimal execution route across various liquidity sources. This separates the "what" from the "how," providing both user assurance and operational efficiency. It’s important to note, however, that this guarantee would apply only within a single transaction on a single network, not across multiple chains.

4. Workflow Completion Assurance: Assertions could be used to verify that multi-step workflows reach their intended final state. For example, after a complex DeFi interaction, an assertion could confirm that any unused tokens are returned to the user, or that temporary token approvals granted for the transaction are subsequently revoked, minimizing lingering security risks.

The Path Forward: Collaborative Development

The development of native transaction assertions is a cornerstone of the Ethereum Foundation’s "Trillion Dollar Security" initiative, representing a proactive step towards building a more secure and predictable decentralized future. The complexity and criticality of this feature necessitate broad community involvement. Wallet providers, protocol developers, and security researchers are encouraged to actively participate in shaping the design and implementation of these vital safeguards.

Engagement opportunities include contacting the Trillion Dollar Security team directly at [email protected] to discuss specific use cases and contribute to the research, or joining the public discussion on the EIP-7906 discussion thread on Ethereum Magicians (ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130). Further information on risk controls and priority work within the initiative can be found at trilliondollarsecurity.org. Collaborative efforts are essential to ensure that Ethereum continues to evolve as a secure and reliable platform for global innovation.