The Ethereum Foundation is exploring native transaction assertions as a protocol-level mechanism for letting users specify what a transaction is allowed to accomplish, rather than relying only on what they authorize before execution. In an official October 5 research post, the Foundation said assertions could inspect a transaction’s final outcome and roll back its execution if predefined conditions are violated, extending Ethereum’s security work beyond conventional signing interfaces.
The research addresses a limitation behind blind signing and transaction uncertainty. A valid signature confirms that a user authorized a request, but the final result can still depend on contract logic and blockchain state when execution occurs. Signing a transaction does not inherently guarantee the economic or state outcome the user intended. Clear Signing can improve visibility before approval, but it cannot enforce what ultimately changes onchain.
EIP-7906 Adds Post-Execution Checks
The main implementation under consideration is EIP-7906, a Draft Core proposal titled Transaction Assertions via State Diff Opcode. It builds on EIP-8141 Frame Transactions, which divides validation, execution and gas payment into programmable frames. EIP-7906 introduces a read-only POST_TX frame that runs after the transaction body. This final frame can examine net state changes and events before allowing the transaction’s effects to stand.
Three proposed EVM instructions provide that visibility. TXTRACE enumerates net changes and emitted events, TXDIFF retrieves before-and-after values for specific balances, code hashes or storage slots, and EVENTDATACOPY exposes event data. A wallet could therefore require that a swap produces at least a specified token amount, that no unexpected approval is created or that account-control logic remains unchanged. If an assertion fails, the transaction’s execution body is reverted, although the failed transaction remains recorded and its gas is still charged.
The proposal depends on EIP-8141, which has already moved into Ethereum’s Hegotá roadmap. Frame Transactions are scheduled as a Hegotá execution-layer headliner, giving Ethereum a native account-abstraction structure for programmable validation and payment. That architecture is also being explored for cheaper post-quantum cryptographic verification through EIP-8288. Transaction assertions would extend that framework from account mechanics into explicit control over transaction outcomes.
Assertions Still Depend on Trusted Intent
Native assertions do not automatically eliminate malicious transactions. The Foundation notes that a compromised frontend could generate an assertion that deliberately permits the same harmful behavior as the transaction itself. The protection is only meaningful when the rule originates from an independently trusted wallet policy, user instruction or protocol requirement. That makes assertion generation and verification part of the security boundary rather than a complete replacement for secure interfaces.
The design could also extend beyond ordinary wallet transactions. Protocols could require callers to satisfy specific post-execution invariants, while solver-based systems could define the required final result without prescribing the route used to obtain it. Agents acting under delegated authority could similarly be constrained by both permitted actions and required outcomes. Assertions could therefore complement broader wallet-security efforts, including the Foundation’s work with SEAL against wallet-drainer attacks, by preventing some authorized transactions from producing unauthorized effects.
EIP-7906 is not yet part of a finalized Ethereum fork. While EIP-8141 is scheduled for Hegotá, the Foundation says transaction assertions have only advanced to Considered for Inclusion, leaving specification changes, client implementation and testing ahead. The immediate development is therefore a protocol security design under active evaluation, not a protection currently available on Ethereum mainnet.