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

This significant development, announced as part of the Ethereum Foundation’s ambitious "Trillion Dollar Security initiative" launched in May 2025, aims to fundamentally bolster the security and trustworthiness of transactions on the world’s second-largest blockchain. The initiative, named for its aspiration to secure the vast sums of value flowing through and stored on the Ethereum network, addresses critical vulnerabilities that have led to substantial user losses in the past. At its core, the problem stems from the inherent nature of how Ethereum transactions are currently processed: a signature commits to a request, but its actual outcome can be unpredictable due to evolving network state and contract code, often differing significantly from a user’s initial intent. This gap between user intent and final outcome has been a persistent Achilles’ heel for both individual users and major decentralized applications (dApps).

Addressing Core Vulnerabilities: Blind Signing and Outcome Mismatches

The Ethereum Foundation’s research, undertaken as part of the Trillion Dollar Security initiative, has pinpointed two primary vectors through which signed transactions can lead to undesired outcomes: blind signing and outcome mismatch. Blind signing occurs when users approve a transaction without fully understanding its implications, often due to technical complexity, obfuscated interfaces, or malicious front-end manipulation. Outcome mismatch, conversely, happens when a user signs a transaction they believe to be correct, but the execution context (such as fluctuating liquidity, front-running, or unexpected contract state changes) leads to a result that conflicts with their economic goals or safety policies.

Historically, these vulnerabilities have been exploited in high-profile incidents, resulting in millions of dollars in losses. For instance, the original article references the Bybit incident and the BadgerDAO attack as prime examples of intent mismatch due to compromised frontends. In the Bybit incident, which occurred prior to the launch of the Trillion Dollar Security initiative, signers were unknowingly tricked into authorizing the replacement of a Safe’s implementation contract, a critical component that dictates a smart contract’s logic. Similarly, in the BadgerDAO attack, users inadvertently granted attackers permission to spend their tokens, a devastating blow that cost the protocol an estimated $120 million in December 2021. These events underscored the urgent need for robust mechanisms that can verify a transaction’s true impact before or during its execution, independent of the user’s initial interaction with a potentially compromised interface.

An outcome mismatch was starkly illustrated in the Aave and CoW collateral swap case. A user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, due to extremely thin liquidity for AAVE at that scale and CoW Swap’s gas ceiling rejecting more complex (and likely safer) quotes during verification, the transaction proceeded with a drastically unfavorable exchange rate. Despite an interface warning of a 99.9% price impact, the user signed the transaction, ultimately receiving only about $36,000 worth of aEthAAVE. This incident, while demonstrating existing warnings, highlighted the lack of an enforceable on-chain mechanism to prevent such a catastrophic outcome if the user proceeds regardless. These examples collectively emphasize that a valid signature alone does not guarantee the desired transaction result, creating significant user experience risks and hindering broader adoption of decentralized finance (DeFi).

The Limitations of Existing Security Measures

While the Ethereum ecosystem has developed various defense mechanisms over time, they often fall short in providing comprehensive protection against these sophisticated attacks and unforeseen outcomes.

• Clear Signing: This method aims to present transaction details in a human-readable format, helping users understand what they are signing. However, its effectiveness relies heavily on accurate decoding and the user’s ability to recognize discrepancies. It can be circumvented by highly sophisticated malware that alters the payload after the user’s review but before signing, as demonstrated in the Radiant Capital case where malicious software on signers’ machines substituted a payload despite the wallet interface showing the intended transaction. Clear Signing also doesn’t protect against outcome mismatches where the signed action is technically correct but leads to an economically unfavorable result due to external factors.

• Transaction Simulation: Wallets and dApps frequently employ simulations to predict the effects of a transaction using a snapshot of the current chain state. While valuable, simulations are inherently predictive and can be inaccurate if the chain state changes significantly between the time of simulation and actual inclusion in a block. This is particularly relevant in volatile markets or under conditions of high network congestion where transaction ordering (and thus state) can be manipulated (e.g., sandwich attacks). Furthermore, a simulation cannot detect a malicious payload substitution that occurs after the simulation but before signing, as seen with Radiant Capital.

• Contract Checks and Wallet Guards: Smart contracts often incorporate internal checks (e.g., Uniswap’s amountOutMinimum for swaps) or leverage wallet guards (like Safe’s checkAfterExecution hook) to enforce rules. These mechanisms are crucial for preventing certain types of exploits. However, they require developers to anticipate and hardcode every possible undesirable outcome. They also face limitations in their ability to inspect the full set of net state changes produced by a transaction. A guard might verify that a specific balance remains unchanged, but it cannot easily query the Ethereum Virtual Machine (EVM) about all other changes that occurred. Reading another contract’s storage often depends on exposed functions, meaning critical information (like a proxy’s implementation address) might be inaccessible if not explicitly provided. This leaves a significant blind spot where unintended side effects or subtle manipulations can go unnoticed.

These limitations highlight a critical gap: Ethereum currently lacks a general, native mechanism for on-chain code to comprehensively inspect and validate the entire resulting state—including all net state changes and events—after a transaction’s execution.

Native Transaction Assertions: A Paradigm Shift in Security

To bridge this critical security gap, the Ethereum Foundation is championing the development of native transaction assertions. This innovative approach would empower on-chain code to inspect the full set of net state changes after a transaction’s actions have run, but before its finalization. An assertion would comprise read-only logic that compares the starting and final values of accounts, storage, and events against a predefined rule. If this rule is violated, the entire transaction’s actions would be reverted, effectively preventing the undesirable outcome from being recorded on the blockchain.

Crucially, the assertion itself would be included in the transaction and signed alongside its intended actions. This ensures that the user’s explicit intent, as defined by the assertion, is enforced on-chain. The scope of these assertions is broad, capable of covering:

• Minimum amount received in a swap.
• Caps on spending or token approvals.
• Blocking new token approvals entirely.
• Preserving an account’s control logic (e.g., ensuring a Safe’s implementation contract remains unchanged).
• Allowing only a specified, whitelisted set of changes.

The power of this mechanism lies in its independence. A useful rule must originate from an independently approved user intent, a standing account policy, or protocol logic that cannot be manipulated by a compromised front-end or malicious actor. This creates a powerful, on-chain "safety net" that functions as a last line of defense, reverting any transaction that deviates from the user’s or protocol’s predefined safety parameters. The diagrammatic representation illustrates this clearly: assertions act as a post-execution validator, nullifying the transaction if the outcome does not meet the asserted conditions.

EIP-7906: A Concrete Proposal for Implementation

One leading proposal for implementing native transaction assertions is EIP-7906 (Transaction Assertions via State Diff Opcode). This Ethereum Improvement Proposal builds upon EIP-8141, which introduces "frame transactions." Frame transactions are a new transaction type that allows for an ordered sequence of validation and action steps. EIP-7906 extends this by adding a read-only POST_TX frame at the very end of the transaction’s execution. This POST_TX frame is specifically designed to inspect the transaction’s outcome.

EIP-8141 is currently scheduled for inclusion in the upcoming Hegot’a upgrade, marking a significant step towards enabling such advanced transaction types. EIP-7906, having advanced to "Considered for Inclusion," is a strong candidate for future upgrades, though its final confirmation is pending.

The design of EIP-7906 is comprehensive, exposing both state changes and events. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their code hashes. Importantly, if a storage slot is written multiple times but ultimately reverts to its original value, it will not appear as a change, streamlining the information presented for assertion.

To facilitate access to this crucial information, EIP-7906 proposes three new EVM opcodes:

1. TXTRACE: This opcode would allow enumeration of net state changes and emitted events, providing a comprehensive overview of the transaction’s impact.
2. TXDIFF: This opcode would enable retrieval of starting and final values for specific addresses and storage slots, allowing for targeted checks.
3. EVENTDATACOPY: This opcode would copy an event’s data into memory, making it accessible for assertion logic.

These opcodes are designed to function exclusively within a POST_TX frame, which executes as a static call. This crucial restriction ensures that the assertion logic itself cannot modify the state, maintaining its integrity as a purely evaluative mechanism. If an assertion within the POST_TX frame fails, the entire execution body of the transaction is reverted. However, the transaction itself still remains in the block with a failed status, and the gas payer is charged for the gas consumed. This design choice is vital for preventing denial-of-service attacks, where malicious actors might intentionally craft failing transactions to burden block builders without incurring any cost.

The Crucial Role of Requirement and Adoption

A key aspect of native transaction assertions is their mandatory adoption. EIP-7906, in its current form, does not inherently require transactions to include an assertion. This means that if an attacker or a compromised frontend constructs a transaction, they could simply omit the assertion, rendering the protective mechanism ineffective. Therefore, the onus of requiring assertions falls on other layers of the ecosystem:

• Wallets: For a user’s own transactions, the wallet must ensure that every frame transaction it constructs includes the necessary assertion. This assertion could be generated dynamically based on a simulation the wallet performs, or it could be derived from a standing security policy predefined by the user or the wallet provider.
• Protocols: Decentralized protocols (dApps) can play a critical role by verifying that calls to their protected functions originate from frame transactions containing the exact required assertion. Such protocols would need to reject ordinary transactions or frame transactions with missing or incorrect assertions. This would compel users and integrating applications to utilize compatible frame transactions with appropriate assertions, thereby enhancing the protocol’s overall security posture.

A notable challenge for protocol-level enforcement is that already deployed, immutable smart contracts cannot easily be updated to incorporate this check. This implies that new contract deployments or upgrades would be necessary to fully leverage the power of native transaction assertions at the protocol layer.

Broader Implications and Future Use Cases

Beyond directly mitigating blind signing and outcome mismatches, native transaction assertions hold immense potential for a wide array of use cases, significantly enhancing the utility and security of the Ethereum platform:

• Strengthening Delegation: When users delegate authority to an agent (e.g., a smart contract wallet or a third-party service) to act on their behalf, assertions can provide granular control over the outcomes of those delegated actions. While existing mechanisms can limit what an agent can do (which contracts it uses, spending limits, permission durations), assertions can add rules for what its actions produce. This creates a more robust and trustworthy delegation framework, crucial for enterprise adoption and complex DeFi strategies.

• Protocol-Defined Safety Checks: Protocols could define their own universal safety rules that must be met by any transaction interacting with them via a frame transaction. For instance, a decentralized exchange (DEX) could mandate a minimum output amount for all swaps, regardless of the user interface or specific swap route. In solver-based execution models (like CoW Swap), a protocol could specify the required final outcome, granting solvers flexibility in choosing the optimal route while ensuring the user’s safety parameters are strictly adhered to. This guarantee, however, would apply only within a single transaction on a single network, necessitating further innovation for multi-chain operations.

• Workflow Verification: Assertions could verify that complex multi-step workflows reach their intended final state. This could include ensuring that unused tokens are returned to the user, that temporary token approvals are revoked after a specific operation, or that a contract’s state transitions correctly through a series of operations. This provides an unprecedented level of on-chain verification for complex dApp interactions.

• Enhanced Auditability and Compliance: By providing a clear, on-chain record of intended outcomes and their enforcement, transaction assertions could significantly improve the auditability of smart contract interactions. This could be beneficial for compliance frameworks, allowing for verifiable assurances that certain financial or operational rules are always upheld.

Shaping the Future of Ethereum Security

The Trillion Dollar Security initiative, with its focus on native transaction assertions and Clear Signing, represents a proactive and essential step towards building a more secure and user-friendly Ethereum. As the value secured by the network continues to grow, so does the imperative to eliminate vulnerabilities that undermine user trust and financial safety. The Ethereum Foundation recognizes that the design of such foundational security mechanisms requires broad collaboration across the ecosystem. Wallet developers, protocol teams, and security researchers are encouraged to engage with the initiative by reaching out to [email protected] to explore use cases, contribute to the research, and help shape the final design. Active participation in discussions, such as the EIP-7906 thread on Ethereum Magicians, is also vital for ensuring these solutions meet the diverse needs of the community.

By empowering users and protocols with the ability to define and enforce transaction outcomes on-chain, native transaction assertions promise to transform the security landscape of Ethereum, fostering greater confidence and paving the way for wider adoption of decentralized technologies. The journey towards a truly "Trillion Dollar Secure" Ethereum is ongoing, and these advancements mark a critical milestone in that endeavor.