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

This pivotal development signals a concerted effort by the Ethereum Foundation to fortify the security landscape of the world’s leading smart contract platform, addressing fundamental vulnerabilities that have led to significant user losses and eroded trust. The initiative, first unveiled on May 14, 2025, underscores the immense value secured by the Ethereum network, which necessitates robust, protocol-level security enhancements. Native transaction assertions are designed to provide an unprecedented layer of on-chain verification, allowing users and protocols to programmatically define and enforce the expected outcomes of transactions, thereby mitigating risks stemming from malicious actors, compromised interfaces, and unforeseen state changes. This new mechanism is being developed in parallel with Clear Signing, an earlier announcement from May 12, 2026, which aims to provide users with transparent and human-readable transaction details before signing.

The Core Challenge: Understanding Transaction Uncertainty

At the heart of Ethereum’s security dilemma lies its deterministic execution model coupled with a dynamic environment. While the Ethereum Virtual Machine (EVM) executes precisely what a user authorizes, it operates without inherent judgment on the desired outcome. A user’s digital signature commits to a specific transaction request, but the ultimate result of that request is contingent upon the smart contract code and the prevailing blockchain state at the exact moment of execution. This inherent characteristic opens the door to two critical failure modes: intent mismatch and outcome mismatch, both of which have been exploited in high-profile incidents across the ecosystem.

An intent mismatch occurs when a user signs a transaction believing they are authorizing one action, but the actual calldata or underlying contract interaction is entirely different. This is often the result of sophisticated phishing attacks, front-end compromises, or malware injecting malicious payloads into legitimate signing requests. The user’s displayed intent in their wallet may not correspond to the actual data being broadcast to the network.

An outcome mismatch, conversely, happens when the user signs a transaction with a clear understanding of their intended action, but the execution against the current chain state or other external factors leads to an undesirable or economically detrimental result. This can be due to factors like thin liquidity, unexpected price slippage, or reordering of transactions by miners/validators (MEV – Maximal Extractable Value), where the signed parameters, while valid, do not adequately protect against adverse outcomes.

The current challenge is that Ethereum lacks a general, native mechanism for on-chain code to comprehensively inspect the full set of net state changes and events produced by a transaction after its execution but before its final commitment to the blockchain state. This absence is the critical gap that native transaction assertions aim to fill.

Case Studies: Lessons from Major Incidents

The urgency for native transaction assertions is highlighted by several costly incidents that exemplify these mismatches, collectively underscoring the "Trillion Dollar Security" imperative.

One prominent example of an intent mismatch is the Bybit incident, where signers of a Safe (formerly Gnosis Safe) multisig wallet inadvertently authorized the replacement of the Safe’s implementation contract. This was not the intended action; instead, a compromised frontend supplied a signing request that subtly differed from what the users believed they were approving. Such an attack bypasses typical security checks because the signature itself is cryptographically valid for the malicious request, not the intended one. Had there been an assertion requiring the Safe implementation contract to remain unchanged, the transaction would have reverted.

Similarly, the BadgerDAO attack in December 2021 saw users grant attackers permission to spend their tokens. This sophisticated social engineering and front-end compromise resulted in approximately $120 million in user funds being siphoned. Users believed they were interacting with the legitimate BadgerDAO platform, but malicious code injected into the website altered the transaction request, leading them to unknowingly approve token spending for the attacker’s addresses. A native assertion could have been configured to permit new token approvals only for a predefined list of trusted BadgerDAO contracts, effectively blocking the malicious approval.

An example of an outcome mismatch is the Aave and CoW collateral swap incident. A user attempted to swap approximately $50.4 million of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was severely insufficient for a trade of that magnitude. Despite a 99.9% price impact warning displayed by the interface, and the requirement for the user to confirm that the entire value could be lost, the user proceeded with the transaction. Due to CoWSwap’s gas ceiling rejecting more complex, better-priced quotes during verification, the transaction settled for a meager 329 aEthAAVE, valued at roughly $36,000 – a catastrophic loss of over 99.9% of the initial value. In this scenario, the user’s intent was to execute a swap, but the outcome was drastically misaligned with their economic goal. A native assertion could have mandated a minimum acceptable output amount, calculated independently of the initial quote, ensuring the transaction would only succeed if a reasonable amount of aEthAAVE was received.

These incidents underscore a critical vulnerability: the absence of a trusted, on-chain mechanism to define and enforce rules over the resulting state changes of a transaction, independent of the transaction builder or the initial signing request.

Current Defenses and Their Limitations

Today’s Ethereum ecosystem employs several defense mechanisms, but each has inherent limitations in preventing intent and outcome mismatches:

1. Clear Signing: This defense focuses on improving the user experience by explaining, in human-readable terms, the action requested by the calldata. It relies on accurate decoding of transaction data and the user’s ability to recognize if the decoded action deviates from their intent. While crucial for transparency, Clear Signing alone cannot guarantee the outcome. A user might clearly understand the action but still suffer an adverse result due to dynamic chain state changes or insufficient liquidity, as seen in the Aave/CoW example.

2. Simulation: Wallets and DApps often use simulation services to predict a transaction’s effects against a chosen chain state. This provides a valuable preview. However, simulations are not guarantees. The actual chain state can change between the time of simulation and the transaction’s inclusion in a block. Furthermore, as demonstrated in the Radiant Capital incident (detailed in their post-mortem), malware on a signer’s machine can substitute a malicious payload at the moment of signing, even if the wallet interface and simulation correctly showed the intended transaction. The signed transaction might differ from the one simulated, rendering the simulation ineffective.

3. Contract Checks and Wallet Guards: Smart contracts themselves, or external guard contracts (like those used with Safe accounts), can enforce rules during EVM execution. For instance, Uniswap reverts a swap if the output falls below a user-defined amountOutMinimum. Safe’s checkAfterExecution hook allows a guard to inspect an account’s state post-execution and revert transactions violating predefined rules. While effective for specific, pre-programmed conditions, these checks face limitations:

   • Pre-defined State: They require choosing which specific state variables to check in advance.
   • Limited Visibility: They can only read state through functions exposed by other contracts. A token’s balanceOf is straightforward, but a proxy contract might not expose its implementation address directly, preventing a guard from reading the implementation slot.
   • Partial Inspection: Crucially, these existing checks cannot inspect the full set of net state changes across the entire transaction. A guard can verify if a particular balance remains unchanged, but it cannot query the EVM about everything else that changed. Unforeseen side effects or changes to unchecked variables can therefore go unnoticed.

These limitations highlight the need for a more comprehensive, native solution that can inspect the entirety of a transaction’s impact on the blockchain state.

Native Transaction Assertions: A Paradigm Shift in Security

Native transaction assertions represent a fundamental shift in how transaction security is conceptualized and enforced on Ethereum. They empower users and protocols to define rules that must hold true for a transaction’s final outcome, making security an intrinsic part of the transaction lifecycle rather than an external or pre-execution check.

The core principle is straightforward: an assertion is a piece of read-only logic included in a transaction and signed alongside its actions. After the transaction’s primary actions have run, this assertion logic compares the initial state values with the final state values against the predefined rule. If the rule is violated, the entire set of transaction actions is reverted, ensuring that only desired outcomes are permanently recorded on the blockchain.

These assertions are designed to be incredibly versatile, capable of covering a wide array of net changes:

• Balances: Ensuring minimum received amounts or capping spending.
• Storage: Preventing unauthorized changes to critical contract parameters (e.g., preserving an account’s control logic, ensuring a proxy’s implementation address remains unchanged).
• Code: Verifying no new contracts were deployed or existing code was not altered unexpectedly.
• Events: Checking for the emission of specific events that confirm intended actions or the absence of unexpected ones.

For example, an assertion could:

• Require a minimum output for a token swap, protecting against severe slippage.
• Block new token approvals, preventing attacks like BadgerDAO.
• Ensure that the implementation address of a critical proxy contract remains unchanged, preventing incidents like Bybit.
• Allow only a specified set of state changes, acting as a powerful whitelist for transaction effects.

Crucially, the source of the assertion rule matters immensely. A compromised frontend could easily write an assertion that permits an attack. Therefore, a truly useful rule must originate from an independently approved user intent (e.g., explicitly defined by the user in a trusted wallet environment), a standing account policy (e.g., configured in a smart contract wallet), or protocol logic that cannot be manipulated by the compromised component. This ensures the integrity and trustworthiness of the assertion itself.

EIP-7906: A Concrete Proposal for Implementation

The technical backbone for realizing native transaction assertions is being explored through Ethereum Improvement Proposals (EIPs). One leading candidate is EIP-7906 (Transaction Assertions via State Diff Opcode), which builds upon the concept of "frame transactions" introduced in EIP-8141.

EIP-8141, currently scheduled for inclusion in the upcoming Hegotá network upgrade, defines a new transaction type: the "frame transaction." This transaction type allows for an ordered sequence of validation and action steps, providing more structured and flexible transaction execution. EIP-7906 extends this by adding a dedicated, read-only POST_TX frame at the very end of the transaction execution. This POST_TX frame is specifically designed to check the transaction’s outcome.

The design of EIP-7906 exposes both state changes and events for inspection. State changes are reported as net differences in native ETH balances and storage. This means if a storage slot is written to multiple times within a transaction but ultimately reverts to its original value, it will not appear in the net changes. Only the final, cumulative differences from the transaction’s start to its end are exposed. Newly deployed contracts and their code hashes are also included.

To facilitate access to this information, EIP-7906 proposes three new EVM opcodes (low-level instructions):

1. TXTRACE: This opcode allows for the enumeration of all net state changes and emitted events, providing a comprehensive audit trail of the transaction’s effects.
2. TXDIFF: This opcode enables the retrieval of specific starting and final values for particular addresses and storage slots, allowing targeted checks on critical state variables.
3. EVENTDATACOPY: This opcode allows the data of an emitted event to be copied into memory, enabling assertions to verify event content.

Crucially, these new opcodes are restricted to operate only within the POST_TX frame. This frame executes as a staticcall, meaning it cannot modify the blockchain state itself. This read-only nature is vital for security, as it prevents the assertion logic from inadvertently introducing new vulnerabilities or side effects. If the assertion rule 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 mechanism is critical for preventing denial-of-service attacks, where malicious actors might intentionally submit failing transactions to burden block builders without incurring costs.

EIP-7906 has advanced to "Considered for Inclusion," signifying its importance and potential, but is not yet confirmed for a specific network upgrade. Its integration would mark a significant step towards a more secure and predictable Ethereum.

The Crucial Role of Enforcement and Adoption

While EIP-7906 provides the technical capability for transaction assertions, its effectiveness hinges on widespread adoption and, critically, on the requirement for assertions to be included. EIP-7906, in its current form, does not mandate the inclusion of an assertion; transaction builders can opt to omit it.

This places a significant responsibility on various ecosystem participants:

• Wallets: For a user’s own transactions, the wallet interface must ensure that every frame transaction it constructs includes the necessary and appropriate assertion. This rule could be generated dynamically based on a simulation the wallet performs or derived from a standing security policy configured by the user (e.g., "never approve more than X amount," "always receive at least Y tokens"). Wallets will become the primary interface for users to define their security parameters.
• Protocols: Smart contract protocols offering protected functions would need to verify that incoming calls originate from a frame transaction containing the exact required assertion. They would need to reject ordinary transactions or frame transactions with missing or incorrect assertions. This would necessitate a coordinated upgrade path for protocols and their integrations. A significant challenge here is for already deployed, immutable contracts, which cannot be retrofitted to add this check. This highlights a potential bifurcation in the ecosystem, with newer or upgradeable contracts being able to leverage assertions, while older ones remain exposed.

The success of native transaction assertions will therefore depend not just on the technical implementation but also on strong community consensus, wallet developer support, and strategic protocol upgrades.

Broader Implications and Future Use Cases

Beyond directly preventing hacks and mitigating user losses, native transaction assertions open up a spectrum of innovative use cases that can enhance the utility and trustworthiness of the Ethereum platform:

• Strengthening Delegation: When users delegate permissions to an agent (e.g., a smart contract or another wallet) to act on their behalf, assertions can provide granular control over transaction outcomes. While existing mechanisms can limit what an agent can do (which contracts it calls, how much it spends, duration of permissions), assertions add constraints on what its actions produce. This means users can ensure that, for instance, an automated trading agent always achieves a minimum profit margin or that specific token balances are never reduced beyond a certain threshold, irrespective of the agent’s chosen strategy.
• Protocol-Defined Safety Checks: Protocols could embed their own universally required safety checks into frame transactions. For instance, a lending protocol could mandate an assertion that ensures a user’s health factor always remains above a certain level after a collateral adjustment, irrespective of the specific transaction path taken. This standardizes security for all users interacting with the protocol via frame transactions.
• Enhanced Solver Execution: In complex DeFi mechanisms like solver-based decentralized exchanges (e.g., CoW Swap), where solvers determine the optimal execution route for an order, assertions could allow the protocol to specify the required outcome while giving the solver freedom to choose the most efficient path. This would guarantee user intent (e.g., "receive at least X tokens") without restricting the solver’s innovation. It’s important to note, however, that these guarantees would typically apply within a single transaction on a single network, not across multiple chains.
• Workflow Integrity: Assertions could be used to ensure that multi-step workflows reach their intended final state. For example, after a complex DeFi interaction, an assertion could verify that unused tokens are returned to the user, any temporary token approvals are revoked, and all intermediate state changes are cleaned up as expected. This guarantees a clean and secure exit from complex interactions.

These potential applications underscore how native transaction assertions could fundamentally reshape user interactions, smart contract design, and the overall security posture of decentralized applications, moving towards a more proactive and outcome-oriented security model.

A Call to Action for the Ecosystem

The Ethereum Foundation’s Trillion Dollar Security initiative is a collaborative endeavor. The design of native transaction assertions is still evolving, and community input is paramount. The Foundation is actively seeking engagement from wallet developers, protocol teams, security researchers, and other stakeholders who would utilize these features. Their experiences and use cases are crucial for shaping the research and ensuring the final design is practical, robust, and widely adopted.

Interested parties are encouraged to reach out to [email protected] to explore specific use cases and contribute to the ongoing research. Additionally, active participation in the EIP-7906 discussion thread on ethereum-magicians.org is welcomed, providing a public forum for technical feedback and design refinement. Further details on risk controls and priority work within the broader initiative can be found at trilliondollarsecurity.org.

In conclusion, native transaction assertions, alongside Clear Signing, represent a critical evolutionary step for Ethereum security. By empowering users and protocols with on-chain, programmatic control over transaction outcomes, the Ethereum Foundation aims to significantly reduce the attack surface for malicious exploits, enhance user trust, and solidify Ethereum’s position as a secure and reliable platform for the global digital economy. This initiative is not merely about patching vulnerabilities but about building a more resilient and predictable foundation for the future of decentralized finance and beyond.