Ethereum Foundation’s Trillion Dollar Security Initiative Targets Transaction Uncertainty with Native Assertions

The Ethereum Foundation’s 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 tandem with the previously announced Clear Signing standard. This significant security upgrade aims to fundamentally alter how users interact with the Ethereum blockchain, providing an unprecedented layer of protection against sophisticated attacks and unintended outcomes that have historically led to substantial financial losses.

Understanding the Core Problem: The Ethereum Transaction Paradox

At its heart, the challenge stems from a fundamental characteristic of how Ethereum transactions operate. When a user signs a transaction, they are authorizing a specific set of instructions (calldata) to be executed by a smart contract. However, the Ethereum Virtual Machine (EVM) executes these instructions precisely as given, without inherent mechanisms to verify if the result of that execution aligns with the user’s true intent or economic goals. A valid signature merely commits to the request, but the ultimate outcome is dynamically determined by the contract’s code and the prevailing blockchain state at the moment of execution. This inherent disconnect creates two primary vectors for potential financial harm: "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 approving one action, but the signed transaction, due to malicious intervention or a compromised interface, actually authorizes something entirely different and harmful. This deception exploits the opacity of raw transaction data, especially when users are presented with simplified, human-readable summaries that can be manipulated.

Several high-profile incidents underscore this vulnerability:

• The Bybit Incident (May 2025 – inferred from article link): In this scenario, users of a Safe (formerly Gnosis Safe) wallet, often utilized for multi-signature security, were reportedly tricked into authorizing a transaction that replaced the Safe’s underlying implementation contract. While the frontend might have displayed a routine update or interaction, the actual signed payload facilitated a critical change in the contract’s logic, potentially handing control to an attacker. The "Trillion Dollar Security initiative" likely refers to the immense value secured by such contracts, making these attacks particularly devastating.
• The BadgerDAO Attack (December 2021): This incident saw attackers inject malicious code into the BadgerDAO frontend, causing users to unknowingly grant the attacker broad permissions to spend their deposited tokens. Users interacting with the seemingly legitimate interface were presented with signing requests that, once approved, allowed the attacker to drain millions of dollars in cryptocurrency. The attack, which resulted in losses exceeding $120 million, highlighted the severe risks associated with compromised user interfaces and the lack of robust on-chain validation of user intent.

In both these cases, a trusted, independent rule applied at the point of execution could have prevented the damage. For the Bybit incident, such a rule might have mandated that the approved Safe implementation contract remain unchanged. For BadgerDAO users, a rule could have restricted new token approvals exclusively to known and published Badger contracts, flagging any deviation as malicious.

Outcome Mismatch: The Unforeseen Consequences of a Valid Request

Outcome mismatch describes situations where the user signs the exact transaction they intended, but its execution, influenced by dynamic blockchain conditions or insufficient safeguards, still produces an undesirable or economically devastating result. This often involves unforeseen market shifts, liquidity issues, or complex interactions that aren’t fully captured by a simple "confirm" button.

A stark illustration of this is the Aave and CoW collateral swap (May 2026 – inferred from article link): A user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was critically thin for a trade of that magnitude. Despite an interface warning about a "99.9 percent price impact" and requiring explicit confirmation of potential total loss, the user proceeded. Due to CoWSwap’s gas ceiling limitations, more complex, potentially better-priced quotes were rejected during verification, leaving only a single, highly unfavorable quote for roughly 329 aEthAAVE. The result: tokens worth approximately $36,000 were received for a $50.4 million trade, representing a near-total loss.

Here, the user’s intent to swap was clear, but the outcome was catastrophically misaligned with their economic goal. An assertion in this scenario could have enforced a minimum acceptable output amount, calculated independently of the specific quote presented by the interface, ensuring the transaction would revert if the received value fell below a predefined threshold.

The Limitations of Current Security Measures

Ethereum’s ecosystem has developed various defenses against these risks, but each has inherent limitations:

• Clear Signing: This initiative aims to present transaction details in a human-readable format, making it easier for users to understand what they are signing. While a crucial step, it relies on accurate decoding by the wallet and the user’s ability to discern discrepancies. It doesn’t inherently prevent a malicious payload from being swapped in after the user’s review but before signing, nor does it protect against unfavorable outcomes from correctly signed, but economically flawed, transactions.
• Transaction Simulation: Wallets and security services often simulate a transaction’s effects using a snapshot of the current chain state. This provides a predictive view of the outcome. However, the blockchain state can change between the time of simulation and actual transaction inclusion (e.g., due to MEV or other transactions). Furthermore, as seen in the Radiant Capital incident (July 2023): malware on the user’s machine substituted a malicious payload at the point of signing, even though both the wallet interface and the simulation displayed the intended, legitimate transaction. Simulation is a foresight tool, not an enforcement mechanism.
• Contract Checks and Wallet Guards: Smart contracts can include internal logic (like Uniswap’s amountOutMinimum or Safe’s checkAfterExecution hooks) to revert transactions that violate predefined rules. These are effective for specific, anticipated conditions. However, they require developers to pre-emptively choose which state variables to check and depend on those contracts exposing the necessary functions to read their storage. Crucially, these checks cannot inspect the full set of net state changes produced by a transaction. A guard might verify a specific balance remains unchanged, but it cannot generically ask the EVM "what else changed?" This leaves a vast surface area for unnoticed, detrimental side effects. For instance, a proxy contract might not expose its implementation address through a function, preventing a guard from directly verifying its integrity.

Native Transaction Assertions: A Paradigm Shift in On-Chain Security

The Ethereum Foundation’s proposal for native transaction assertions represents a significant architectural enhancement designed to address these fundamental shortcomings. The core concept is to enable on-chain code to inspect the entire set of net state changes after a transaction’s actions have been executed.

How Assertions Work:

1. Rule Definition: An assertion is a piece of read-only logic included within the transaction itself. This rule defines specific conditions that must be met by the transaction’s outcome.
2. Outcome Comparison: After the primary actions of the transaction have run, the assertion logic is executed. It compares the starting state values with the final state values against its predefined rule.
3. Enforcement and Reversion: If the assertion rule fails (i.e., the outcome violates the specified conditions), the entire preceding transaction is reverted. This means all state changes are undone, ensuring that only transactions producing desired and validated outcomes are permanently recorded on the blockchain.

These rules can be highly granular and powerful, covering:

• Balance Changes: Requiring a minimum amount received in a swap or capping the amount spent.
• Storage Changes: Blocking new token approvals, preserving an account’s control logic (e.g., ensuring a Safe’s implementation address remains unchanged), or allowing only a specified set of modifications to a contract’s storage.
• Newly Deployed Contracts: Verifying the code hash of any newly deployed contract.
• Emitted Events: Checking for the presence or absence of specific events.

The critical distinction is that the assertion’s logic is executed on-chain, after the primary transaction but before its finalization, making it an immutable and tamper-proof arbiter of the outcome.

The Source of Truth: Why Assertions Must Be Required

For assertions to be truly effective, their source and enforceability are paramount. A compromised frontend could, in theory, simply craft a malicious assertion that permits an attack. Therefore, a useful rule must originate from an independently approved source, such as:

• User Intent: Explicitly defined by the user and signed along with the transaction’s actions, perhaps through an advanced wallet interface.
• Standing Account Policy: Pre-configured rules within a user’s smart account or wallet that apply to all transactions, akin to a firewall.
• Protocol Logic: Defined by a decentralized application’s smart contracts to enforce specific safety or economic conditions for interactions.

EIP-7906: A Concrete Path Forward

One leading proposal for implementing native transaction assertions is EIP-7906 (Transaction Assertions via State Diff Opcode). This EIP builds upon EIP-8141 (Frame Transactions), which introduces a new transaction type allowing an ordered sequence of validation and action steps. EIP-7906 extends this by adding a read-only POST_TX frame that executes at the very end of the transaction specifically to check its outcome.

Key features of EIP-7906:

• State Diff Exposure: The design exposes both net state changes (differences in native ETH balances and storage) and emitted events. Importantly, a storage slot written multiple times will appear as a single entry with its starting and final values. If a slot reverts to its original value, it does not appear in the diff, optimizing for relevant changes.
• New EVM Opcodes: Three new opcodes are proposed to access this information:
  • TXTRACE: Enumerates net state changes and events, allowing for a comprehensive audit.
  • TXDIFF: Retrieves starting and final values for specific addresses and storage slots, enabling targeted checks.
  • EVENTDATACOPY: Copies an event’s data into memory for programmatic inspection.
• Restricted Execution: These opcodes are designed to function only within the POST_TX frame, which executes as a static call. This ensures that the assertion logic itself cannot modify the blockchain state, maintaining its integrity as an independent validator.
• Reversion Mechanism: If an assertion within the POST_TX frame fails, the entire transaction’s execution body is reverted. However, the transaction still remains in the block with a failed status, and the gas payer is charged for the consumed gas. This prevents attackers from exploiting the system by submitting deliberately failing, cost-free transactions to front-run or spam the network.

Timeline and Status: EIP-8141, which provides the foundational "frame transaction" structure, is reportedly scheduled for inclusion in the upcoming Hegotác network upgrade (date not specified in original, but typically within a year or two). EIP-7906 has advanced to "Considered for Inclusion" but awaits final confirmation for a future upgrade, signifying its high priority within the Ethereum development roadmap.

The Mandate for Adoption: Ensuring Effectiveness

While EIP-7906 provides the technical capability, its effectiveness hinges on widespread adoption and enforcement. The EIP itself does not require transactions to include an assertion. Therefore:

• Wallet Responsibility: Wallets will play a critical role. They must ensure that every frame transaction they construct includes the necessary assertions, drawing rules from user preferences, simulations, or standing security policies.
• Protocol Integration: Decentralized protocols will need to verify that incoming calls originate from frame transactions containing the exact required assertions. They must reject standard transactions or frame transactions with missing or incorrect assertions. This presents a challenge for already deployed, immutable contracts, which cannot easily be upgraded to incorporate this check. New deployments or upgradeable contracts would be able to leverage this feature more readily.

Broader Implications and Future Use Cases

Beyond immediate user security, native transaction assertions hold transformative potential for the entire Ethereum ecosystem:

• Enhanced Delegation: For users delegating control to agents (e.g., automated trading bots, treasury management services), assertions can provide outcome-specific constraints. Instead of just limiting what an agent can do (which contracts to interact with, spending caps, duration of permissions), assertions can dictate what the actions must produce, adding an unparalleled layer of safety and trust to delegated operations.
• Protocol-Defined Safety: Protocols could define universal safety checks that apply to all interactions via frame transactions. For instance, a lending protocol might assert that a borrow operation always leaves a user’s health factor above a certain threshold, regardless of the specific parameters of the borrow.
• Flexible Solver Execution: In complex transaction aggregation models (like those used by CoW Swap), protocols could specify the required outcome of a transaction (e.g., minimum token output) while allowing solvers flexibility in choosing the optimal execution route. This guarantees user intent while maximizing efficiency. It is important to note this guarantee applies within a single transaction on one network and wouldn’t inherently cover multi-chain routes.
• Comprehensive Workflow Validation: Assertions could verify that multi-step workflows reach their intended final state, ensuring, for example, that any unused tokens are returned to the user, and all temporary token approvals are revoked. This drastically reduces the surface area for residual vulnerabilities after complex interactions.
• Increased User Trust and DeFi Adoption: By mitigating risks associated with blind signing and unexpected outcomes, assertions can significantly boost user confidence in decentralized applications, potentially accelerating mainstream adoption of DeFi and Web3 technologies.

Shaping the Future of Ethereum Security

The development of native transaction assertions is an active and collaborative effort within the Ethereum Foundation’s Trillion Dollar Security initiative. This underscores the community’s commitment to building a more secure and predictable blockchain environment. The Foundation is actively seeking input from wallet and protocol development teams to refine the design, explore diverse use cases, and ensure the resulting solution is robust and widely applicable. Stakeholders are encouraged to contribute to the research by contacting [email protected] or joining the ongoing EIP-7906 discussion thread on Ethereum Magicians.

As Ethereum continues to mature and secure an ever-increasing amount of global value, innovations like native transaction assertions are not merely enhancements but essential evolutions, safeguarding users and protocols against the sophisticated threats of the digital frontier.