Layla Zulfa
The Ethereum Foundation’s "Trillion Dollar Security initiative" has intensified its focus on mitigating critical user experience risks stemming from blind signing and transaction uncertainty, announcing a strategic exploration of native transaction assertions. This innovative approach aims to enforce a transaction’s final outcome directly on-chain, working in conjunction with existing efforts like Clear Signing, to provide a robust new layer of protection for users and protocols within the vast Ethereum ecosystem. This move underscores a growing recognition within the blockchain community that while cryptographic signatures validate a user’s intent to initiate a transaction, they do not inherently guarantee the desired or expected outcome, a fundamental gap that has led to significant financial losses in the past. The proposed solution, exemplified by EIP-7906 (Transaction Assertions via State Diff Opcode), seeks to introduce a mechanism where the integrity and impact of a transaction can be verified against predefined rules after execution but before finalization, reverting the transaction if these rules are violated.
The Critical Flaw: Understanding Transaction Uncertainty
At the core of the problem lies Ethereum’s deterministic execution model. The Ethereum Virtual Machine (EVM) executes precisely what a user authorizes through a signed transaction, without an inherent mechanism to assess whether the resulting state changes align with the user’s ultimate objective. A digital signature commits to a specific set of input parameters (target contract, value, calldata), but the actual outcome is a dynamic interplay of this input with the contract’s code and the prevailing blockchain state at the moment of execution. This separation between signed intent and final outcome creates two primary vectors for unwanted results: "intent mismatch" and "outcome mismatch."
An intent mismatch occurs when a user signs a transaction believing it will perform one action, but the underlying data, often manipulated by a compromised interface or malicious software, instructs the blockchain to perform an entirely different, harmful action. The user’s mental model of the transaction diverges critically from the actual cryptographic commitment.
An outcome mismatch, conversely, arises when a user signs precisely the transaction they intended, but external factors or the state of the blockchain at execution time lead to a result that contradicts their economic goals or established safety policies. The transaction executes as authorized, but the consequences are unexpectedly adverse.
Case Studies in Compromise: Illustrative Security Incidents
Several high-profile incidents highlight the devastating impact of these vulnerabilities, underscoring the urgency behind the Ethereum Foundation’s initiative.
One prominent example of an intent mismatch occurred in the Bybit incident, where signers of a Safe (formerly Gnosis Safe) multi-signature wallet unknowingly authorized the replacement of the Safe’s implementation contract. This was facilitated by a compromised frontend that presented a legitimate-looking transaction to users, while subtly altering the underlying calldata to include a malicious payload. Had the transaction gone through undetected, attackers could have gained control over substantial assets held within the Safe. Similarly, the BadgerDAO attack saw users granting an attacker permission to spend their tokens, again through a compromised frontend feeding malicious signing requests. These attacks collectively resulted in millions of dollars in potential or actual losses, eroding user trust and highlighting the insidious nature of sophisticated phishing and malware campaigns targeting Web3 users.
The outcome mismatch scenario was starkly illustrated in the Aave and CoW collateral swap. A user initiated a swap of approximately $50.4 million in aEthUSDT for aEthAAVE. However, the AAVE liquidity pool was critically shallow for a transaction of that magnitude. Exacerbating the issue, CoW Swap’s gas ceiling mechanisms rejected more complex, potentially safer quotes during verification, leaving only one highly unfavorable option. The user interface displayed a stark 99.9% price impact warning, explicitly requiring confirmation that the entire value could be lost. Despite this warning, the user proceeded, ultimately receiving aEthAAVE tokens valued at only about $36,000 – a colossal loss of over $50 million. In this case, the user signed the intended transaction, but the prevailing market conditions and protocol limitations produced an outcome that fundamentally conflicted with their economic objective.
These incidents underscore a critical missing layer in Ethereum’s security architecture: a trusted, on-chain mechanism to define and enforce rules over the resulting state of a transaction, independent of the transaction builder or external interfaces. For the Bybit incident, such a rule could have mandated that the Safe’s implementation contract remain unchanged. In the BadgerDAO case, a rule could have restricted new token approvals only to a whitelist of official Badger contracts. For the Aave user, an assertion could have specified a minimum acceptable output for the swap, reverting the transaction if this threshold was not met, irrespective of the interface’s warnings or the solver’s chosen route. Without a general mechanism for on-chain code to inspect the full set of net state changes and events produced by a transaction, these vulnerabilities persist.
Limitations of Current Security Measures
The Ethereum ecosystem is not devoid of security measures, but existing defenses fall short in addressing the full spectrum of transaction uncertainty.
Clear Signing, a significant improvement over opaque hexadecimal data, aims to present human-readable explanations of what a transaction’s calldata requests. It relies on accurate decoding and the user’s ability to recognize discrepancies between the displayed action and their intent. While vital, Clear Signing alone cannot prevent an outcome mismatch or detect subtle malicious changes if the presented information is itself compromised or if the user overlooks critical details.
Simulation tools predict a transaction’s effects by executing it against a selected chain state. These tools offer a valuable preview, but their predictions are inherently vulnerable to changes in chain state between simulation and actual inclusion on the blockchain. Furthermore, as demonstrated in the Radiant Capital incident, sophisticated malware can substitute a malicious payload at the moment of signing, even if the wallet interface and initial simulation showed the intended transaction. In Radiant Capital’s case, users saw a legitimate transaction, but malware injected a different, harmful transaction just before signing, bypassing all client-side checks.
Contract checks and wallet guards also enforce rules during EVM execution. For instance, Uniswap reverts a swap if the output falls below a user-defined amountOutMinimum. Safe’s checkAfterExecution hook allows a guard contract to inspect an account’s state post-execution and revert transactions violating predefined rules for owners or configuration. However, these checks require pre-determining which specific state variables to inspect. They also depend on target contracts exposing the necessary functions (e.g., balanceOf for token balances). Crucially, these mechanisms cannot inspect the transaction’s full set of net state changes. A guard can verify that a particular balance remains unchanged, but it cannot generically query the EVM about everything else that changed. Effects not explicitly anticipated and coded for can therefore go unnoticed, leaving significant blind spots.
Introducing Native Transaction Assertions
Native transaction assertions represent a paradigm shift in Ethereum security by allowing on-chain code to inspect the entire set of net state changes after a transaction’s actions have completed. This mechanism involves including a read-only "assertion" logic within the transaction itself, which compares the blockchain’s state before and after the transaction’s primary execution. If this assertion logic determines that the final state violates a predefined rule, the entire transaction is reverted.
The assertion rule, like the transaction’s actions, is cryptographically signed by the user. This rule can be highly granular, covering net changes to ETH balances, storage slots, contract code, newly deployed contracts, and emitted events. For example, an assertion could:
- Require a minimum amount of a specific token to be received.
- Cap the maximum amount of a token spent.
- Block the creation of new token approvals.
- Preserve an account’s control logic (e.g., preventing a proxy’s implementation from changing unexpectedly).
- Allow only a specified, whitelisted set of state changes.
The power of assertions lies in their ability to act as an on-chain safety net, ensuring that the outcome aligns with the user’s intent and security policies, even if the initial signed request was subtly manipulated or market conditions shifted adversely. The diagram below illustrates this flow: the user signs a request with embedded assertion rules; the transaction executes; the assertion checks the resulting state; if rules fail, the entire transaction reverts, protecting the user.
Crucially, the source of the assertion rule is as important as the check itself. A compromised frontend could, in theory, generate a malicious assertion that permits an attack. Therefore, a useful rule must originate from an independently approved source, such as a user’s trusted wallet configuration, a standing account-level policy, or robust protocol logic that cannot be altered by a compromised component. This independent source ensures the integrity of the safety check.
Architectural Considerations and Design Choices
The design and implementation of native transaction assertions require careful consideration of several fundamental architectural choices within the EVM:
- Information Exposure: What specific information about state changes should the EVM expose to the assertion logic? This could include balance changes, storage modifications, code deployments, or event logs, or a combination thereof. EIP-7906, for instance, proposes exposing net differences in native ETH balances and storage, alongside newly deployed contracts and their code hashes. A storage slot modified multiple times within a transaction would appear as a single entry reflecting its initial and final values. If a slot returns to its original value, it would not appear at all, optimizing for net changes.
- Access Methods: How should assertion code access this exposed information? Options include iterating through all recorded changes, querying specific values (e.g., "what was the final balance of address X?"), or copying the full set of changes into memory for detailed analysis.
- Opcode Placement and Execution Phase: Where in the EVM execution lifecycle should the new opcodes (instructions) for assertions be allowed to run? Should they be restricted to specific transaction types or execution phases, or available anywhere? EIP-7906 proposes a dedicated, read-only
POST_TXframe at the very end of the transaction execution. This static call environment ensures that the assertion logic can inspect the final outcome without itself introducing any state changes, maintaining its integrity as a purely verification step.
EIP-7906: A Proposed Path Forward
One leading proposal for native transaction assertions is EIP-7906: Transaction Assertions via State Diff Opcode. This Ethereum Improvement Proposal builds upon the foundational concept of "frame transactions" introduced in EIP-8141, which defines a structured transaction type allowing an ordered sequence of validation and action steps. EIP-7906 extends this by adding a critical, read-only POST_TX frame that executes at the very end of a transaction, specifically designed to check the final outcome against predefined assertions.
EIP-8141, crucial for this framework, is currently scheduled for inclusion in the upcoming Hegotá upgrade, indicating a clear roadmap for the underlying infrastructure. EIP-7906 has advanced to "Considered for Inclusion," signifying its importance and potential for future upgrades, though its final confirmation for a specific network upgrade is still pending.
The design of EIP-7906 is comprehensive, exposing both state changes and events. It introduces three new EVM opcodes to facilitate access to this information:
TXTRACE: This opcode allows the assertion code to enumerate through all net state changes and emitted events, providing a detailed ledger of the transaction’s impact.TXDIFF: This opcode enables retrieval of the starting and final values for specific addresses and storage slots, allowing targeted verification of critical state variables.EVENTDATACOPY: This opcode permits copying an event’s data into memory, allowing assertions to check specific event emissions, which are often crucial for inter-contract communication and off-chain monitoring.
These opcodes are explicitly restricted to operate only within the POST_TX frame. This frame executes as a static call, meaning it cannot modify the blockchain state itself. This read-only enforcement is vital for the assertion’s integrity, ensuring it acts purely as a validator. If an assertion rule is violated, the entire preceding execution body of the transaction is reverted. However, a crucial design choice is that the transaction remains in the block with a failed status, and the gas payer is still charged for the gas consumed up to the point of reversion. This mechanism is a vital anti-spam measure, preventing attackers from exploiting the system by submitting deliberately failing transactions for free, which could otherwise be used to clog the network.
Ensuring Adoption: The Mandate for Assertions
While EIP-7906 provides the technical capability for transaction assertions, it does not inherently mandate their use. This presents a key challenge for widespread adoption and effectiveness.
For individual users’ transactions, the responsibility will largely fall on wallet providers. Wallets must be designed to ensure that every frame transaction they construct includes the necessary assertions. This could involve generating assertions dynamically based on a simulation of the intended transaction, or by applying standing, user-defined policies that govern all outgoing transactions (e.g., "never allow token approvals over $1,000," or "always ensure at least X amount of ETH remains in the wallet").
For protocols, the integration would be more complex. A protocol’s protected functions would need to be modified to verify that any incoming call originates from a frame transaction that contains the exact required assertion. The protocol would then reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach would necessitate that all callers and integrations adapt to using compatible frame transactions. A significant hurdle is that already deployed, immutable smart contracts cannot retroactively add this check, limiting the immediate applicability to newly deployed or upgradeable contracts. This implies a gradual rollout and adoption curve, potentially requiring significant ecosystem coordination.
Broader Implications and Future Use Cases
Beyond bolstering security for individual users and preventing malicious exploits, native transaction assertions unlock a wide array of powerful use cases that could fundamentally enhance the functionality and trustworthiness of the Ethereum ecosystem:
- Strengthening Delegation: When users delegate authority to an agent (e.g., a smart contract wallet managing funds, or an automated trading bot), assertions can add a crucial layer of control. While existing methods can limit which contracts an agent interacts with, how much it spends, or the duration of its permissions, assertions can constrain the outcome of each delegated transaction. For instance, a user could assert that a trading bot never makes a swap with more than 1% slippage, or that a delegated spending account never depletes the ETH balance below a certain threshold.
- Protocol-Defined Safety Checks: Protocols could define their own universal safety rules, requiring every caller using a frame transaction to adhere to them. This provides a standardized, on-chain guarantee of expected behavior for all interactions with the protocol, enhancing overall system integrity.
- Optimized Solver Execution: In complex decentralized finance (DeFi) scenarios involving solvers (e.g., in intent-based architectures like CoW Swap), assertions could empower the protocol or user to specify the required outcome of an operation (e.g., "I must receive at least X amount of Y token") while granting the solver maximum flexibility to determine the most efficient execution route. This guarantees user intent while optimizing for execution. It’s important to note, however, that this guarantee would apply only within a single transaction on a single network, not across multi-chain operations.
- Workflow Validation: Assertions could be used to ensure that multi-step workflows reach their intended final state. For example, after a complex DeFi interaction, assertions could verify that any unused tokens are returned to the user, or that temporary token approvals are revoked, minimizing residual attack surface. This moves beyond simply checking individual transaction components to validating the holistic integrity of a sequence of operations.
- Enhanced Compliance and Reporting: For institutional users or those operating under regulatory frameworks, assertions could provide an auditable, on-chain record that transactions adhered to specific compliance rules, enhancing transparency and accountability.
Industry Reactions and Collaborative Development
The "Trillion Dollar Security initiative" and the exploration of native transaction assertions have been met with considerable interest and enthusiasm from various segments of the Ethereum community. Spokespersons from the Ethereum Foundation emphasize that these advancements are critical for the long-term scalability and mainstream adoption of Web3 technologies. "The current state of transaction signing leaves too much room for user error and malicious exploitation," stated a representative. "Native transaction assertions are designed to shift the burden of outcome verification from the user to the protocol, fundamentally enhancing trust and safety."
Wallet developers are reportedly keen on integrating these features, seeing them as a powerful tool to protect their users and differentiate their products. "The ability to provide an ironclad, on-chain guarantee of transaction outcome will be a game-changer for user experience and confidence," remarked a lead developer at a major wallet provider. Protocol teams, particularly those managing substantial user funds or complex interactions, are actively engaging in the design discussions, eager to leverage assertions for enhanced security and to define robust interaction policies for their ecosystems. The ongoing discussions on the Ethereum Magicians forum for EIP-7906 underscore the collaborative nature of this development, with community feedback actively shaping the technical specifications and implementation strategies.
Conclusion
Native transaction assertions represent a monumental step forward in securing the Ethereum ecosystem, addressing fundamental vulnerabilities that have plagued users and protocols. By moving beyond mere intent verification to actual outcome enforcement on-chain, this initiative promises to drastically reduce the risks associated with blind signing and transaction uncertainty. While significant design and adoption challenges remain, particularly in ensuring widespread integration by wallets and protocols, the clear benefits for user safety, trust, and the expansion of complex decentralized applications make this a high-priority endeavor. The Ethereum Foundation’s "Trillion Dollar Security initiative" continues to invite active participation from developers, researchers, and users to refine and implement these crucial security enhancements, paving the way for a more secure and resilient decentralized future. Interested parties are encouraged to engage with the initiative at trilliondollarsecurity.org and join the EIP-7906 discussion thread on Ethereum Magicians to help shape the future of Web3 security.
