As the decentralized finance ecosystem scales toward securing unprecedented volumes of global economic value, the Ethereum Foundation’s Trillion Dollar Security initiative has spotlighted critical user experience risks that continue to threaten everyday participants. In its latest ongoing security research, the initiative has identified blind signing and transaction uncertainty as fundamental vectors for user asset loss. To address these vulnerabilities head-on, developers and researchers are exploring the implementation of native transaction assertions alongside Clear Signing standards. This next-generation protective layer is designed to enforce a transaction’s final economic and structural outcome, ensuring that users get precisely what they bargained for—or nothing at all.
This latest focus sheds light on why a cryptographically valid signature does not inherently guarantee the transaction result a user actually desires. By introducing native transaction assertions, the Ethereum ecosystem hopes to protect participants at the exact boundary where today’s conventional security defenses fall short. The ongoing design choices behind this paradigm shift include proposals like EIP-7906, which introduces transaction assertions via a state diff opcode as one highly promising technical pathway.
Two Ways a Signed Transaction Can Go Wrong
The core security problem stems from the fundamental architecture of Ethereum itself. The Ethereum Virtual Machine (EVM) executes instructions precisely as they are authorized, operating without subjective judgment regarding whether the eventual result matches the user’s real-world intent. While a digital signature securely commits a user to a specific request, the ultimate outcome depends heavily on the surrounding contract code and blockchain state encountered during execution. Over the history of the network, participants have suffered severe financial losses either because they approved a request that fundamentally differed from what they believed they were signing, or because an intended request still produced an unwanted, detrimental outcome due to market conditions or malicious interference.
The first major pitfall is an intent mismatch, a dangerous scenario prominently demonstrated in high-profile security breaches such as the Bybit incident and the BadgerDAO attack. In both of these events, compromised front-end interfaces covertly supplied signing requests that deviated entirely from the actions users thought they were approving. During the Bybit incident, unsuspecting signers authorized a transaction that replaced their Safe’s underlying implementation contract with a malicious one. Similarly, in the BadgerDAO attack, users unwittingly granted external attackers broad permissions to drain their tokens.
The second major pitfall is an outcome mismatch. In these scenarios, the signer authorizes the exact request presented to them by the interface, but execution limits or shifting network state allow a result that directly violates their economic goals or standing safety parameters. A textbook example of this occurred during a massive collateral swap involving Aave and CoW Swap. A user attempted to execute an enormous swap trading roughly $50.4 million worth of aEthUSDT for aEthAAVE. Because AAVE liquidity was vastly too thin to absorb a trade of that magnitude in a single execution path, 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 viable. Although the user interface displayed a stark 99.9 percent price impact warning and explicitly required confirmation that the entire principal could be lost, the user signed the transaction regardless, ultimately receiving tokens valued at a mere $36,000.
In all three of these historical scenarios, a vital defensive element was entirely absent: a trusted, tamper-proof rule governing the resulting state, defined completely independently of the transaction builder and strictly enforced directly by the execution environment. Had a robust rule been in place during the Bybit breach, it would have mandated that the approved Safe implementation contract remain completely unmodified. For a BadgerDAO user, a protective rule would have restricted new token approvals exclusively to officially published and verified Badger contracts. In the Aave instance, a predefined rule would have enforced a strict minimum acceptable output calculated independently of the quotes displayed by the Aave interface, requiring the underlying solver-based flow or CoW settlement protocol to respect that absolute boundary. Historically, however, Ethereum has lacked a generalized mechanism enabling onchain code to inspect the full, holistic set of net state changes and emitted events produced by a single transaction before it finalizes.
What a Signature Does Not Control
When a user signs a transaction on Ethereum, their cryptographic commitment applies strictly to the requested action, specifying parameters such as the target contract, transferred value, and calldata payload. However, the EVM executes this call against the exact contract code and blockchain state present at the precise moment the transaction is included in a block—conditions that may have altered dramatically since the moment the user signed. Consequently, the resulting net balance modifications, storage updates, and emitted events can diverge wildly from initial expectations.
The target contract itself, or any auxiliary contracts it calls during execution, may rely on proxy patterns whose underlying implementation logic changes right before execution. This means the actual code running onchain can differ entirely from what the user inspected beforehand. Furthermore, transaction ordering and adversarial manipulation can alter the precise state encountered by a call. For instance, a classic sandwich attack can manipulate a decentralized exchange liquidity pool’s pricing immediately before a user’s swap executes, altering their financial return without ever modifying the bytes of their signed transaction.
Where Today’s Defenses Stop
The Ethereum ecosystem has progressively introduced several valuable defensive layers to mitigate these risks. One prominent standard is Clear Signing, which translates raw calldata into human-readable details so users can understand what an action requests. However, Clear Signing ultimately relies on accurate decoding mechanisms and assumes the signer possesses the attentiveness to recognize when a presented action deviates from their actual intent.
Another common defense is transaction simulation, which predicts the downstream effects of a transaction using a snapshot of the current chain state. Because chain state is fluid and can change before block inclusion, the transaction that eventually gets signed can still diverge from what was originally simulated. A stark illustration of this vulnerability occurred during the Radiant Capital exploit, where both the wallet interface and the simulation accurately displayed the intended transaction, but local malware on the signers’ machines covertly substituted a malicious payload at the exact moment of signing.
Contract-level checks and wallet security guards also attempt to enforce safety rules during EVM execution. For example, Uniswap automatically reverts a token swap if the final output falls below a pre-specified amountOutMinimum parameter. Similarly, Safe accounts utilize a checkAfterExecution hook, enabling a designated security guard to inspect the account’s state after transaction execution and automatically revert any transaction that violates configuration policies or owner constraints.
Nevertheless, both of these approaches require developers to choose which specific state variables to check in advance. To read the storage of another contract, they are entirely dependent on the specific viewing functions that contract exposes. While checking a token’s balanceOf function is straightforward, an arbitrary proxy contract is under no obligation to expose its implementation address through a public function. Without a standardized interface, a security guard cannot read an implementation storage slot directly. Crucially, these existing checks remain fundamentally incapable of inspecting a transaction’s comprehensive set of net state changes. While a security guard can verify that a specific token balance remains intact, it cannot ask the EVM what else changed across the broader state trie, leaving unforeseen and unmonitored side effects entirely unchecked.
How Native Transaction Assertions Work
Native transaction assertions seek to bridge this safety gap by allowing onchain code to inspect the full set of net state changes immediately after a transaction’s primary actions have successfully executed. Utilizing read-only logic, an assertion compares starting values and final outcomes against a predefined rule. If the rule is violated, the entire transaction’s actions are automatically reverted.
These compliance rules are bundled directly into the transaction itself and are cryptographically signed alongside its primary actions. A rule can comprehensively govern net changes across native balances, storage variables, and contract code, while also monitoring newly deployed contracts and emitted logs. It can enforce strict economic bounds—such as requiring a minimum token output, capping maximum spending, blocking unauthorized token approvals, preserving an account’s foundational control logic, or restricting execution to a strictly whitelisted set of state alterations.
Importantly, the origin of the validation rule is just as critical as the verification mechanism itself. If a compromised front-end interface is allowed to write its own assertion, it could simply craft a rule that explicitly permits the attack. Therefore, a truly useful rule must originate from an independently verified user intent, a standing account security policy, or protocol-level logic that a compromised interface component cannot manipulate.
Three Design Choices
Designing native transaction assertions at the protocol layer involves navigating complex architectural decisions regarding what precise information the EVM should expose, how assertion code can access that data, and where the corresponding opcodes are permitted to run. Core developers must determine whether the exposed information should encompass net state changes, emitted events, or both. Access mechanisms might involve enumerating entries sequentially, looking up specific address values directly, or copying the full set of structural changes into memory. Furthermore, protocol architects must decide whether the new opcodes should be restricted exclusively to specialized transaction types and execution phases, or made universally available throughout the EVM.
EIP-7906 as a Possible Solution
A prominent technical proposal addressing these challenges is EIP-7906, which builds directly upon the frame transaction architecture defined in EIP-8141. Under this framework, a frame transaction contains an ordered sequence of distinct validation and action steps. EIP-7906 introduces a specialized, read-only POST_TX frame appended to the very end of the execution sequence specifically to evaluate the transaction’s ultimate outcome. While EIP-8141 has advanced toward inclusion in upcoming network upgrades, EIP-7906 has progressed to being actively considered for inclusion, though it is not yet finalized.
The EIP-7906 design exposes both net state changes and emitted events to the execution environment. State changes are reported as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their corresponding code hashes. Under this accounting model, a storage slot that is written to multiple times during a transaction is summarized as a single entry reflecting its initial starting value and final ending value; if a slot concludes with its original value intact, it does not appear in the trace at all.
Three new EVM instructions provide programmatic access to this tracking data. The TXTRACE opcode enumerates net state changes and logged events, the TXDIFF opcode retrieves starting and final values for specific addresses and storage slots, and the EVENTDATACOPY opcode copies specific event data directly into memory. These opcodes function exclusively inside the designated POST_TX frame, which executes as a static call at the conclusion of the transaction. This ensures that the assertion can inspect the final outcome without altering state variables. If the defined rule is violated, the entire execution body reverts, but the transaction remains permanently recorded in the block with a failed status, and the gas payer is appropriately charged for the consumed computation. This economic deterrent prevents malicious actors from forcing block builders to process deliberately failing transactions for free.
The Assertion Has to Be Required
A key characteristic of EIP-7906 is that it does not inherently force every transaction on the network to include an assertion, meaning a transaction builder could technically omit it. To achieve meaningful security, user wallets must ensure that every frame transaction they construct includes the necessary protective assertion, drawing the rule from a local simulation or a standing user security policy.
Similarly, protocol-level smart contracts must actively verify that incoming calls originate from frame transactions containing the exact required assertions, rejecting ordinary transactions and improperly guarded frame transactions alike. Consequently, callers and ecosystem integrations must adopt compatible frame transactions, noting that already-deployed immutable contracts cannot retroactively add this verification check.
Where Transaction Assertions Could Help
Beyond fortifying basic user and protocol security, native transaction assertions unlock powerful capabilities across various emerging use cases. For instance, they can significantly strengthen account delegation and automated agent workflows. When users authorize autonomous agents to act on their behalf, they typically need to restrict which contracts the agent can interact with, how much capital it can expend, and how long its permissions persist. Assertions can introduce strict rules governing the economic outcome of each transaction, allowing users to constrain both the actions an agent takes and the financial results those actions produce.
Protocols can also define standardized security rules, requiring uniform safety checks for every user interacting through frame transactions. In solver-based execution models, a protocol can specify the precise required outcome while granting solvers the freedom to determine the optimal routing path. Additionally, assertions can verify that complex multi-step workflows successfully reach their intended final state, ensuring that residual tokens are properly returned to the user and any temporary token approvals are cleanly revoked before final settlement.
Help Shape the Design
Native transaction assertions remain an active area of research within the Ethereum Foundation’s Trillion Dollar Security initiative, and developers are actively seeking feedback from the wallet and protocol teams who will ultimately implement them. Stakeholders are encouraged to explore use cases, contribute to ongoing research, or participate directly in the broader community discussions surrounding EIP-7906 to help refine the design of Ethereum’s next-generation security architecture.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
