Ethereum’s Trillion Dollar Security Initiative Proposes Native Transaction Assertions to Combat Blind Signing and Transaction Uncertainty.

The Ethereum Foundation’s ambitious "Trillion Dollar Security initiative," launched in May 2025, 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. This groundbreaking proposal aims to work in tandem with existing efforts like Clear Signing, enhancing the robustness and trustworthiness of on-chain interactions across the vast Ethereum ecosystem. The initiative seeks to introduce a fundamental shift in how users interact with decentralized applications (dApps), moving beyond merely signing a request to actively asserting the desired state changes.

This comprehensive approach addresses a long-standing vulnerability within Ethereum’s transaction model, where a valid signature does not always guarantee the user’s intended result. The core challenge lies in the execution environment of the Ethereum Virtual Machine (EVM), which processes precisely what is authorized by a signature, irrespective of whether the final state aligns with the user’s expectations. This discrepancy has led to significant financial losses for users, either due to signing requests different from what they believed they were approving (intent mismatch) or because an intended request still yielded an undesirable outcome due to unforeseen market conditions or malicious front-end manipulations (outcome mismatch).

The Peril of Intent and Outcome Mismatch: Lessons from Recent Exploits

The history of decentralized finance (DeFi) is unfortunately punctuated by incidents highlighting the dangers of intent and outcome mismatches. These cases underscore the urgent need for a more robust security paradigm, one that empowers users with greater control over the finality of their transactions.

One prominent example of an intent mismatch occurred during the Bybit incident (details emerged around late 2023/early 2024), where compromised front-end infrastructure led users to sign transactions that, unbeknownst to them, authorized critical changes to a Safe’s implementation contract. Users believed they were executing routine operations, but their signatures unwittingly enabled an attacker to replace the core logic of a multi-signature wallet. Similarly, the BadgerDAO attack in December 2021 saw users granting attackers permissions to spend their tokens, again facilitated by a compromised front-end injecting malicious signing requests. In both scenarios, the cryptographic signature was valid, yet the underlying intent of the user was fundamentally subverted. The sheer volume of assets managed by these platforms — hundreds of millions, if not billions, of dollars — amplifies the severity of such vulnerabilities, leading to substantial reputational and financial damage.

An outcome mismatch illustrates a different facet of this problem. In a notable incident involving Aave and CoW Protocol collateral swaps (reported around mid-2023), a user initiated a swap of approximately $50.4 million worth of aEthUSDT for aEthAAVE. Despite the user’s clear intent to execute this trade, the underlying liquidity for aEthAAVE was insufficient for such a large transaction. Complicating matters, CoW Protocol’s gas ceiling mechanisms rejected more complex, potentially safer quotes during verification, leaving only one highly unfavorable option. The user interface did display a stark 99.9% price impact warning and required explicit confirmation that the entire value could be lost. Despite these warnings, the user proceeded, ultimately receiving a mere $36,000 worth of tokens for their multi-million dollar asset. Here, the signed request was precisely what was shown, but the final outcome drastically diverged from any reasonable economic expectation, primarily due to market dynamics and protocol limitations.

In all these cases, a crucial element was missing: a trusted, on-chain mechanism to define and enforce rules over the resulting state changes, independently of the transaction builder or even the dApp interface. For the Bybit incident, an ideal rule would have mandated that the approved Safe implementation remain unaltered. A BadgerDAO user could have set a rule allowing new token approvals only for a pre-approved list of Badger contracts. The Aave user could have specified a minimum acceptable output amount, enforced independently of the front-end’s quote. The current Ethereum architecture, however, lacks a general, native mechanism for smart contracts to inspect the full scope of net state changes and events generated by a transaction after its execution.

The Limits of a Signature: What It Doesn’t Control

The fundamental design of Ethereum means that a user’s signature commits only to the request: the target contract, the value transferred, and the calldata (the instructions for the contract). The EVM then executes this call against the specific contract code and state present at the time of execution. This distinction is critical because the code or state can change between the moment a user signs a transaction and when it is finally included in a block. Consequently, the resulting net balance and storage changes, along with any emitted events, can deviate significantly from what the user anticipated.

Consider the dynamic interplay: a signed request, the contract’s code, and the current blockchain state all combine to determine the final outcome. The target contract might be a proxy whose underlying implementation contract is updated before the transaction executes, meaning the code that ultimately runs is different from what the user initially inspected. Furthermore, transaction ordering can profoundly alter the state encountered by a user’s call. A malicious "sandwich attack," for instance, can manipulate a decentralized exchange (DEX) pool’s price immediately before and after a user’s swap, resulting in significant slippage, even though the user’s signed transaction remains unchanged.

Current Security Measures and Their Insufficiencies

Ethereum’s ecosystem has evolved several defenses against these risks, but each possesses inherent limitations that native transaction assertions seek to overcome.

Clear Signing, while a significant improvement, focuses on translating raw calldata into human-readable actions. It relies on accurate decoding mechanisms and the user’s ability to discern discrepancies between the displayed action and their actual intent. However, Clear Signing primarily addresses the "intent mismatch" by clarifying what is being signed, not what the outcome will be. It cannot prevent an outcome mismatch if the signed action, though clearly understood, leads to an unfavorable result due to external factors like liquidity or price volatility.

Transaction simulation is another widely adopted defense. Wallets and dApps often simulate a transaction’s effects against a chosen chain state before the user signs. This provides a predictive snapshot of the potential outcome. However, this simulation is merely a prediction. The actual chain state can change dramatically between the simulation and the transaction’s inclusion in a block, especially in volatile market conditions or under malicious MEV (Maximal Extractable Value) attacks. Moreover, as demonstrated by the Radiant Capital incident (January 2024), malware on a user’s machine can substitute a malicious payload at the point of signing, even if both the wallet interface and a prior simulation accurately showed the intended transaction. In this scenario, the simulation becomes irrelevant as the signed transaction is fundamentally different.

Contract-level checks and wallet guards offer a more on-chain approach. Protocols like Uniswap implement amountOutMinimum parameters, reverting a swap if the output falls below a user-defined threshold. Safe (formerly Gnosis Safe) uses a checkAfterExecution hook, allowing a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined rules (e.g., specific owner changes or configuration modifications). While valuable, these defenses require foreknowledge of which state variables to check. They also depend on target contracts exposing relevant functions (e.g., balanceOf for token balances). A proxy contract, for instance, might not expose its implementation address directly, preventing a guard from reading the crucial implementation slot without a dedicated interface. Crucially, these existing checks cannot inspect the full set of net state changes. A guard can verify if a specific balance remains unchanged, but it lacks the EVM’s native capability to query "what else changed?" This blindness leaves other, unforeseen effects unnoticed and unmitigated.

The Power of Native Transaction Assertions

Native transaction assertions represent a paradigm shift by empowering on-chain code to inspect the entire set of net state changes after a transaction’s primary actions have been executed. An assertion functions as a read-only logic gate: it compares the starting and final values of state elements against a user- or protocol-defined rule. If this rule fails, the entire transaction is reverted, effectively preventing undesirable outcomes.

The assertion rule itself is included within the transaction and cryptographically signed alongside its primary actions. This ensures that the user’s intent regarding the outcome is immutably linked to the transaction. These rules can be incredibly flexible and comprehensive, covering:

• Net changes to native ETH balances, ERC-20 token balances, and arbitrary storage slots.
• Newly deployed contracts and their code hashes.
• Emitted events.

Practically, this means users or protocols could define rules such as:

• "Require a minimum amount of tokens received from a swap."
• "Cap spending to a specific amount for a particular token."
• "Block new token approvals for unauthorized contracts."
• "Preserve an account’s control logic (e.g., ensuring a Safe’s implementation contract remains unchanged)."
• "Allow only a specified, narrow set of state changes."

The efficacy of an assertion hinges not just on the check itself, but on the source of the rule. A compromised front-end could, for instance, maliciously inject an assertion that permits an attack. Therefore, a truly useful rule must originate from independently approved user intent, a robust standing account policy (like those implemented by smart contract wallets), or immutable protocol logic that cannot be tampered with by a compromised component. This independence is key to safeguarding against sophisticated social engineering and front-end attacks.

EIP-7906: A Concrete Step Towards Enhanced Security

One leading proposal for implementing native transaction assertions is EIP-7906 (Transaction Assertions via State Diff Opcode). This Ethereum Improvement Proposal builds upon the concept of "frame transactions" defined in EIP-8141, which are structured transactions containing an ordered sequence of validation and action steps. EIP-7906 extends this by adding a crucial, 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. EIP-8141 is currently scheduled for inclusion in the upcoming HegotÁ network upgrade, signifying a foundational step, while EIP-7906 has advanced to "Considered for Inclusion," indicating strong developer interest but awaiting final confirmation for an upgrade.

The design of EIP-7906 is meticulously crafted to expose comprehensive information about state changes and events. State changes are reported as net differences:

• Changes in native ETH balances.
• Differences in storage slot values (only if the final value differs from the initial; if a slot is written multiple times but reverts to its original value, it does not appear).
• Details of newly deployed contracts, including their code hashes.

To enable on-chain code to access this critical information, EIP-7906 introduces three new EVM opcodes (Ethereum Virtual Machine instructions):

1. TXTRACE: This opcode allows enumeration of all net state changes and emitted events, providing a comprehensive overview.
2. TXDIFF: This opcode enables retrieval of starting and final values for specific addresses and storage slots, allowing targeted checks.
3. EVENTDATACOPY: This opcode facilitates copying an event’s data into memory, enabling assertion logic to verify event emissions.

Crucially, these opcodes are strictly restricted to operate only within the POST_TX frame. This frame executes at the very end of the transaction as a static call, meaning it can inspect state but cannot modify it. This read-only nature is vital for security, preventing the assertion logic itself from introducing new vulnerabilities. If any rule within the POST_TX frame is violated, 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 charged for the gas consumed up to that point. This mechanism is critical for preventing denial-of-service attacks, where malicious actors might otherwise attempt to flood the network with deliberately failing transactions without incurring cost.

The Imperative of Required Assertions and Broader Implications

While EIP-7906 provides the technical foundation, its effectiveness hinges on widespread adoption and enforcement. The current design does not require transactions to include an assertion. This means that for a user’s own transactions, the wallet interface becomes the crucial gatekeeper, responsible for ensuring that every frame transaction it constructs includes the necessary assertion. This assertion could be derived from a real-time simulation performed by the wallet or from a standing security policy predefined by the user.

For protocols, integrating transaction assertions requires careful consideration. A protected function within a protocol would need to verify that an incoming call originates from a frame transaction containing the exact required assertion. It would have to reject standard transactions or frame transactions with missing or incorrect assertions. This implies a significant shift in how callers and integrations interact with such protocols. A notable challenge arises for already deployed, immutable smart contracts, which cannot be retrofitted with this new assertion-checking logic. This highlights the need for a gradual rollout and potentially new deployment patterns for contracts that wish to leverage this enhanced security.

Beyond immediate security benefits for individual users and protocols, native transaction assertions unlock a spectrum of advanced use cases:

• Strengthening Delegation: When users delegate authority to agents (e.g., account abstraction modules, transaction relayers), assertions can provide granular control over transaction outcomes, not just inputs. This allows users to constrain not only what an agent may do but also what its actions must produce, adding an extra layer of trust and safety.
• Enhanced Protocol Safety: Protocols can define universal safety checks that apply to all interactions via frame transactions. For instance, a lending protocol could assert that a loan always maintains a minimum collateralization ratio after any operation.
• Flexible Solver Execution: In complex transaction flows involving solvers (e.g., CoW Protocol), assertions could allow the protocol to specify the required outcome while giving the solver flexibility to choose the optimal execution route. This guarantees the user’s desired end-state even as the intermediate steps are optimized by a third party.
• Comprehensive Workflow Verification: Assertions could be used to verify that multi-step workflows reach their intended final state, ensuring, for example, that unused tokens are returned to the user, or temporary token approvals are revoked post-execution. This moves beyond checking individual steps to verifying the integrity of an entire sequence of operations.

Shaping the Future of Ethereum Security

The development of native transaction assertions is a cornerstone of the Ethereum Foundation’s "Trillion Dollar Security initiative," which aims to safeguard the immense value locked within the Ethereum ecosystem – currently hundreds of billions of dollars in Total Value Locked (TVL) across DeFi, NFTs, and other applications, with projections reaching trillions. The initiative recognizes that as Ethereum scales and becomes increasingly central to global finance and digital ownership, the security primitives must evolve to meet the challenges posed by increasingly sophisticated attacks.

This is an ongoing research and development effort, and the Ethereum Foundation is actively seeking input from the broader community, especially wallet developers, dApp teams, and protocol architects who would be primary beneficiaries and implementers of these features. Engaging with these stakeholders is crucial for refining the design, exploring diverse use cases, and ensuring that the proposed solutions are practical, efficient, and widely adoptable.

The community is encouraged to contribute to the discussion on EIP-7906 via the Ethereum Magicians forum or to reach out directly to the Trillion Dollar Security initiative team at [email protected]. Collaborative efforts are essential to navigate the complexities of EVM design, opcode implementation, and the seamless integration of these advanced security features into the user experience. By proactively addressing blind signing and transaction uncertainty, Ethereum aims to cement its position as the most secure and trustworthy platform for decentralized applications, fostering unprecedented levels of user confidence and paving the way for a truly decentralized and secure digital economy. Further information on the initiative’s broader risk controls and priority work is available at trilliondollarsecurity.org.