Ethereum Foundation outlines native checks for transaction outcomes

The Ethereum Foundation has put native transaction assertions on its security research agenda, outlining a way for Ethereum transactions to carry enforceable rules about their final onchain result. The Access Cluster published the design overview on October 5, presenting draft EIP-7906 as one possible implementation rather than an approved network change.

The distinction matters because a valid signature proves authorization, not that execution will produce the economic result a signer expected. Contract code, chain state and transaction ordering can change what happens between signing and inclusion. The proposed mechanism would let a wallet or application define an acceptable outcome and have Ethereum discard the transaction’s execution effects if that rule fails.

From signed request to checked result

Current protections address different parts of the problem. Clear signing can explain the call a user is authorizing, while simulation can estimate effects against a chosen state. Neither guarantees that the transaction included in a block will encounter identical code and conditions.

Native assertions would run read-only logic after the transaction’s actions. That logic could inspect net changes to ether balances, contract storage and deployed code, as well as emitted events. A rule might require a minimum amount received, prohibit a new token approval, cap spending or verify that an account’s control logic remains unchanged.

The proposal does not make a transaction safe merely because an assertion exists. The rule must come from a source independent of any compromised interface or transaction builder. A malicious frontend could otherwise attach a permissive assertion that allows the same unwanted result.

What EIP-7906 would add

EIP-7906 is a draft Core proposal created in February 2025 and highlighted by the Foundation’s October 5 research post. It depends on the separate frame-transaction design in EIP-8141.

Under the draft, a read-only POST_TX frame would run after the transaction’s action frames. Three proposed EVM instructions would expose the result: TXTRACE would enumerate net state changes and events, TXDIFF would retrieve specified starting and final values, and EVENTDATACOPY would copy event data for inspection.

If the assertion fails, the execution body would revert. The transaction would still remain in the block with a failed status, and the gas payer would remain charged for consumed gas. That limitation is intentional: allowing a failing post-transaction check to erase the gas bill could give attackers a way to consume block-building resources without paying.

The design observes net differences, not every intermediate write. If a storage slot changes repeatedly but finishes at its starting value, it would not appear as changed. The draft also warns that incomplete assertions can create false confidence and that checks which enumerate large state or event sets may exhaust their allotted gas.

Adoption is neither automatic nor confirmed

EIP-7906 would be optional under the current design. A wallet would need to include the appropriate assertion, while a protocol seeking mandatory protection would need to reject calls that omit or alter its required rule. Existing immutable contracts could not simply add that enforcement path.

The Foundation also says the guarantee would apply within one transaction on one network. It would not, by itself, secure a workflow spanning multiple chains. Wallet support, application integration and the underlying frame-transaction dependency would all be necessary before users could rely on the mechanism.

As of Coinburn’s October 6 publication window, EIP-7906 remained a draft and was not confirmed for an Ethereum upgrade. The fresh development is the Foundation’s public research push and request for wallet and protocol feedback—not activation, adoption or proof that the proposal would have prevented every cited loss. The next verifiable milestones are changes to the draft, client implementations, test results and a protocol-governance decision on inclusion.