Layla Zulfa
The Ethereum Foundation, in its ongoing commitment to bolster the security and trustworthiness of the world’s leading decentralized platform, has pinpointed two fundamental vulnerabilities: blind signing and transaction uncertainty. These issues significantly undermine user confidence and have led to substantial financial losses within the ecosystem. In response, the Foundation’s "Trillion Dollar Security" initiative is actively pursuing a groundbreaking solution: native transaction assertions. This innovative approach aims to equip the Ethereum Virtual Machine (EVM) with the capability to verify the actual outcomes of transactions against predefined user or protocol rules, thereby ensuring that the executed result aligns with the user’s intent. This development is designed to work in tandem with "Clear Signing," an existing effort focused on making transaction details transparent to users before approval.
Unpacking the Core Problem: When Intent Diverges from Outcome
The inherent design of Ethereum transactions, while robust in its cryptographic integrity, presents a unique challenge: a valid signature guarantees the execution of a request, but not necessarily the desired outcome. The Ethereum Virtual Machine (EVM) meticulously executes the authorized instructions without an intrinsic mechanism to judge whether the final state changes align with the user’s underlying economic or security goals. This fundamental disconnect can manifest in two critical ways, both of which have been exploited by malicious actors or led to unintended consequences for users.
The first, and often most insidious, is an intent mismatch. This occurs when a user signs a transaction believing it will achieve one specific purpose, but the actual calldata or parameters commit them to something entirely different, often due to a compromised frontend or sophisticated phishing. High-profile incidents vividly illustrate this danger. In December 2021, the BadgerDAO attack saw users unknowingly grant an attacker permission to spend their tokens, resulting in losses exceeding $130 million. A compromised frontend injected malicious scripts, altering legitimate transaction requests into approvals for the attacker’s wallet. Similarly, the Bybit incident (though specific dates and exact losses are less publicly detailed, it often refers to scenarios where compromised interfaces tricked users) involved signers inadvertently authorizing the replacement of a Safe’s implementation contract, effectively handing over control. In both cases, users were presented with what appeared to be routine interactions, only for their signed approval to facilitate a malicious action that fundamentally diverged from their perceived intent. The cryptographic signature was valid, but the user’s understanding of what they were signing was fatally flawed.
The second form of failure is an outcome mismatch. Here, the user signs the request they were shown, and the request itself might be legitimate, but external factors or the state against which it runs produce a result that significantly conflicts with their expectations. A stark example is the Aave and CoW collateral swap, which occurred around May 2023. A user attempted to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, the AAVE liquidity was critically low for a transaction of that magnitude. Despite a warning from the interface about a 99.9% price impact and the potential for total value loss, the user proceeded. Due to CoWSwap’s gas ceiling rejecting more complex, and potentially better, quotes during verification, the transaction settled for roughly 329 aEthAAVE, valued at approximately $36,000 – a catastrophic loss of over 99% of the intended value. The user’s intent to swap tokens was clear, and the transaction was technically valid, but the actual outcome was far from what any rational participant would desire.
Crucially, in all these instances, there was no trusted, on-chain mechanism to enforce a rule over the resulting state of the transaction, defined independently of the transaction builder. A rule for Bybit’s signers could have mandated that the Safe implementation contract remain unchanged. For Badger users, a rule might have restricted new token approvals exclusively to whitelisted Badger contracts. The Aave user could have benefited from a rule setting a minimum acceptable output for the swap, independent of the quoted price. The current Ethereum architecture, however, lacks a general, native mechanism for on-chain code to inspect the comprehensive set of net state changes and events produced by a transaction after its execution but before its finalization.
The Limits of a Signature: What It Doesn’t Control
A digital signature on Ethereum commits an address to a specific transaction request, encompassing the target contract, the value transferred, and the calldata (the instructions for the contract). However, the execution environment of the EVM is dynamic. The contract code and state against which the transaction runs may have changed between the moment the user signs and when the transaction is finally included in a block. This temporal gap introduces significant uncertainty.
Consider a scenario where a target contract utilizes a proxy. The underlying implementation contract, which dictates the actual code executed, could be swapped out by a malicious actor or even a legitimate upgrade before your transaction executes. Your signature commits to calling the proxy, but the code that ultimately runs might be entirely different from what you reviewed.
Furthermore, transaction ordering within a block or across blocks can dramatically alter the state a call encounters. A classic example is a "sandwich attack" in decentralized finance (DeFi). An attacker can front-run a user’s swap order by placing a buy order just before it, driving up the price, and then back-run it with a sell order immediately after, profiting from the price movement. The user’s signed swap transaction remains unchanged, but the economic outcome is severely impacted by the altered pool price. These examples highlight that while a signature is immutable, the context of its execution is not, leading to potential discrepancies between expectation and reality.
Current Defenses and Their Inadequacies
The Ethereum ecosystem has developed several layers of defense against these issues, but each has inherent limitations.
Clear Signing represents a crucial step forward. Instead of presenting users with raw hexadecimal calldata, wallets employing Clear Signing decode the transaction details into human-readable formats (e.g., "Approve X amount of Y token for Z contract"). This allows users to understand the specific action they are authorizing. However, Clear Signing relies on accurate decoding and the user’s ability to discern if the presented action differs from their intent. It doesn’t prevent an outcome mismatch if the underlying state changes or if the action, while clearly stated, has unforeseen negative consequences due to market conditions or contract logic.
Transaction Simulation offers another layer of protection. Wallets and security tools can simulate a transaction’s effects against a chosen chain state, providing a preview of potential balance changes or contract interactions. While valuable, simulations are only as good as the state they run against. The actual chain state can change before the transaction is included in a block, rendering the simulation’s predictions obsolete. More critically, as demonstrated in Radiant Capital’s post-mortem (following an exploit, though specific details of a wallet/simulation malware incident are not explicitly linked to Radiant’s publicly known flash loan vulnerability, the general principle applies to sophisticated malware), sophisticated malware on a user’s machine can substitute a malicious payload at the moment of signing, even if the wallet interface and initial simulation showed the intended transaction. The user believes they are signing the simulated transaction, but the malicious payload is what gets committed to the blockchain.
Finally, Contract Checks and Wallet Guards provide on-chain enforcement. Protocols like Uniswap include amountOutMinimum parameters, which revert a swap if the output falls below a user-defined threshold. Safe (formerly Gnosis Safe) smart accounts leverage checkAfterExecution hooks, allowing a guard contract to inspect the account’s state post-execution and revert transactions that violate predefined rules (e.g., preventing unauthorized configuration changes). While effective for specific, pre-programmed conditions, these approaches require defining which state variables to check in advance. They are limited by the public functions exposed by other contracts – for instance, a token’s balanceOf function makes balance checks straightforward, but a proxy contract might not expose its implementation address directly. Without such an interface, a guard cannot directly inspect a specific storage slot to ensure, for example, that a critical contract’s implementation hasn’t been covertly altered. Crucially, these existing 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 ask the EVM what else changed across the entire state, leaving unanticipated side effects unnoticed.
The Promise of Native Transaction Assertions
Native transaction assertions represent a paradigm shift in on-chain security. The core idea is to allow 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 validation step, comparing the state before and after the transaction against a set of predefined rules. If any rule is violated, the transaction’s primary actions are reverted, preventing an undesirable outcome from being finalized.
These rules are included within the transaction itself and are signed alongside the transaction’s primary actions. This ensures that the user’s explicit consent extends not just to what the transaction does, but also to what it achieves. The scope of these assertions is broad, capable of covering:
- Net changes to native ETH balances and ERC-20 token balances.
- Modifications to contract storage.
- Deployment of new contracts and their associated code hashes.
- Emitted events, allowing for checks on specific logging patterns.
This enables powerful safety policies: an assertion could mandate a minimum amount 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 restrict changes to only a specified, whitelisted set. The diagram illustrates this: the transaction’s actions execute, then assertions check the final state, and if rules fail, the entire action set reverts.
The source of the assertion rule is paramount. A compromised frontend could, theoretically, craft an assertion that permits an attack. Therefore, a useful rule must originate from an independently approved source, such as explicit user intent confirmed by a secure wallet, a standing account policy (e.g., set up by a smart contract wallet or multi-sig), or immutable protocol logic that cannot be manipulated by a compromised component. This independent validation layer is what grants assertions their robust security properties.
EIP-7906: A Concrete Path Forward
The Ethereum Foundation’s research into native transaction assertions has coalesced around several design choices, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate. This Ethereum Improvement Proposal builds upon EIP-8141 (Frame Transactions), which introduces a structured transaction type with ordered sequences 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 where the assertion logic resides, allowing it to inspect the transaction’s outcome after all other actions have completed.
EIP-8141, foundational to this approach, is currently scheduled for inclusion in the upcoming Hegotá network upgrade, indicating significant progress. EIP-7906 itself has advanced to "Considered for Inclusion," signifying that it is under serious review for future upgrades, though its final confirmation is pending.
The design of EIP-7906 is comprehensive:
- Exposed Information: It exposes both net state changes and emitted events. State changes are reported as net differences: native ETH balance changes, storage slot modifications (showing original and final values), and details of newly deployed contracts including their code hashes. Importantly, if a storage slot is written to multiple times but ends with its original value, it does not appear in the diff, focusing on actual net changes.
- New Opcodes: Three new EVM instructions are proposed to facilitate access to this information:
TXTRACE: Allows enumeration of all net state changes and events.TXDIFF: Enables retrieval of starting and final values for specific addresses and storage slots.EVENTDATACOPY: Facilitates copying an event’s data into memory for detailed inspection.
- Execution Context: These opcodes are strictly limited to execution within the
POST_TXframe, which runs as aSTATICCALL. This crucial restriction ensures that the assertion logic itself cannot modify the state, maintaining its integrity as a pure validation layer. If the 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 consumed gas. This mechanism is vital for preventing denial-of-service attacks, where malicious actors might intentionally submit failing transactions for free, thereby burdening network resources.
The Imperative of Required Assertions
While EIP-7906 provides the mechanism for native transaction assertions, it does not mandate their inclusion. This creates a critical challenge for adoption and efficacy: if an assertion is optional, a malicious actor or a compromised frontend could simply omit it, circumventing the intended security benefits.
Therefore, for assertions to be truly effective, they must be required in specific contexts:
- Wallet Responsibility: For user-initiated transactions, the wallet software plays a pivotal role. Wallets must be updated to ensure that every frame transaction they construct includes the necessary assertion. This rule could be derived from a real-time simulation performed by the wallet or from a standing security policy configured by the user (e.g., "never approve a token transfer greater than X amount," or "always ensure this specific contract’s code hash remains unchanged").
- Protocol Enforcement: Decentralized applications (dApps) and smart contracts must also evolve. A protocol’s critical functions would need to verify that incoming calls originate from a frame transaction containing the exact required assertion. Any ordinary transaction, or a frame transaction with a missing or incorrect assertion, would be rejected. This implies a significant shift for dApp developers and requires callers and integrations to adopt compatible frame transactions. A key challenge is that already deployed, immutable smart contracts cannot retroactively add this check, limiting its application to new deployments or upgradable contracts.
Broader Implications and Future Horizons
Beyond the immediate and profound security benefits for individual users and protocols, native transaction assertions unlock a wealth of new possibilities and strengthen existing paradigms within the Ethereum ecosystem.
One significant area is strengthening delegation. When users delegate authority to an agent (e.g., a smart contract wallet managing funds, or an automated trading bot), they can already impose limits on which contracts the agent interacts with, how much it spends, or the duration of its permissions. Assertions could add an unprecedented layer of control by allowing users to define specific outcome rules for each transaction executed by the agent. This means users could constrain not only what the agent is permitted to do but also what its actions must produce, adding a powerful safety net against unintended consequences or agent misbehavior.
Protocol-defined safety checks could also become universal. A dApp could define its own invariant rules, requiring the same safety checks for every caller interacting with its core functionalities via a frame transaction. In the context of solver-based execution (common in MEV-protected or aggregated swaps), a protocol could specify a precise, required outcome for a transaction while granting the solver flexibility in choosing the optimal execution path. This guarantees the desired end-state, irrespective of the complex routing chosen by the solver. It’s important to note, however, that this guarantee applies only within a single transaction on a single network, not across multiple chains.
Furthermore, assertions could be leveraged to ensure workflow integrity. For complex multi-step interactions, assertions could verify that a workflow reaches its intended final state, for example, confirming that unused tokens are returned to the user, or that any temporary token approvals granted during the process are revoked post-execution. This adds a crucial layer of transactional hygiene and reduces residual risks.
The "Trillion Dollar Security" Context
The "Trillion Dollar Security initiative" is not merely about addressing specific vulnerabilities but represents a holistic, proactive strategy by the Ethereum Foundation to secure the vast and growing value locked within the Ethereum ecosystem. With Ethereum underpinning a global financial layer securing hundreds of billions, and potentially trillions, of dollars in assets, the imperative for robust, native security mechanisms is paramount. This initiative encompasses various research and development tracks, from formal verification of smart contracts to improving wallet interfaces and, critically, enhancing the fundamental security properties of the EVM itself. Native transaction assertions are a cornerstone of this broader vision, aiming to elevate the baseline security guarantees for every participant. By addressing blind signing and transaction uncertainty at the protocol level, the Foundation seeks to foster greater user trust, accelerate mainstream adoption, and cement Ethereum’s position as the most secure and reliable platform for decentralized applications.
Engaging with the Future: Shape the Design
The development of native transaction assertions remains an active and collaborative process. The Ethereum Foundation is keen to gather insights and feedback from the wider community, particularly from wallet developers, protocol teams, and security researchers who will be the primary implementers and beneficiaries of these advancements. Those interested in exploring specific use cases, contributing to the research, or providing input on the design choices are encouraged to reach out to [email protected]. Additionally, the EIP-7906 discussion thread on Ethereum Magicians (ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130) serves as a public forum for technical discourse and community input. Further information on risk controls and priority work within the broader initiative can be found at trilliondollarsecurity.org. By actively participating, the community has a unique opportunity to shape the future of Ethereum’s security architecture, making the network safer and more predictable for everyone.
