Ethereum Foundation Unveils Native Transaction Assertions to Combat Blind Signing and Enhance User Security

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. This advanced security mechanism is being developed in parallel with existing efforts like Clear Signing, aiming to fortify the integrity of user interactions within the vast and rapidly expanding Ethereum ecosystem. This comprehensive proposal seeks to bridge the critical gap between what a user believes they are approving and the actual on-chain result, thereby protecting digital assets from a myriad of sophisticated attack vectors.

The current post delves into the inherent vulnerabilities of Ethereum’s transaction model, where a valid signature does not always guarantee the desired transaction result. It meticulously outlines how native transaction assertions are designed to offer an unprecedented layer of protection, addressing shortcomings in today’s defensive strategies. Furthermore, the article explores the fundamental design choices underpinning these assertions, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate for implementation. This technical advancement is not merely an incremental upgrade but a foundational shift, poised to significantly enhance user confidence and the overall security posture of the Ethereum blockchain.

The Perilous Disconnect: When a Signed Transaction Goes Awry

The fundamental challenge stems from Ethereum’s operational paradigm: it executes precisely what is authorized, without inherent judgment on whether the outcome aligns with the user’s intent. A digital signature commits to a specific request, but its ultimate effect is contingent upon the smart contract code and the prevailing state of the blockchain at the moment of execution. This inherent characteristic has, unfortunately, led to significant financial losses for users who either approved an action fundamentally different from their understanding or whose intended request still yielded an undesirable result due to dynamic on-chain conditions.

These detrimental scenarios typically manifest in two primary forms:

1. Intent Mismatch: This occurs when the transaction signed by the user is not what they believed they were approving. Malicious actors frequently exploit compromised frontends or sophisticated phishing schemes to present users with a benign-looking transaction for approval, while secretly substituting it with a nefarious payload.

   • The Bybit Incident: A stark illustration of intent mismatch involved the Bybit platform. In this incident, signers for a Safe (formerly Gnosis Safe) wallet inadvertently authorized a transaction that replaced the Safe’s implementation contract. This critical change, if executed maliciously, could have granted attackers complete control over the funds managed by the Safe, despite the signers believing they were performing a routine or harmless operation. The compromise of the frontend interface was key to this deception.
   • The BadgerDAO Attack: Similarly, the BadgerDAO attack saw users unknowingly grant attackers broad permissions to spend their tokens. A compromised web interface presented a seemingly legitimate request, but the underlying transaction payload secretly included an approve call that ceded control of user tokens to the attacker. The users, unaware of the hidden malicious intent, provided valid signatures, leading to substantial asset drains.

2. Outcome Mismatch: In this scenario, the user approves the exact request presented to them, but the transaction’s limits, its interaction with current blockchain state, or external factors result in an outcome that severely conflicts with their economic objectives or established safety policies.

   • The Aave and CoW Collateral Swap: A high-profile case involved a user attempting to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. Despite the user’s explicit intent to execute this swap, the AAVE liquidity pool was critically shallow for a transaction of that magnitude. Further compounding the issue, CoW Swap’s gas ceiling mechanism rejected more complex, potentially safer quotes during its verification process, leaving only one viable, but highly unfavorable, quote for roughly 329 aEthAAVE. The interface did display a prominent 99.9% price impact warning, requiring explicit user confirmation of potential total loss. Yet, the user proceeded, ultimately receiving tokens valued at merely $36,000 – a catastrophic outcome mismatch despite clear warnings and a valid signature.

In all three instances, a crucial safeguard was absent: a trusted, on-chain rule governing the resulting state of the transaction, defined independently of the transaction builder and enforced during execution. For the Bybit incident, such a rule would have mandated that the approved Safe implementation contract remain unchanged. A BadgerDAO user could have benefited from a rule restricting new token approvals solely to published and verified Badger contracts. The Aave user, ideally, would have had a rule setting a minimum acceptable output for their swap, calculated and enforced independently of the quote presented by the interface.

The fundamental limitation across these cases is that Ethereum currently lacks a general, native mechanism for on-chain code to comprehensively inspect the full set of net state changes and events generated by a transaction. This absence creates a significant vulnerability that native transaction assertions aim to rectify.

The "Trillion Dollar Security" Imperative: Protecting a Growing Ecosystem

The Ethereum Foundation’s "Trillion Dollar Security" initiative, launched in May 2025, underscores the immense value at stake within the Ethereum ecosystem. With a Total Value Locked (TVL) in DeFi consistently fluctuating in the tens of billions and the broader market capitalization of Ethereum and its associated tokens often surpassing a trillion dollars, the economic gravity of securing this digital frontier cannot be overstated. The initiative recognizes that as Ethereum matures and integrates further into global finance and commerce, the sophistication of attacks will only increase, making robust, native security primitives absolutely essential. It’s a proactive stance to ensure that the foundational layer of this digital economy is resilient against evolving threats.

What a Signature Alone Cannot Control

A digital signature on Ethereum commits to the specific action requested by the user, encompassing 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 blockchain state present at the time the transaction runs. This state may have changed significantly between the moment the user signed the transaction and its inclusion in a block. Consequently, the resulting net balance and storage changes, along with any emitted events, can deviate drastically from initial expectations.

Consider the dynamic nature of Ethereum:

• Proxy Contract Risks: A target contract, or one it calls, might utilize an upgradeable proxy. The underlying implementation contract could be changed before the transaction executes, meaning the code that ultimately runs is different from what the user inspected at signing.
• Transaction Ordering and MEV: The order in which transactions are processed can profoundly alter the state encountered by a user’s call. For instance, a "sandwich attack" can manipulate a decentralized exchange (DEX) pool’s price by executing malicious transactions before and after a legitimate user’s swap. The user’s signed transaction remains unchanged, but the state it interacts with is manipulated, leading to unfavorable execution.

These scenarios highlight that while a signature proves authorization for a specific input, it offers no guarantee over the output in a mutable, dynamic environment.

Where Today’s Defenses Fall Short

Several existing security measures attempt to mitigate these risks, but each possesses inherent limitations that native transaction assertions aim to overcome:

1. Clear Signing: This defense mechanism focuses on clearly explaining to the user what action the calldata of a transaction requests. It relies on accurate decoding of the transaction payload and the user’s ability to recognize if the decoded action deviates from their intent. While vital for transparency, clear signing is effective only if the user correctly interprets the information and if the malicious intent isn’t cleverly disguised within seemingly legitimate parameters. It doesn’t prevent outcome mismatches where the signed action is correct but the result is undesired due to state changes.

2. Transaction Simulation: Wallets and dApps often employ simulation tools to predict a transaction’s effects using a selected chain state. This offers a preview of what might happen. However, simulation has critical weaknesses:

   • State Drift: The actual chain state can change significantly between the simulation and the transaction’s inclusion in a block, rendering the simulation inaccurate.
   • Malware Substitution: As demonstrated in the Radiant Capital incident, malware on a user’s machine can substitute a malicious payload at the exact moment of signing, even if the wallet interface and preceding simulation displayed the intended, legitimate transaction. The simulation provides a prediction, but the signed artifact can still be compromised.

3. Contract Checks and Wallet Guards: These mechanisms enforce specific rules during EVM execution.

   • Uniswap’s amountOutMinimum: Decentralized exchanges like Uniswap revert a swap if the output tokens fall below a user-defined amountOutMinimum. This is a valuable protection against severe slippage.
   • Safe’s checkAfterExecution hook: Smart contract wallets like Safe allow "guards" to inspect the account’s state after execution within the same transaction context, reverting if predefined rules (e.g., related to owner changes or configuration) are violated.

Despite their utility, these contract-level checks have limitations:

• Pre-defined State: They require choosing which specific state variables to check in advance. They cannot dynamically react to unforeseen changes across the entire state.
• Interface Dependency: To read another contract’s storage, these checks depend on the functions that contract exposes. For example, a token’s balanceOf function makes balance checks straightforward. However, a proxy contract might not expose its implementation address through a function, preventing a guard from directly reading that critical storage slot.
• Limited Scope: Crucially, existing contract checks cannot inspect the full set of net state changes produced by a transaction. A guard can verify that a particular balance remains unchanged, but it cannot query the EVM about everything else that changed. Effects not explicitly designed to be checked can, therefore, go unnoticed, leaving blind spots for sophisticated attackers.

Native Transaction Assertions: Enforcing Intent Beyond the Signature

Native transaction assertions represent a powerful new primitive that would allow on-chain code to inspect the entire set of net state changes after a transaction’s core actions have completed. An assertion functions as a read-only piece of logic that compares the initial and final values of relevant state components against a user- or protocol-defined rule. If this rule fails, the entire transaction (including its actions) is reverted.

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

• Net changes to native ETH balances.
• Changes in storage variables across any contract.
• Newly deployed contracts and their associated code hashes.
• Emitted events.

Practically, assertions could enforce a minimum amount of tokens received in a swap, cap spending limits, block new token approvals, preserve an account’s control logic (e.g., preventing a Safe implementation change), or allow only a predefined, whitelisted set of changes. The core innovation is that assertions act as a post-execution gate: the transaction runs, its effects are calculated, and then the assertion verifies if these effects align with the established rules. If not, the transaction is rolled back, protecting the user from unintended consequences.

The source of the assertion rule is as critical as the check itself. A compromised frontend, for example, could theoretically inject a malicious assertion that permits an attack. Therefore, a truly effective rule must originate from independently approved user intent, a standing account policy (perhaps set at the wallet level), or protocol logic that cannot be manipulated by a compromised component. This ensures the integrity and trustworthiness of the assertion.

EIP-7906: A Concrete Path Forward via State Diff Opcodes

One of the most promising technical approaches to realizing native transaction assertions is EIP-7906, which builds upon the concept of "frame transactions" introduced in EIP-8141.

• Frame Transactions (EIP-8141): EIP-8141 defines a new transaction type that contains an ordered sequence of validation and action steps. This structure provides a more modular and flexible way to compose complex transactions. EIP-8141 is currently scheduled for inclusion in the upcoming Hegotá network upgrade, indicating strong developer consensus on its utility.
• EIP-7906’s POST_TX Frame: EIP-7906 extends this framework by adding a specialized, read-only POST_TX (post-transaction) frame at the very end of the execution sequence. This POST_TX frame is where the assertion logic resides and is executed. Its read-only nature (static call) ensures that the assertion itself cannot modify state, only inspect it and trigger a revert if the rules are violated. EIP-7906 has advanced to "Considered for Inclusion" but awaits final confirmation for an upcoming upgrade.

Information Exposure and Access:
The design of EIP-7906 proposes exposing both net state changes and emitted events.

• State Changes: These are reported as net differences in native ETH balances and storage. Crucially, if a storage slot is written to multiple times within a transaction, it appears as a single entry reflecting its starting and final values. If a storage slot ultimately reverts to its original value, it is not reported at all, optimizing for relevance. This "net difference" approach is highly efficient and focused.
• Newly Deployed Contracts: The assertion can also inspect newly deployed contracts and their associated code hashes.

New EVM Opcodes:
To enable on-chain code to access this vital information, EIP-7906 introduces three new EVM instructions (opcodes):

• TXTRACE: This opcode enumerates the net state changes and events that occurred during the transaction’s execution. It allows the assertion logic to iterate through all modifications.
• TXDIFF: This opcode provides a targeted way to retrieve the starting and final values for specific addresses and storage slots. This is useful for checking specific known values.
• EVENTDATACOPY: This opcode allows copying an event’s data into memory, enabling detailed inspection of emitted events.

Execution Model and Gas Costs:
These new opcodes are strictly limited to execution within the POST_TX frame, which runs as a static call at the end of the transaction. This design ensures that the assertion logic is purely for verification and cannot introduce new side effects. If an assertion rule 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 still charged for the gas consumed up to the point of the revert. This critical design choice prevents malicious actors from exploiting the system by deliberately crafting failing transactions to force builders to execute them for free, thereby mitigating potential denial-of-service attacks.

The Imperative of Requirement: Making Assertions Mandatory

A key consideration for the efficacy of native transaction assertions is their mandatory adoption. EIP-7906, in its current form, does not require transactions to include an assertion. This means a malicious or careless transaction builder could simply omit the assertion, circumventing the security benefits.

For native transaction assertions to truly protect users and protocols, they must be enforced:

• Wallet Responsibility: For user-initiated transactions, the wallet interface plays a crucial role. It must ensure that every frame transaction it constructs includes the necessary assertion. This assertion could be derived from a pre-run simulation, a user-defined standing policy, or a combination of both. Wallets will become the primary enforcers of user intent.
• Protocol-Level Enforcement: Protocols seeking enhanced security for their functions would need to verify that incoming calls originate from frame transactions containing the exact required assertion. They would reject ordinary transactions or frame transactions with missing or incorrect assertions. This implies a need for protocols to upgrade or adapt their smart contracts. However, this also presents a challenge for already deployed, immutable contracts, which cannot be modified to incorporate this check. This highlights the need for careful rollout strategies and potentially new contract standards.

Broadening the Horizon: Beyond Core Security Benefits

Beyond the immediate and profound security benefits for individual users and smart contract protocols, native transaction assertions unlock a range of other innovative use cases:

1. Strengthened Delegation: When users delegate authority to an agent (e.g., a smart account or a third-party service) to act on their behalf, assertions can provide granular control. While existing methods can limit which contracts an agent uses, how much it spends, and the duration of its permissions, assertions can add crucial rules about the outcome of each delegated transaction. This allows users to constrain both the agent’s actions and the resulting state changes, creating a more secure and trustworthy delegation framework.

2. Protocol-Defined Safety Checks: Protocols can define and enforce their own universal safety rules. By requiring all callers to use frame transactions with a specific assertion, protocols can guarantee a consistent safety check for every interaction. For instance, a lending protocol could mandate an assertion that ensures a user’s health factor does not drop below a certain threshold after a series of operations.

3. Flexible Solver Execution: In complex transaction settlement mechanisms, such as those used by intent-based protocols or MEV-resistant systems, users often specify their desired outcome but allow "solvers" to find the optimal execution path. Assertions could empower the protocol to specify the required outcome precisely, while granting solvers the freedom to choose the most efficient route. The assertion would then verify that the solver’s chosen path indeed achieves the specified result, even if that path involves multiple internal calls or state changes across different contracts. This provides a strong guarantee, though it would apply only within a single transaction on a single network.

4. Workflow Verification: Assertions could ensure that multi-step workflows reach their intended final state. For example, after a complex DeFi operation, an assertion could verify that any unused tokens are returned to the user, and any temporary token approvals granted during the process are revoked, minimizing attack surface.

Shaping the Future: Community Engagement and Outlook

The design and implementation of native transaction assertions are dynamic processes, central to the Ethereum Foundation’s Trillion Dollar Security initiative. This represents a significant engineering and community effort, demanding careful consideration of trade-offs between security, efficiency, and developer experience.

The Ethereum Foundation actively seeks input and collaboration from the broader ecosystem. Wallet providers, who will be instrumental in integrating and promoting these assertions, and protocol teams, who will benefit immensely from enhanced on-chain safety, are particularly encouraged to participate. Their insights into real-world use cases, potential challenges, and integration strategies are vital for shaping a robust and widely adopted solution.

Developers, researchers, and interested community members are invited to engage directly with the ongoing research and design efforts. Participation in discussions, particularly on the EIP-7906 discussion thread on Ethereum Magicians, is crucial for refining the technical specifications and ensuring that the final design meets the diverse needs of the ecosystem. The initiative’s progress and priorities are regularly updated on trilliondollarsecurity.org, providing a central resource for those looking to contribute to a more secure Ethereum.

The journey towards native transaction assertions signifies Ethereum’s unwavering commitment to user protection and its evolution into an even more secure and resilient platform. By addressing the fundamental disconnect between user intent and transaction outcome, this initiative promises to unlock new levels of trust, fostering broader adoption and innovation within the decentralized web.