How native transaction assertions could enforce a transaction’s final outcome

This pivotal development marks a significant stride in bolstering user safety and transaction integrity across the Ethereum ecosystem. The initiative aims to address a critical vulnerability where a valid cryptographic signature does not inherently guarantee the desired outcome of a blockchain transaction. This disconnect between user intent and actual transaction results has led to substantial financial losses and eroded trust in decentralized applications (dApps). By introducing native transaction assertions, the Ethereum Foundation seeks to embed a robust, on-chain mechanism that allows users and protocols to define and enforce specific conditions for a transaction’s successful execution, thereby providing an unprecedented layer of security.

The Genesis of a Problem: Intent vs. Outcome Mismatch

At its core, the challenge stems from Ethereum’s deterministic execution model. The Ethereum Virtual Machine (EVM) meticulously executes precisely what a user authorizes via a signature, without inherent judgment on whether the resulting state aligns with the user’s ultimate objective. A signature acts as a commitment to a specific request (target contract, value, and calldata), but the actual outcome is profoundly influenced by the prevailing contract code and blockchain state at the moment of execution. This can lead to two primary categories of failure: an "intent mismatch" or an "outcome mismatch."

An intent mismatch occurs when users unwittingly approve a transaction that differs fundamentally from their understanding or expectation. This often arises from compromised frontends or malicious interfaces that display one set of parameters to the user while generating a completely different, harmful transaction for signing. The user believes they are signing one thing, but the underlying data commits them to another.

Conversely, an outcome mismatch happens when the user signs precisely the transaction they were shown and intended, but the execution against the current chain state, or the absence of sufficient protective parameters, yields an undesirable or economically damaging result. This could be due to unexpected market conditions, front-running attacks, or protocol limitations that are not immediately apparent during the signing process.

Illustrative Incidents: Highlighting Systemic Risks

Several high-profile incidents underscore the urgent need for native transaction assertions, demonstrating how both intent and outcome mismatches can lead to severe financial consequences:

Bybit Incident (Intent Mismatch): In a notable security event, signers associated with Bybit’s operations unknowingly authorized the replacement of a Safe’s implementation contract. This was not the intended action. A compromised frontend presented a benign-looking transaction for approval, but the underlying calldata discreetly facilitated a critical change to the Safe’s architecture. Had an assertion been in place requiring the Safe’s implementation contract to remain unchanged for that specific transaction, the malicious action would have been automatically reverted.

BadgerDAO Attack (Intent Mismatch): The BadgerDAO incident saw users grant attackers broad permissions to spend their tokens. This attack vector leveraged a compromised frontend to inject malicious scripts, manipulating user interfaces to present seemingly legitimate approval requests. In reality, these requests conferred excessive allowances to an attacker-controlled address. A native transaction assertion could have enforced a rule limiting new token approvals strictly to known and verified Badger contracts, thereby preventing the attacker from gaining unauthorized control over user funds.

Aave and CoW Collateral Swap (Outcome Mismatch): This incident serves as a stark example of an outcome mismatch. A user initiated a swap of approximately $50.4 million in aEthUSDT for aEthAAVE. However, the liquidity for aEthAAVE was critically low for such a large trade. Compounding the issue, CoW Swap’s gas ceiling rejected more complex (and potentially safer) quotes during verification, leaving only a single, highly unfavorable quote for roughly 329 aEthAAVE. Despite the interface displaying a 99.9% price impact warning and requiring explicit user confirmation of potential total loss, the user proceeded. The outcome was receiving tokens worth merely $36,000 from a $50.4 million input. A robust assertion in this scenario would have allowed the user to set a minimum acceptable output value, calculated independently of the interface’s displayed quote, ensuring the transaction would revert if this economic threshold was not met.

These cases collectively highlight a significant gap in Ethereum’s current transaction model: the absence of a general, on-chain mechanism for code to inspect and validate the full set of net state changes and emitted events produced by a transaction before it is finalized.

The Limitations of Existing Security Paradigms

Before native transaction assertions, various security measures have been implemented, each with its own merits and limitations:

1. Clear Signing: This defense mechanism aims to decode and present the user with a human-readable explanation of what a transaction’s calldata is requesting. It empowers users to identify discrepancies between their perceived intent and the actual action. However, its effectiveness hinges on accurate decoding tools and the user’s ability to recognize a malicious or unintended action, which can be challenging with complex smart contract interactions or sophisticated attack vectors. Clear Signing addresses the "intent mismatch" by making the intent clearer, but it doesn’t prevent an "outcome mismatch" if the clear intent still leads to a bad result due to external factors.

2. Transaction Simulation: Wallets and dApps often provide simulation services, predicting a transaction’s effects against a chosen chain state. While valuable for pre-execution analysis, simulations are not foolproof. The chain state can change between the time of simulation and actual inclusion in a block, leading to different outcomes. More critically, malware on a user’s machine can substitute a malicious payload after simulation and before signing, as seen in the Radiant Capital incident where both the wallet interface and simulation displayed the intended transaction, but a different, harmful one was signed.

3. Contract Checks and Wallet Guards: These are on-chain mechanisms embedded within smart contracts or smart wallets (like Gnosis Safe). For instance, Uniswap reverts a swap if the output falls below a pre-defined amountOutMinimum. Safe’s checkAfterExecution hook allows a guard contract to inspect the account’s state post-execution and revert transactions violating specific rules. While powerful, these approaches require defining specific state checks in advance and are limited by the information exposed by other contracts. A guard can verify a particular balance remains unchanged but cannot comprehensively inspect all net state changes or events. If a proxy contract’s implementation address isn’t exposed via a function, a guard cannot directly read the critical storage slot, leaving a blind spot. They are designed for specific, known vulnerabilities, not for the full spectrum of potential state alterations.

Crucially, none of these existing defenses offer a general mechanism for on-chain code to inspect the entire set of net state changes (balances, storage, code deployments) and events generated by a transaction, which is the core capability that native transaction assertions aim to provide.

The Mechanism of Native Transaction Assertions

Native transaction assertions represent a paradigm shift by empowering on-chain code to inspect the comprehensive set of net state changes after a transaction’s primary actions have been executed, but before its finalization. An assertion functions as a read-only logic gate: it compares the state before the transaction to the state after its execution against a predefined rule. If this rule is violated, the entire transaction (including its primary actions) is automatically reverted.

The assertion rule itself is included within the transaction payload and cryptographically signed alongside the transaction’s core actions. This binding ensures that the user’s intent regarding the outcome is immutable and verifiable on-chain. These rules are remarkably flexible, capable of covering:

• Net changes to ETH balances and token balances.
• Modifications to contract storage slots.
• Deployment of new contracts and their associated code hashes.
• Emission of specific events.
• Minimum acceptable output amounts for swaps.
• Caps on spending or token approvals.
• Preservation of an account’s control logic (e.g., ensuring a Safe’s implementation contract remains unchanged).
• Allowing only a specified, whitelisted set of changes.

The critical distinction is that the assertion logic evaluates the final state resulting from the transaction, rather than just the initial parameters. If the outcome deviates from the asserted conditions, the transaction fails safely, preventing unintended consequences.

A key design principle emphasizes that the source of the assertion rule is as important as the check itself. A compromised frontend could, theoretically, craft a malicious assertion that permits an attack. Therefore, a useful rule must originate from independently approved user intent (e.g., a rule explicitly configured by the user), a standing account policy (e.g., a smart wallet’s pre-programmed safety checks), or robust protocol logic that cannot be tampered with by a compromised component.

EIP-7906: A Concrete Proposal for Implementation

The Ethereum community is actively exploring concrete proposals to implement native transaction assertions, with EIP-7906 (Transaction Assertions via State Diff Opcode) emerging as a leading candidate. EIP-7906 builds upon the "frame transactions" concept introduced in EIP-8141.

Frame Transactions (EIP-8141): Scheduled for inclusion in a future Ethereum upgrade tentatively named "Hegotác," EIP-8141 defines a new transaction type that encapsulates an ordered sequence of validation and action steps. This structured approach provides a flexible framework for more complex transaction logic.

EIP-7906’s Contribution: EIP-7906 extends EIP-8141 by adding a special, read-only POST_TX frame that executes at the very end of the transaction’s lifecycle. This POST_TX frame is specifically designed to check the transaction’s outcome against defined assertions. EIP-7906 has advanced to "Considered for Inclusion" but awaits final confirmation for an upcoming upgrade.

Information Exposed: EIP-7906 proposes exposing both state changes and events to the POST_TX frame. State changes are presented as net differences: native ETH balances, storage slot values (showing initial and final values), newly deployed contracts, and their code hashes. Crucially, if a storage slot is written to multiple times but ultimately reverts to its original value, it will not appear in the state diff, reflecting only the net changes.

New EVM Opcodes: To facilitate access to this outcome data, EIP-7906 introduces three new EVM instructions (opcodes):

1. TXTRACE: This opcode allows assertion code to enumerate through the net state changes and emitted events, providing a high-level overview of what transpired.
2. TXDIFF: For more granular inspection, TXDIFF enables retrieval of the starting and final values for specific addresses and storage slots.
3. EVENTDATACOPY: This opcode allows the assertion logic to copy the data of a specific event into memory for detailed examination.

Execution Context: These new opcodes are strictly restricted to operate within the POST_TX frame. Furthermore, the POST_TX frame executes as a static call, meaning it cannot modify the blockchain state itself. This read-only constraint is vital for security, ensuring that the assertion logic cannot inadvertently (or maliciously) alter the outcome it is meant to verify. If an assertion fails, 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 prevents attackers from submitting deliberately failing transactions to exploit block builders for free computation.

The Imperative of Mandatory Assertions

While EIP-7906 provides the technical foundation, its efficacy in preventing attacks hinges on a critical factor: the assertion must be required. The current EIP design does not inherently mandate the inclusion of an assertion, leaving a potential loophole for malicious actors or negligent builders to omit it.

To ensure comprehensive protection, the following measures are crucial:

• Wallet Enforcement: For user-initiated transactions, wallets must be programmed to ensure that every frame transaction they construct includes the necessary assertion. This rule could be dynamically generated based on a simulation run by the wallet or derived from a standing security policy predefined by the user for all their transactions (e.g., "never send more than X ETH," "only interact with whitelisted contracts").
• Protocol-Level Verification: Protocols and dApps that rely on robust security guarantees would need to verify that incoming calls originate from frame transactions containing a specific, correct assertion. Such protocols would reject ordinary transactions or frame transactions with missing or incorrect assertions. This approach would require callers and integrated applications to adopt compatible frame transaction types. A significant challenge here lies with already deployed, immutable smart contracts, which cannot be retroactively updated to incorporate this assertion-checking logic. This implies that the full benefits of mandatory assertions might initially be confined to new protocols or upgradeable contracts.

Broader Implications and Future Horizons

Beyond enhancing direct user security against blind signing and unexpected outcomes, native transaction assertions unlock a spectrum of transformative possibilities for the Ethereum ecosystem:

• Strengthening Delegation: Delegated authority, where an agent acts on behalf of a user or protocol, becomes significantly more secure. Currently, delegation relies on limiting what an agent can do (e.g., which contracts it can call, spending limits, duration of permissions). Assertions would add a powerful layer by constraining what the agent’s actions produce. This allows principals to define precise outcome parameters, ensuring delegated transactions adhere to both action and result-oriented policies.
• Protocol-Defined Safety Checks: Protocols could embed their own universal safety checks, requiring every caller utilizing a frame transaction to adhere to a specific outcome rule. This standardizes security and reduces the risk of unexpected interactions.
• Optimized Solver Execution: In complex transaction flows involving solvers (e.g., in intent-based architectures or MEV-protected swaps), assertions could allow the protocol to specify a guaranteed outcome (e.g., minimum received tokens) while granting the solver maximum flexibility in choosing the optimal execution path. This provides both safety and efficiency. However, it’s important to note that this guarantee would be limited to a single transaction on a single network, not extending to multi-chain routes.
• Workflow Finality Guarantees: Assertions could ensure that multi-step workflows reach their intended final state. This could include verifying that unused tokens are returned to the user, temporary token approvals are revoked, or specific contract states are achieved at the end of a complex sequence of operations. This provides greater certainty and reduces residual risks.

The introduction of native transaction assertions represents a fundamental upgrade to Ethereum’s security architecture, moving beyond merely verifying what a user signs to ensuring what a user gets. It is a crucial step towards making blockchain interactions more predictable, trustworthy, and ultimately, safer for a broader user base.

Call to Action: Shaping the Future of Ethereum Security

The design and implementation of native transaction assertions are ongoing efforts under the Ethereum Foundation’s ambitious Trillion Dollar Security initiative. The success of this endeavor hinges on collaborative input from the diverse ecosystem of wallet developers, dApp creators, and protocol teams who will ultimately integrate and benefit from these advancements.

The Ethereum Foundation extends an invitation to all interested parties to engage in this critical development. Feedback and insights are invaluable for exploring practical use cases, refining the technical specifications, and shaping the research roadmap. Those wishing to contribute can reach out via email at [email protected] or join the active EIP-7906 discussion thread on Ethereum Magicians forum.

Further information on risk controls and priority work streams can be found at trilliondollarsecurity.org, underscoring the foundation’s commitment to fortifying Ethereum’s defenses against evolving threats and ensuring its long-term security and viability as a global, decentralized platform.