Ethereum Foundation’s Trillion Dollar Security Initiative Proposes Native Transaction Assertions to Eliminate Blind Signing Risks

The Ethereum Foundation’s ongoing Trillion Dollar Security initiative has pinpointed blind signing and transaction uncertainty as critical user experience and safety risks within the broader ecosystem. As part of its next major phase of infrastructure hardening, the initiative is actively exploring native transaction assertions—a mechanism designed to strictly enforce a transaction’s final execution outcome. Working alongside complementary solutions like Clear Signing, this research aims to fundamentally alter how users interact with smart contracts by bridging the gap between authorized intent and actual on-chain execution.

The core motivation behind this initiative stems from a fundamental reality of how Ethereum operates: the network executes instructions precisely as they are authorized, without evaluating whether the resulting state aligns with the user’s actual desires. When a user signs a transaction, they are committing to a specific request, but the final outcome remains vulnerable to the underlying code and state conditions encountered during execution. Over the history of the network, significant financial losses have occurred not just because users were tricked into approving malicious actions, but because even well-intentioned requests frequently produced unexpected, economically devastating results.

These security challenges typically manifest in two distinct ways. The first is an intent mismatch, a dangerous scenario vividly illustrated by high-profile exploits such as the Bybit security incident and the BadgerDAO attack. In both of these cases, compromised frontend interfaces successfully supplied signing requests that deviated entirely from what the users believed they were authorizing. During the Bybit incident, unsuspecting signers authorized actions that replaced their Safe’s core implementation contract, whereas users interacting with BadgerDAO unwittingly granted malicious actors sweeping permissions to drain their tokens.

The second major category is an outcome mismatch, where a signer authorizes a legitimate request, but shifting liquidity limits or the prevailing blockchain state results in an economic outcome that directly conflicts with the user’s explicit goals or institutional safety policies. A prominent example of this occurred during a high-value collateral swap involving Aave and CoW Swap. In that scenario, a user attempted to swap roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was vastly insufficient to absorb a trade of that unprecedented magnitude, and because CoW Swap’s gas ceiling rejected more complex multi-hop quotes during verification, only a single verified quote returning roughly 329 aEthAAVE remained. Although the user interface presented a stark 99.9 percent price impact warning and required explicit confirmation that the entire principal could be lost, the user signed the transaction regardless, ultimately receiving tokens valued at approximately $36,000.

What tied these diverse incidents together was the total absence of a trusted, immutable rule governing the resulting state—one defined completely independently of the transaction builder and strictly enforced at the protocol level during execution. In the Bybit scenario, an effective rule would have mandated that the approved Safe implementation contract remain entirely unaltered. For a BadgerDAO user, a protective rule would have restricted new token approvals exclusively to officially published and audited contracts. In the Aave scenario, a robust rule would have enforced a minimum acceptable output calculated independently of the quotes supplied by the interface, while simultaneously requiring solver-based protocols and settlement layers to respect that boundary. Currently, however, Ethereum lacks a generalized mechanism that allows on-chain code to inspect the full set of net state changes and emitted events produced by a single transaction.

A standard cryptographic signature commits strictly to the action requested by the user, incorporating the designated target contract, transferred value, and execution calldata. However, the Ethereum Virtual Machine executes this call against whatever contract code and environmental state happen to be present at the exact moment the transaction is included in a block, which can—and frequently does—differ from the state observed at the time of signing. Consequently, the resulting net balances, storage modifications, and emitted events often diverge sharply from expectations.

This vulnerability is exacerbated by proxy architecture, where a target contract or its downstream dependencies can have its underlying implementation modified prior to execution, causing the live code to differ from what the user originally inspected. Furthermore, transaction ordering creates persistent risks. A malicious actor can execute a sandwich attack or front-running sequence that shifts a liquidity pool’s price immediately before a victim’s swap processes, all without altering a single byte of the user’s signed transaction.

To combat these systemic vulnerabilities, the ecosystem has deployed several defensive layers, though each possesses distinct limitations. Clear Signing, for instance, provides human-readable explanations of what requested calldata actually does. However, its effectiveness relies entirely on accurate decoding by wallet interfaces and the user’s ability to spot discrepancies between the displayed summary and their true intent.

Another prominent defense is transaction simulation, which predicts the effects of a proposed transaction using a selected snapshot of the chain state. Because the underlying chain state can shift rapidly before block inclusion, the transaction ultimately included can differ from the one that was simulated. A stark reminder of this limitation occurred during the Radiant Capital exploit, where both the wallet interface and the simulation engine displayed the correct, intended transaction, while malware active on the signers’ local machines dynamically substituted a malicious payload precisely at the moment of signing.

Contract checks and wallet-level security guards also enforce specific rules during EVM execution. For example, Uniswap automatically reverts a swap if its final output falls below a predefined parameter known as amountOutMinimum. Similarly, Safe accounts utilize a checkAfterExecution hook that allows a designated security guard to inspect the account’s state immediately after execution and revert transactions that violate established configuration rules. However, both of these methodologies require developers to choose which specific state variables to inspect in advance. To read the storage of an external contract, they depend entirely on the functions that the contract explicitly exposes. While checking a token’s balance via standard functions is straightforward, an arbitrary proxy contract is under no obligation to expose its implementation address through a readable function call. Without such an explicit interface, a standard security guard cannot read the implementation slot directly. Crucially, these existing checks remain fundamentally incapable of inspecting a transaction’s comprehensive net set of state modifications. A guard can verify that a specific balance remains untouched, but it cannot query the EVM to determine what else shifted unexpectedly during the execution flow.

Native transaction assertions represent a paradigm shift by empowering on-chain code to inspect the entire set of net state changes after all constituent actions of a transaction have completed. Utilizing read-only logic, an assertion compares starting values against final outcomes to evaluate compliance with a pre-established rule. If the specified rule is violated, the entire transaction reverts.

Crucially, this validation rule is embedded directly within the transaction payload and is cryptographically signed alongside its primary actions. These rules can govern net changes across native asset balances, storage slots, newly deployed code, and emitted events. They can enforce minimum payout thresholds, cap maximum spending limits, block unauthorized token approvals, preserve an account’s foundational control logic, or whitelist an exclusive set of permissible modifications.

However, security experts emphasize that the source of the assertion rule is just as vital as the check itself. If a compromised frontend interface is allowed to dictate the terms of the assertion, it can simply write a rule that permits the malicious exploit. Therefore, a genuinely useful assertion rule must derive from an independently verified expression of user intent, a standing institutional policy, or immutable protocol logic that a compromised interface component has no power to alter.

Designing native transaction assertions at the protocol level requires complex decisions regarding what underlying information the EVM exposes, how assertion code accesses that data, and where the associated opcodes are permitted to run. Potential design choices include exposing state changes, events, or a combination of both. Access mechanisms range from enumerating raw entries and looking up specific values to copying the complete set of net state changes directly into memory. Furthermore, protocol architects must determine whether these specialized opcodes should be restricted to specific transaction types or execution phases, or made available universally across the EVM.

A leading approach currently under active consideration is EIP-7906, which builds directly upon the frame transactions established in EIP-8141. Under this architecture, a frame transaction contains an ordered sequence of discrete validation and action steps. EIP-7906 introduces a specialized, read-only POST_TX frame positioned at the very conclusion of the transaction lifecycle to verify the final outcome. While EIP-8141 has progressed significantly toward network implementation schedules, EIP-7906 has advanced to being actively "Considered for Inclusion" in upcoming protocol upgrades, though it remains unconfirmed.

The EIP-7906 design framework exposes both state modifications and event logs. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their associated code hashes. For instance, if a specific storage slot is written to five times during a complex execution path, it appears in the trace as a single consolidated entry detailing only its starting and final values. If a slot ultimately reverts to its original value by the end of the transaction, it is omitted entirely.

To interact with this data, the proposal introduces three new opcodes. The TXTRACE instruction enumerates net state changes and generated events, TXDIFF retrieves the starting and final values for targeted addresses and storage slots, and EVENTDATACOPY copies the payload of a specific event directly into memory.

These instructions are strictly constrained to execute solely within the POST_TX frame, which runs as a static call at the very end of the transaction. This ensures that the assertion can thoroughly inspect the execution outcome without altering state variables. If the defined rule is violated, the execution body reverts entirely, but the transaction remains recorded on-chain with a failed status, and the gas payer is charged for the computational resources consumed. This economic enforcement mechanism prevents malicious actors from exploiting the network by forcing block builders to process deliberately failing transactions for free.

Because EIP-7906 does not mandate that every transaction include an assertion, transaction builders retain the technical capability to omit them. Consequently, for a user’s standard transactions, wallet software must take responsibility for ensuring that every constructed frame transaction incorporates the necessary safety assertion. This protective rule can be generated dynamically via local wallet simulation or derived from a standing user-defined security policy.

For decentralized protocols, protecting users requires that core smart contract functions verify that incoming calls originate exclusively from frame transactions containing the exact required assertion. These contracts must actively reject ordinary transactions as well as frame transactions that feature missing or malformed assertions. As a result, wider adoption will require client applications and protocol integrations to standardize around compatible frame transactions, noting that already deployed, immutable smart contracts cannot retroactively add this validation check.

Beyond shielding everyday users and protocols from exploits, native transaction assertions open up robust new capabilities across the Ethereum ecosystem. For instance, they can significantly strengthen account delegation frameworks. When delegating operational authority to an automated agent or smart account, users can already restrict which contracts the agent may interact with, how much capital it can spend, and how long its permissions remain active. Native assertions add a crucial layer of control over the actual outcome of each transaction, allowing users to constrain not just the actions an agent takes, but the exact economic results those actions produce.

Protocols can also leverage assertions to enforce standardized safety checks for every caller utilizing frame transactions. In solver-based execution architectures, a protocol can specify the required outcome of a trade while leaving independent solvers entirely free to determine the routing path. This execution guarantee applies reliably within a single transaction on a given network, though it cannot inherently bridge state across multi-chain paths. Furthermore, assertions can verify that intricate automated workflows successfully reach their intended final states, ensuring that any residual tokens are automatically returned to the user and that leftover token approvals are cleanly revoked before final settlement.

As research and development surrounding native transaction assertions continue under the umbrella of the Ethereum Foundation’s Trillion Dollar Security initiative, developers are actively seeking engagement from wallet providers, application teams, and protocol architects. Stakeholders interested in exploring these use cases and contributing to the technical design can connect directly with the research team or participate in the ongoing EIP-7906 community discussion threads to help shape the future of Ethereum security controls.