The Ethereum Foundation’s ambitious Trillion Dollar Security initiative has identified critical user experience vulnerabilities within the Ethereum ecosystem, specifically highlighting the risks associated with "blind signing" and transaction uncertainty. In response, the initiative is actively exploring the implementation of native transaction assertions, a novel mechanism designed to enforce the intended final outcome of a transaction. This groundbreaking proposal aims to complement existing security measures like Clear Signing by providing an additional layer of on-chain verification for transaction results.
The core of the problem lies in the fundamental operational principles of the Ethereum Virtual Machine (EVM). A digital signature on the Ethereum network signifies an immutable authorization of a specific request, including the target address, the function to be called, and the accompanying data. However, the EVM’s execution model is deterministic and does not inherently judge the user’s intent or the desirability of the outcome. Instead, it executes precisely what has been authorized, interacting with the network’s state and contract code at the moment of execution. This decoupling of the signed request from the final realized state creates a potential vector for exploits, leading to users inadvertently approving actions that differ from their expectations or resulting in unintended financial consequences.
Understanding Transaction Uncertainty: Two Paths to Compromise
The inherent complexities of blockchain interactions can lead to two primary scenarios where a seemingly valid signature results in an undesirable outcome: intent mismatch and outcome mismatch.
Intent Mismatch: When What You Sign Isn’t What You Think
This category of exploits occurs when a user approves a transaction based on their understanding of its purpose, but the actual transaction executed by the EVM differs significantly due to malicious manipulation of the user interface or smart contract logic. The consequences can be severe, as demonstrated by high-profile incidents.
The Bybit incident, for example, saw users authorizing actions that appeared innocuous through their wallet interfaces. However, the underlying transaction data, manipulated by a compromised frontend, instructed the Safe wallet to replace its implementation contract. This change effectively handed over control of the wallet’s assets to the attackers. Similarly, the BadgerDAO attack involved a sophisticated exploit where users were tricked into signing transactions that granted attackers permission to drain their token reserves. In both cases, the user’s signature was valid for the transaction presented, but the presented transaction itself was designed to deceive.
Outcome Mismatch: When the Execution Yields Unexpected Results
Even when a user correctly understands the intended action of a transaction, unforeseen circumstances or subtle interactions within the blockchain can lead to an outcome that contradicts their economic goals or established safety policies. This can occur due to factors like insufficient liquidity, network congestion, or intricate smart contract interactions.
A poignant illustration of this is the collateral swap incident involving Aave and CoWSwap. A user intended to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the available Aave liquidity for such a large trade was insufficient. Furthermore, CoWSwap’s gas ceiling mechanism rejected more complex quotes during verification, leaving only a single verified quote for roughly 329 aEthAAVE. The user’s interface displayed a stark warning of a 99.9% price impact, explicitly stating that the entire value could be lost. Despite this warning and the significant risk highlighted, the user proceeded and signed the transaction. The final result was the acquisition of tokens valued at approximately $36,000, a stark contrast to the intended multi-million dollar swap.
In these outcome mismatch scenarios, the user’s signed request was technically correct, but the execution environment – including market conditions and network limitations – led to a disastrously unfavorable outcome. The lack of a mechanism to enforce specific outcome constraints independently of the transaction builder proved to be the critical vulnerability.
The Limits of Current Defenses
Ethereum currently employs several security measures to protect users, but these have been found to fall short in addressing the aforementioned risks.
Clear Signing: This approach focuses on improving the transparency of transaction data presented to users. It aims to decode complex calldata into human-readable descriptions of the intended action. While valuable, Clear Signing relies on accurate decoding and the user’s ability to recognize deviations from their intent. It does not, however, guarantee that the decoded action will lead to a desired outcome.
Transaction Simulation: Wallets and explorers often simulate the effects of a transaction against a chosen chain state to provide users with a preview of the outcome. However, this defense is vulnerable to several factors. The chain state can change between the time of simulation and the actual transaction inclusion, especially in volatile markets or during periods of high network activity. Furthermore, as seen in the Radiant Capital incident, malware on a user’s machine can intercept and alter the transaction data after simulation but before signing, presenting a seemingly legitimate transaction to the user while submitting a malicious one to the network. In this case, both the wallet interface and the simulation indicated the intended transaction, but malicious software substituted a harmful payload during the signing process.
Contract Checks and Wallet Guards: Many protocols and wallets implement on-chain checks and guards to enforce specific rules. For instance, Uniswap will revert a swap if the output falls below a user-defined amountOutMinimum. Safe’s checkAfterExecution hook allows for post-transaction state inspection to revert actions that violate owner-defined rules. While effective for specific, pre-defined conditions, these mechanisms have limitations. They typically require advance knowledge of which state variables to monitor and often depend on the target contract exposing specific functions (e.g., balanceOf) to read relevant data. Contracts that utilize proxies without exposing implementation addresses, for example, pose a challenge for guards seeking to verify code integrity. Crucially, these checks cannot broadly inspect the entire set of net state changes and events produced by a transaction. A guard might confirm a specific balance remains unchanged, but it cannot query the EVM for all other modifications that may have occurred.
Introducing Native Transaction Assertions: A New Paradigm for On-Chain Security
The Trillion Dollar Security initiative proposes native transaction assertions as a fundamental enhancement to Ethereum’s security model. This mechanism would empower on-chain code to inspect the complete spectrum of net state changes and events that occur after a transaction’s actions have been executed.
At its core, a transaction assertion would involve read-only logic embedded within the transaction itself. This logic would compare the initial and final states of various blockchain elements against a pre-defined rule. If the rule is violated, the transaction’s actions would be reverted. The assertion, along with the transaction’s primary actions, would be signed by the user, ensuring its integrity and immutability.
The scope of these assertions is extensive. They could encompass net changes to token balances, storage variables, code deployments, and even emitted events. This allows for the enforcement of precise conditions, such as:
- Minimum Output Guarantees: Requiring a minimum amount of a token to be received in an exchange.
- Spending Caps: Limiting the total amount of funds that can be spent in a transaction.
- Approval Restrictions: Preventing new token approvals from being granted to arbitrary addresses.
- Control Logic Preservation: Ensuring that an account’s core control mechanisms remain intact.
- Permitted Change Sets: Allowing only a specific, pre-defined set of state modifications.
The diagram below illustrates how assertions act as a final gatekeeper, scrutinizing the outcome of a transaction and reverting it if the established rules are not met.
[Diagram illustrating how assertions on Ethereum check the outcome and revert the transaction’s actions if the rules fail.]
A critical aspect of this design is the source of the assertion rule. A compromised frontend could potentially craft a malicious assertion that permits an attack. Therefore, for an assertion to be truly effective, it must originate from a source of independently approved user intent, a standing account policy, or protocol logic that cannot be altered by a compromised component.
Key Design Considerations for Native Assertions
The development of native transaction assertions necessitates careful consideration of several design choices that will shape their implementation and effectiveness.
1. Information Exposure: What data should the EVM expose to the assertion logic? Options include providing a comprehensive list of state changes, individual events, or a combination of both. The granularity of this information is crucial for enabling precise rule-setting.
2. Access Mechanisms: How will the assertion code interact with the exposed information? Potential methods include enumerating all entries in a state change log, allowing lookups for specific values, or copying the entire set of changes into memory for programmatic analysis.
3. Opcode Placement and Scope: Where and when should the opcodes (low-level EVM instructions) that facilitate these checks be available? They could be restricted to specific transaction types, such as "frame transactions," or allowed at any point during the EVM execution. The choice of placement will influence the flexibility and complexity of the assertions that can be implemented.
EIP-7906: A Promising Pathway Forward
One of the leading proposals exploring native transaction assertions is EIP-7906, "Transaction Assertions via State Diff Opcode." This Ethereum Improvement Proposal builds upon the framework established by EIP-8141, which introduced "frame transactions." Frame transactions are designed to encompass an ordered sequence of validation and action steps. EIP-7906 extends this by incorporating a read-only POST_TX frame at the conclusion of the transaction. This frame is specifically designated for verifying the transaction’s outcome.
EIP-8141 is slated for inclusion in the upcoming Hegotā upgrade, while EIP-7906 has progressed to the "Considered for Inclusion" stage, indicating significant community interest but not yet a confirmed inclusion in a future hard fork.
The design of EIP-7906 aims to provide comprehensive access to transaction outcomes. It proposes exposing both state changes and events. State changes would be reported as net differences in native ETH balances and storage slots, alongside information on newly deployed contracts and their code hashes. Crucially, if a storage slot is written multiple times within a transaction, it would be represented as a single entry detailing its starting and final values. If a slot reverts to its original value, it would not appear in the state diff, thus streamlining the data presented.
To facilitate this, EIP-7906 introduces three new EVM opcodes:
TTRACE: This opcode would enumerate all net state changes and events generated by the transaction.TXDIFF: This opcode would allow for retrieving the starting and final values of specific addresses and storage slots.EVENTDATACOPY: This opcode would enable the copying of an event’s associated data into memory for further analysis.
These opcodes would function exclusively within the POST_TX frame. This ensures that the assertion logic operates as a static call, meaning it can inspect the outcome without altering the state. If the assertion rule is violated, the entire execution body of the transaction would revert. However, the transaction itself would remain on the blockchain with a failed status. The gas payer would still be charged for the gas consumed during the execution, thereby preventing attackers from exploiting deliberately failing transactions for free.
The Imperative of Requiring Assertions
A critical aspect of any robust security mechanism is its mandatory application. EIP-7906, in its current form, does not mandate the inclusion of an assertion in every transaction. This means that the party constructing the transaction could choose to omit it.
For user-initiated transactions, wallets will play a vital role in ensuring that every frame transaction they construct includes the necessary assertion. This assertion could be derived from a wallet-level simulation or a pre-defined, standing policy applicable to all of the user’s transactions.
For protocols, securing critical functions will require them to verify that any incoming call originates from a frame transaction containing the precisely required assertion. Ordinary transactions and frame transactions with missing or incorrect assertions would be rejected. This would necessitate that callers and integrated systems adopt compatible frame transactions. It’s important to note that this check could not be retroactively applied to already deployed, immutable smart contracts.
Broadening the Horizons: Applications Beyond Direct Security
Beyond their direct application in enhancing user security and protocol resilience, native transaction assertions hold the potential to unlock a range of other valuable use cases.
Enhanced Delegation: When users delegate authority to agents (e.g., smart contract keepers or automated trading bots), they can currently set limits on which contracts the agent can interact with, the maximum amount it can spend, and the duration of its permissions. Transaction assertions could introduce an additional layer of control by imposing rules on the outcome of each delegated transaction. This would allow users to constrain not only what their agents can do but also the specific results that their actions must produce.
Protocol-Defined Safety Standards: Protocols could leverage transaction assertions to enforce specific safety checks for all callers utilizing frame transactions. This could standardize security practices across a protocol’s ecosystem.
Optimized Solver Execution: In decentralized exchange (DEX) protocols that utilize solvers for transaction routing, assertions could allow the protocol to specify the required outcome of a trade (e.g., a minimum output amount) while leaving the solver with the flexibility to determine the most efficient route. This guarantee would, however, be confined to a single transaction on a single network, and would not inherently cover cross-chain operations.
Workflow Completion Assurance: Assertions could be employed to verify that complex workflows reach their intended final state. For instance, they could ensure that any unused tokens are returned to the user and that any remaining token approvals are revoked upon completion of a multi-step process.
Shaping the Future of Ethereum Security
The design and implementation of native transaction assertions are ongoing efforts within the Ethereum Foundation’s Trillion Dollar Security initiative. The project actively seeks input from wallet and protocol teams who would be the primary users of this technology. Engagement is encouraged through direct communication with the initiative at [email protected] to explore use cases and contribute to the research. Furthermore, active participation in the discussion thread for EIP-7906 on Ethereum Magicians provides a platform for technical discourse and community feedback.
For more detailed information on risk controls and the priority workstreams of the Trillion Dollar Security initiative, interested parties can visit trilliondollarsecurity.org. The development of native transaction assertions represents a significant step towards building a more secure and predictable Ethereum ecosystem, empowering users and developers with greater control over the outcomes of their on-chain interactions.
