EIP-7906 Transaction Assertions: How Post-Transaction Checks Work

A wallet can preview a swap and still lack a rule that says, “Do not commit if any other asset leaves my account.” EIP-7906 proposes that missing enforcement layer. It would let a frame transaction inspect its own final effects and discard the execution when those effects violate a programmed policy. That could strengthen crypto wallet security, but the proposal is not live on Ethereum mainnet and an incomplete assertion can create dangerous confidence.

What EIP-7906 transaction assertions are

Think of a transaction assertion as a quality-control gate at the end of an assembly line. The transaction performs its intended work first. Before the result is committed, a read-only checker compares the finished product with an allowed outcome. If the checker finds an unexpected transfer, approval, storage change, deployment, or event, it can reject the execution result.

The draft adds a POST_TX mode to EIP-8141 Frame Transactions. A POST_TX frame sits at the trailing end of the frame list and observes the transaction after the execution frames have run. It cannot modify state. If it reverts or halts, the transaction receives a failed receipt and the execution body is rolled back, while the gas payer still pays for work already performed.

That last detail matters. If a failed assertion also erased gas payment, an attacker could consume block resources and deliberately fail the final check for free. EIP-7906 instead treats assertion failure like an application-level revert: the protected execution does not persist, but network work is still paid for.

How the post-transaction check works

The proposal introduces three EVM instructions for assertion logic.

TXTRACE: enumerate the outcome

TXTRACE exposes the transaction's net state difference. An assertion can enumerate addresses with balance changes, changed storage slots, newly deployed contracts, and emitted events. “Net” is important: if a storage value changes and then returns to its starting value, the final diff does not show an outstanding change.

This is useful for broad policies such as:

• only these two token balances may change;
• no new contract may be deployed;
• the transaction must emit an expected event; or
• no unrecognized address may receive ETH.

TXDIFF: inspect a known account or slot

TXDIFF provides keyed lookup. Instead of scanning every changed item, an assertion can ask for the before-and-after balance, code hash, or storage value associated with a particular address and slot. It can also inspect per-address changes and events.

The draft includes account-change flags that summarize whether an account's nonce, balance, storage, or code hash changed. A “shield” policy could require those flags to remain zero for an account that should not be touched.

EVENTDATACOPY: read event data

Events can contain variable-length non-indexed data that does not fit in one EVM stack word. EVENTDATACOPY lets assertion code copy that data into memory for inspection. Together with event topics exposed through the other instructions, it can support checks around transfers, approvals, and application-specific receipts.

The authoritative draft defines the exact parameter tables and ordering rules. Builders should follow the live EIP-7906 specification, not a copied implementation guide, because gas costs and parts of the design remain unsettled. The Foundation's Hegotá review also notes a proposed narrowing that could remove arbitrary storage reads and focus assertions on emitted events and block-access-list-touched slots, so today's lookup surface is not final.

Assertions vs transaction simulation

Simulation and assertions answer related but different questions.

Layer	When it runs	What it provides	Main limitation
Wallet simulation	Before signing or broadcast	A preview against selected chain state	Live state, routing, or interpretation can differ
Transaction assertion	During the proposed frame transaction	An onchain condition over the transaction's actual effects	The policy may omit a harmful effect or fail technically

A crypto transaction simulation is like rehearsing a route before a trip. An assertion is like installing a barrier that opens only when the car arrives at an allowed destination. The preview helps you understand intent; the assertion aims to enforce a boundary during execution.

They are complementary. A wallet still needs to explain the request before you sign, and it may use simulation to construct a suitable policy. The assertion then needs to cover the effects that actually matter. Neither layer proves that a token has value, a trade is fair, or a protocol is honest.

What transaction assertions could protect

The Ethereum Foundation's September 2026 Hegotá EIP tier list describes EIP-7906 as a Frames extension that can prevent wallet drains and classes of MEV extraction. Practical policy patterns could include:

• Maximum outflow: reject if the account loses more ETH or tokens than the displayed limit.
• No hidden approval: reject an unexpected allowance or approval event.
• Minimum received amount: require the intended asset balance to increase by at least a stated quantity.
• Allowed-contract list: permit changes only at contracts required for the action.
• Protected account shield: require no balance, storage, nonce, or code change at another account.
• Expected event: require a known contract to emit a specific receipt or settlement signal.

These examples describe possible policies, not universal guarantees. Token accounting is not perfectly uniform, application state may be encoded in custom ways, and a sophisticated action can touch more contracts than a simple allowlist anticipates.

The Foundation's broader protocol priorities update groups EIP-7906 with account-hardening work around Frame Transactions. It also shows why status language matters: Ethereum proposals move through research, EIP, prototype, devnet, fork-inclusion stages, and only then mainnet. A promising devnet result is not a feature users can activate today.

Risks and limits

Transaction assertions move some security from “show the user a warning” to “enforce a machine-readable invariant.” That is valuable only when the invariant is correct.

Incomplete policies: A checker may verify one token outflow while overlooking an NFT, a native-asset transfer, a new operator permission, or application-specific storage. The EIP explicitly warns that an insufficiently restrictive assertion can be no better than having none.

Missing enforcement: A smart account must require its expected POST_TX frame. If validation can approve a transaction without that frame, a malicious request may bypass the check entirely.

Mutable checker code: The draft warns that the expected assertion target should be immutable. If untrusted execution can upgrade the checker before POST_TX runs, the transaction may weaken the very rule meant to protect it.

Gas exhaustion: A transaction can produce many changes or events. An assertion that tries to enumerate everything can run out of gas. The design provides narrower per-address and per-topic views, but implementations still need safe limits and failure handling.

Validation-prefix effects: A failed POST_TX frame rolls back the execution body, not the validation prefix. Gas payment and permitted setup work remain. Wallet software must keep untrusted dApp behavior out of that prefix.

Draft coupling: EIP-7906 depends on EIP-8141 and EIP-2929. Changes to Frames, opcode assignments, gas accounting, or Hegotá scope can change how assertions work or whether they ship.

A practical review checklist

If transaction assertions reach production wallets, ask these questions before relying on them:

1. What exact effects are bounded? List assets, accounts, contracts, storage, approvals, and events—not just a green “protected” badge.
2. What remains allowed? A maximum spend policy may still allow any recipient unless the recipient is separately constrained.
3. Is the assertion mandatory? Confirm the account's validation logic cannot approve a request without the expected immutable POST_TX checker.
4. What happens on failure? Expect the execution body to revert, a failed receipt to remain, and gas still to be charged.
5. How is complexity bounded? Review entry-count limits, gas stipends, and out-of-gas behavior.
6. Which specification version is implemented? Draft opcodes and semantics can change.
7. Can you still understand the transaction? Assertions complement clear signing; they do not justify approving an unreadable request.

Frequently asked questions

Is EIP-7906 live on Ethereum mainnet?

No. As of September 26, 2026, its official EIP page labels it Draft. The Ethereum Foundation graded it A tier for Hegotá and reported public-devnet work, but those milestones do not equal activation.

Does a failed assertion make the whole transaction free?

No. The proposed execution effects are rolled back, but the transaction remains valid with a failed receipt and the payer is charged for gas. This prevents free resource consumption through deliberate assertion failure.

Can EIP-7906 replace wallet simulation?

No. Simulation helps a user and wallet understand a proposed action before signing. An assertion enforces selected conditions during a Frame Transaction. Good wallet security can use both.

Can an assertion stop every wallet drainer?

No. It can reject effects covered by a correctly enforced policy. A missing, bypassable, outdated, or incomplete policy may fail to catch a harmful action.

Does EIP-7906 work with ordinary EIP-1559 transactions?

The current draft says its new instructions are valid only inside the proposed POST_TX mode of an EIP-8141 Frame Transaction. They are not available to legacy or ordinary EIP-1559 transactions.

The bottom line

EIP-7906 proposes a useful shift: wallets could enforce limits on what a transaction actually changes, not merely describe what they expect it to do. TXTRACE, TXDIFF, and EVENTDATACOPY would give a trailing read-only POST_TX frame the information needed to accept or reject the outcome.

The design is still a draft, its protection is only as complete as the assertion, and failed checks still cost gas. Follow the live EIP and official fork announcements rather than promotional claims. This article is educational, not financial advice (NFA). Crypto transactions and smart contracts can cause irreversible loss; use only funds you can afford to lose and do your own research (DYOR).