EIP-7906 Transaction Assertions: Enforcing Outcomes After a Wallet Signs

The core problem: wallets sign instructions, but users care about outcomes

Most wallet security today is concentrated before execution.

The wallet shows a contract address.

It decodes a function call.

It estimates gas.

It may simulate token transfers.

It may warn that an approval is unlimited.

The user signs.

After signing, however, the transaction is still executed by contracts whose behavior can depend on complex and mutable state.

A swap router can call several other contracts.

A proxy can delegate to an implementation.

A hook can execute.

A callback can trigger nested logic.

An oracle can return a different price.

A token can implement unusual transfer behavior.

A malicious frontend can construct calldata that is technically valid but economically different from what the user thinks they approved.

Simulation helps, but simulation is a prediction.

The final transaction executes against the block state in which it lands.

EIP-7906 proposes an additional security layer: do not merely predict the result before signing. Attach constraints that inspect the actual transaction outcome and reject execution when those constraints are violated.

What EIP-7906 actually introduces

EIP-7906 is titled Transaction Assertions via State Diff Opcode.

The proposal adds EVM-level introspection mechanisms that can observe the transaction's net effects.

The main components are:

The proposal is therefore not just a wallet UI feature.

It changes what execution-time code can observe and enforce.

Transaction assertions are not persistent permissions

The terminology around smart-wallet standards can easily create confusion.

EIP-7906 assertions are not delegated authority.

They are not wallet connection grants.

They are not ERC-20 approvals.

They are not Permit2 allowances.

They are not reusable session keys.

They do not grant a DApp permission to execute future transactions.

An assertion is attached to the transaction being evaluated.

Its purpose is to constrain that transaction's acceptable outcome.

This distinction changes how expiry and revocation should be discussed.

EIP-7906 itself does not define a reusable permission that needs later revocation.

The assertion belongs to a particular transaction structure.

Once that transaction executes or fails, there is no independent EIP-7906 authorization left behind.

Why EIP-7906 depends on EIP-8141 frame transactions

EIP-8141 proposes a transaction format composed of ordered frames.

Different frame modes can perform validation, sender execution, payment logic, and other parts of the transaction lifecycle.

EIP-7906 adds a new frame mode named POST_TX.

POST_TX frames must form a contiguous suffix at the end of the frame list.

Once the first POST_TX frame appears, every later frame must also be POST_TX.

This placement matters because assertions need to inspect the final execution outcome.

If ordinary execution could occur after an assertion, the transaction could satisfy the assertion and then perform additional harmful state changes.

Trailing-only placement prevents that ordering attack.

What happens inside a POST_TX frame

A POST_TX frame executes as a static call.

That means assertion code is not supposed to mutate ordinary state while it inspects the transaction outcome.

The frame can read the transaction diff and decide whether the outcome is acceptable.

If the assertion succeeds, execution remains committed.

If the POST_TX frame reverts or halts exceptionally, the transaction's execution body is reverted.

The transaction itself is not considered protocol-invalid merely because the assertion fails.

It can still be included in a block and produce a receipt with failed status.

This difference is crucial.

The payer still pays gas

The network already performed computation.

If assertion failure refunded every cost and removed the transaction completely, an attacker could deliberately execute expensive transactions and fail the final assertion for free.

The design therefore preserves gas payment.

The validation prefix is not reverted

State changes belonging to the EIP-8141 validation prefix remain committed.

This can include gas-payment approval and account creation performed in the validation stage.

The user operation is reverted

Untrusted execution placed in normal execution frames is rolled back when the POST_TX assertion fails.

This architecture creates a security boundary between trusted transaction validation and the user operation being outcome-constrained.

EIP-7906 transaction assertion surface map

TXTRACE: enumerating what changed

TXTRACE exposes the transaction's net outcome through indexed parameters.

Assertion logic can determine how many account balances changed.

It can determine how many storage slots changed.

It can identify contracts deployed during the transaction.

It can enumerate events in emission order.

It can inspect the gas payer and provisional gas pre-charge.

TXTRACE observes net differences, not every intermediate write

The state-diff semantics are important when designing assertions.

The "before" value represents the transaction prestate.

The "after" value represents state as observed when TXTRACE runs in the POST_TX phase.

Intermediate writes are collapsed.

If a contract changes storage slot X from 1 to 2 and later restores it to 1 before the assertion runs, the final net state for that slot is unchanged.

The diff does not expose those temporary intermediate values as separate entries.

This is good for final-state assertions

A wallet may care only that a protected storage slot ended exactly where it started.

It is not a complete execution trace

If temporary state changes themselves are dangerous, the final diff may not expose them.

An assertion system should not be confused with a full instruction-by-instruction execution tracer.

Events are different

Events are not collapsed into a net state value.

They remain individually observable in their emission order.

TXDIFF: targeted lookup without scanning everything

TXTRACE is useful when an assertion wants to enumerate the complete outcome.

Many security policies need only a small number of targeted checks.

For those cases EIP-7906 introduces TXDIFF.

TXDIFF can query a specific address or storage slot directly.

It can return:

• Storage slot value before execution.
• Storage slot value after execution.
• Account balance before execution.
• Account balance after execution.
• Code hash before execution.
• Code hash after execution.
• Count of changed storage slots for one address.
• Per-address mappings into global changed-slot entries.
• Count of events emitted by one address.
• Per-address mappings into global event entries.
• A compact account-change bitmask.

Direct lookup matters because unrelated contracts can produce large numbers of logs or state changes.

An assertion protecting one token contract should not need to scan every event emitted by every other contract if TXDIFF can narrow the work to that token.

The account-change flags enable a powerful shield assertion

One of the proposal's most practical features is a compact bitmask summarizing whether an account changed.

The flags represent net differences in:

If the flags value is zero, the account's internal state is identical to its prestate across those categories.

This makes a simple "shield" possible:

This can be useful when a transaction interacts with a complicated DApp but the wallet wants to guarantee that a particular vault, smart account, token, or unrelated asset contract remained untouched.

Events are intentionally excluded from this bitmask because emitting a log does not itself change account state.

An assertion that also requires silence can separately check that the address emitted zero events.

The account-change flags expose nonce change without exposing the nonce value

EIP-7906 deliberately exposes whether the nonce changed in the account-change flags.

It does not expose the actual nonce value through TXTRACE or TXDIFF.

This distinction is useful for shield assertions.

An assertion can tell that the protected account's internal state is no longer identical without requiring the opcode to expose every account field directly.

Events become enforceable outcome evidence

Wallets already use logs when displaying transaction activity after execution.

EIP-7906 lets assertion code examine them inside transaction execution policy.

For each event, TXTRACE can expose the emitting address, number of topics, topic values, and non-indexed data length.

EVENTDATACOPY can copy the variable-length event data into memory for inspection.

Token transfer assertions

An assertion can require a Transfer event from a specific token with expected sender, recipient, and token identifier or amount semantics.

Approval assertions

A wallet can reject an interaction if an unexpected Approval event appears.

Protocol-state confirmation

An assertion can require a particular protocol event to be emitted by the expected contract.

Events are not complete proof by themselves

Contracts can emit misleading events.

When value or ownership matters, event assertions should often be combined with direct balance or storage assertions.

Per-address event views reduce event-padding attacks

A naive assertion could enumerate every event in the transaction looking for events from one contract.

A malicious DApp could intentionally emit a large number of cheap unrelated logs.

That increases the assertion's gas cost.

If the assertion runs out of gas before finishing, it has not actually verified the transaction.

TXDIFF's per-address event views make the assertion cost proportional to the activity of the contract being inspected rather than the entire transaction's log volume.

This is a subtle but important anti-DoS property.

Why gas pre-charge needs special treatment

Balance-difference assertions can be misleading if gas payment is not accounted for.

In the EIP-8141 model, the gas payer's balance already reflects the gas pre-charge when the transaction diff is inspected.

The gas payer can also be different from the sender if a separate payer or paymaster is used.

EIP-7906 therefore exposes both the gas payer address and gas pre-charge.

An assertion that wants to measure pure application-level ETH transfer can subtract the gas pre-charge from the payer's balance delta.

The proposal notes that this pre-charge is provisional because unused gas can later be refunded.

Wallet designers should therefore understand exactly which balance condition they are enforcing rather than displaying a simplistic "maximum ETH lost" promise that accidentally includes or excludes fee behavior incorrectly.

What useful transaction assertions could look like

The EIP provides infrastructure rather than one mandatory policy language.

Wallets and assertion providers can build different constraints.

Maximum ETH outflow

A wallet can require that the user's application-level ETH balance decrease by no more than 0.5 ETH, excluding the known gas pre-charge.

Minimum token received

A swap assertion can verify the relevant token balance or storage slot and require at least the user's chosen minimum output.

No new token approval

A wallet can reject an interaction if a particular token's allowance storage changes unexpectedly or if an approval event indicates a spender the user did not authorize.

Protected account untouched

A shield assertion can require account_change_flags to remain zero for a cold-storage vault or another sensitive smart contract.

No code deployment

A transaction that is expected only to swap tokens can fail if a new contract is unexpectedly deployed.

Expected code hash remains unchanged

An assertion can check that a critical contract's code hash did not change during execution.

Only approved contracts changed storage

A stricter policy can enumerate state changes and reject the transaction if an unapproved address modified persistent storage.

Expected protocol event appears

A bridge or vault transaction can require specific contract events consistent with the intended operation.

Unexpected event does not appear

A wallet can reject if a token approval, ownership transfer, operator permission, or administrative event occurs unexpectedly.

Illustrative assertion logic

The exact opcode wrappers and production interface will depend on the implementation environment, but the security model can be illustrated with Solidity-like pseudocode.

function assertProtectedAccountUntouched(address protected) external view {
    uint256 flags = txdiffAccountChangeFlags(protected);

    require(
        flags == 0,
        "Protected account changed"
    );
}

function assertMaxEthOutflow(
    address user,
    uint256 maxOutflow
) external view {
    uint256 beforeBal = txdiffBalanceBefore(user);
    uint256 afterBal  = txdiffBalanceAfter(user);

    uint256 applicationOutflow = normalizeForGasPayer(
        user,
        beforeBal,
        afterBal
    );

    require(
        applicationOutflow <= maxOutflow,
        "ETH outflow exceeded"
    );
}

The important point is not the exact wrapper syntax.

The assertion reads the actual transaction outcome and reverts when the result falls outside the policy.

What the wallet should display before the user signs

Outcome assertions are useful only when users understand the protection they are receiving.

A vague badge saying "Protected transaction" can be dangerous because it can create a false sense of safety.

The wallet should not imply that one assertion protects against every possible transaction risk.

Assertions complement clear signing rather than replacing it

Before EIP-7906, wallet security relies heavily on helping users understand the transaction they are signing.

That remains necessary.

An assertion can constrain outcomes, but the wallet should still explain the intended action before signing.

TokenToolHub's Clear Signing in Crypto guide covers the pre-execution side of this problem: translating raw calldata, messages, approvals, and contract calls into human-readable consequences.

EIP-7906 potentially adds another question:

The largest risk is an assertion that checks too little

The EIP's security section emphasizes insufficiently restrictive assertions.

This deserves more attention than almost any other issue.

Suppose a wallet displays "Maximum loss: 1 ETH."

The assertion checks only the user's ETH balance.

The transaction instead grants unlimited USDC approval to an attacker.

The ETH condition passes.

The user still suffers a severe security failure later.

The assertion was technically correct.

The wallet's security claim was incomplete.

Assertions need threat-model coverage

A swap assertion might need to cover token outflow, minimum token inflow, approval changes, unexpected contract deployment, and potentially affected vault or account state.

"No ETH stolen" is not "transaction safe"

NFT approvals, ERC-20 approvals, ownership changes, contract upgrades, and protocol debt can occur without direct ETH loss.

Incomplete checks can be worse than no checks psychologically

Users may relax their normal skepticism because the wallet displays a protection indicator.

An assertion should therefore communicate its exact guarantee.

A wallet must prevent the DApp from dropping the assertion frame

EIP-7906 does not impose a protocol-wide rule that every frame transaction must include a POST_TX assertion.

This is one of the most important integration requirements.

If the wallet expects all of its transactions to be assertion-protected, the account's VERIFY logic must require the expected POST_TX frame.

Otherwise a malicious frontend can construct the dangerous transaction but simply omit the assertion.

The user may think their wallet always enforces outcome constraints while the signed transaction contains no protection.

Because POST_TX frames form a trailing suffix, validation logic can inspect the transaction structure and locate the required enforcer.

The assertion target should be immutable

The EIP's security considerations go further.

It warns that the expected POST_TX target should be immutable and non-upgradeable.

Why?

Imagine the VERIFY frame confirms that the transaction contains POST_TX target A.

During execution, the transaction upgrades contract A to malicious logic.

The same address still appears in the POST_TX frame.

But the assertion policy has changed.

The user believed the transaction would be checked by the original enforcer.

The transaction has replaced the checker before it runs.

Immutable assertion contracts eliminate this class of policy substitution.

A compromised frontend can attack assertion construction

A transaction assertion is only as useful as the policy the wallet actually signs.

A compromised DApp frontend can attempt several attacks.

Remove the assertion frame

This fails if smart-account validation explicitly requires the expected POST_TX frame.

Substitute a weaker assertion

The frontend can replace "minimum 1,000 USDC received" with "minimum 1 USDC received."

The wallet needs to render the effective assertion parameters clearly.

Substitute the assertion contract

The frontend can point to an attacker-controlled policy contract.

Account validation should bind to the expected enforcer where protection is mandatory.

Hide uncovered side effects

A frontend can emphasize one strong assertion while omitting that unlimited approval changes remain permitted.

The wallet needs its own understanding of the policy rather than trusting frontend labels.

Assertion gas exhaustion is a security failure, not a harmless inconvenience

An assertion that runs out of gas has not completed verification.

EIP-7906 therefore requires frameworks to treat assertion out-of-gas as an explicit assertion failure.

It must not be interpreted as "the check could not finish, so allow the transaction."

Global enumeration can become expensive

A transaction can produce a very large number of events.

Scanning them all consumes gas.

Unrelated event spam can target the assertion

A malicious contract can produce many logs merely to raise assertion cost.

Read total counts first

An assertion framework can inspect entry counts and reject or allocate gas according to bounded expectations.

Use per-address views when possible

If only one contract matters, TXDIFF can make cost depend on that contract's activity rather than the whole transaction.

Why validation-prefix behavior matters

When a POST_TX frame fails, the execution body is reverted but the validation prefix is not.

This means developers must be extremely careful about what they put in the validation prefix.

The wallet's trusted validation logic belongs there.

Untrusted DApp operations do not.

Gas payment remains committed

This is intentional to protect the network from free computation attacks.

Account deployment can remain committed

If account creation happened as part of the validation prefix, POST_TX failure does not necessarily erase that deployment.

Do not place arbitrary DApp side effects before the assertion-protected execution boundary

The EIP explicitly warns that wallets must not rely on POST_TX to reverse unsafe validation-prefix behavior.

Does EIP-7906 allow partial execution after assertion failure?

For the execution body protected by POST_TX, a failing assertion unconditionally causes that execution to revert.

The EIP is designed specifically so atomic-batch behavior cannot preserve only part of a prohibited outcome.

The failed POST_TX frame prevents the transaction from keeping the untrusted execution body merely because one earlier frame succeeded.

However, the validation prefix is intentionally outside this rollback boundary.

This is why the safest mental model is:

A failed assertion still produces an included failed transaction

Users should understand how this differs from a transaction that never enters a block.

If the POST_TX assertion fails, the transaction remains valid for block inclusion.

The receipt records failed status.

The gas payer is charged.

The execution body does not survive.

This can confuse users who expect "assertion prevented the transaction" to mean "no transaction and no fee."

A better description is:

Multiple POST_TX assertions can compose

EIP-7906 permits multiple POST_TX frames at the end of one frame transaction.

This supports independent policy modules.

A wallet could combine:

• A maximum ETH-outflow assertion.
• A no-new-approval assertion.
• A protected-vault shield.
• A minimum-token-received assertion.
• A code-deployment prohibition.

Each module can independently inspect the transaction result and fail the transaction if its own invariant is violated.

This modularity avoids forcing every security provider to cooperate inside one giant assertion contract.

It also creates a UX challenge.

The wallet should clearly explain the combined policy instead of showing five incomprehensible contract addresses.

What assertion scope means in EIP-7906

There is no generic "scope" field equivalent to a delegated-permission scope.

The scope is defined by the assertion program itself and by the transaction it is attached to.

An assertion can be broad.

For example, it can enumerate all changed addresses and require every change to match an allowlist.

An assertion can be narrow.

For example, it can check only that one USDC balance increased by at least 1,000 units.

The narrow assertion is cheaper and easier to reason about.

It also leaves more side effects unconstrained.

Scope therefore becomes a tradeoff between coverage, complexity, gas cost, and user comprehension.

Expiry and revocation are not native assertion concepts

Because an EIP-7906 assertion is transaction-local, there is no persistent permission that later needs to expire or be revoked.

The frame transaction itself has EIP-8141 transaction semantics, including chain and nonce behavior.

Applications can also include expiry logic in validation or application data.

But EIP-7906 does not define an assertion-expiration timestamp.

Nor does it define a revokeAssertion function.

If the wallet wants a different policy for a future transaction, it constructs that future transaction with a different assertion.

Assertions do not replace replay protection

A transaction assertion constrains outcomes.

Replay protection still belongs to the transaction and authorization layer.

EIP-8141 frame transactions contain a chain ID and sender nonce.

Those fields help ensure that the signed transaction cannot simply be replayed indefinitely as another transaction from the same account.

Assertions should not be used as a substitute for correct nonce or chain-domain design.

Chain scope comes from the transaction, not TXTRACE

EIP-7906 does not add a separate chainId parameter to each assertion.

The assertion executes inside a frame transaction whose outer payload contains chain ID.

A wallet should still communicate the network clearly.

The same assertion contract address can have different code or state on another chain.

Policy trust should therefore be evaluated in the correct chain context.

Outcome assertions can constrain approval risk, but approvals remain independent state

ERC-20 allowances remain one of the most persistent wallet risk surfaces.

EIP-7906 can help because an assertion can inspect relevant token storage changes or approval events and reject unexpected approval outcomes.

That does not mean allowances cease to exist.

A wallet can still intentionally approve a spender.

The approval can remain after the transaction succeeds.

TokenToolHub's Crypto Approval Risks guide explains the persistent authority created when a spender receives ERC-20 approval.

For Permit2-specific authority, the Permit2 and Allowances guide covers another layer of reusable token permissions that remains conceptually separate from EIP-7906 transaction assertions.

Assertions are stronger than simulation in one specific way

Simulation predicts.

An assertion enforces.

A wallet can simulate a swap and estimate that the user will receive 1,005 USDC.

The actual block state can change before inclusion.

Another transaction can move the price.

Liquidity can change.

An oracle can update.

A contract can execute a different branch.

If the signed transaction includes a minimum-output assertion of 1,000 USDC, the final result can be rejected when actual execution produces only 990 USDC.

That is an enforceable boundary rather than a prediction.

Simulation still matters

The wallet needs simulation to explain likely outcomes and estimate whether the transaction will satisfy its assertions.

Assertions are not omniscient

They enforce only what they check.

A perfect simulation plus incomplete assertion can still leave uncovered risks.

Wallet and smart-account builder checklist

Assertion-contract builder checklist

User checklist before signing an assertion-protected transaction

Hardware wallets and transaction assertions protect different layers

Hardware signing can protect the user's root signing credential from malware on the general-purpose computer.

A device such as Ledger can help isolate a key used by an assertion-aware smart account.

An air-gapped signer such as Keystone can similarly reduce direct exposure of the signing credential.

EIP-7906 addresses a different layer.

Hardware protects who signs.

Clear signing helps explain what is being signed.

Transaction assertions constrain what execution is allowed to produce.

These protections complement each other.

Independent transaction decoding still matters

Assertions can prevent some prohibited outcomes from surviving execution.

Users and researchers still need visibility into what a transaction attempted and what actually happened.

TokenToolHub's Transaction Decoder can help inspect contract targets, calldata, token movements, approvals, nested calls, traces, fees, execution errors, and post-transaction effects.

This becomes especially useful after an assertion failure.

The execution body may have reverted, but the transaction still consumed gas and produced a failed receipt.

Decoding can help answer why the assertion failed and whether the DApp attempted an unexpected action.

Worked EIP-7906 transaction assertion scenarios

Scenario 1: swap minimum output protection

A user intends to swap 1 ETH for at least 3,000 units of a stablecoin.

The DApp simulates an output of 3,040.

Before inclusion, price moves.

Actual execution would deliver only 2,960.

A POST_TX assertion checks the user's stablecoin state and requires at least 3,000 units of net inflow.

The assertion fails.

The swap execution is reverted.

The user still pays gas because the computation occurred.

Scenario 2: hidden unlimited approval

A malicious swap frontend constructs a transaction that performs the requested trade but also sets an unlimited token allowance to an attacker-controlled spender.

The wallet uses an assertion allowing expected swap storage changes but prohibiting unexpected allowance changes.

The approval changes storage in the token contract.

The assertion detects it and reverts the execution body.

Scenario 3: incomplete ETH-only assertion

A wallet promises that the user will not lose more than 0.1 ETH.

The assertion checks only ETH balance.

The transaction grants unlimited USDC approval.

ETH outflow stays below 0.1 ETH.

The assertion passes.

The transaction is still dangerous.

This is the false-confidence problem emphasized by the proposal.

Scenario 4: protected vault shield

A user interacts with a complex DeFi aggregator from a smart account that also controls a separate vault contract.

The wallet attaches a shield requiring the vault's account_change_flags to remain zero.

A malicious callback attempts to modify vault storage.

The flags become non-zero.

The POST_TX assertion rejects the entire execution body.

Scenario 5: unexpected contract deployment

A transaction is expected only to transfer tokens and update an AMM position.

A hidden branch deploys a helper contract through CREATE2.

TXTRACE exposes the newly deployed code.

A no-deployment assertion fails.

Scenario 6: event-padding attack

An assertion scans all transaction events looking for one approval event.

A malicious DApp emits thousands of unrelated logs before the assertion runs.

The assertion approaches its gas limit.

A more resilient design uses TXDIFF's per-address event view to inspect only the token contract's events.

Scenario 7: assertion out-of-gas

A transaction deliberately creates enough state-diff entries to exhaust the assertion's gas budget.

The framework treats the out-of-gas condition as assertion failure.

The execution body reverts instead of being accepted without verification.

Scenario 8: malicious frontend removes POST_TX

A smart-wallet user normally relies on an assertion provider.

A compromised frontend constructs a frame transaction without the required POST_TX frame.

If the account's VERIFY logic explicitly requires the enforcer, validation fails before unsafe execution can proceed.

If the account relies only on the frontend to add assertions, the protection can disappear silently.

Scenario 9: upgradeable assertion contract

The VERIFY frame checks that the final assertion targets contract A.

During execution, a malicious transaction upgrades contract A's implementation.

The POST_TX call still targets A, but the policy code is now different.

This is why the proposal recommends immutable non-upgradeable assertion targets for mandatory security enforcement.

Scenario 10: storage changed and restored

A contract temporarily writes sensitive slot X and later restores the original value before POST_TX.

The final diff shows no net change to X.

An assertion based only on net storage state cannot observe the intermediate write.

If temporary writes themselves matter, another security mechanism or contract-specific execution design is needed.

Scenario 11: sponsored gas confuses ETH accounting

The sender is not the gas payer.

A wallet naively interprets the sender's balance delta without checking payer information.

A correct assertion uses gas_payer_address and gas_pre_charge so gas accounting does not distort the application-level ETH-transfer rule.

Scenario 12: event says success but storage disagrees

A malicious token emits a Transfer event suggesting the user received 1,000 units while its actual balance storage does not increase accordingly.

An event-only assertion passes incorrectly.

A stronger assertion checks authoritative state alongside event evidence.

Scenario 13: multiple independent assertion providers

A wallet includes three POST_TX frames.

The first checks token outcome.

The second checks no unauthorized approvals.

The third ensures a protected account did not change.

All must succeed for execution to survive.

The modules do not need to be implemented by one provider.

Scenario 14: assertion detects code-hash mutation

A transaction interacts with a proxy administration path that unexpectedly changes a critical implementation address or code hash.

A targeted TXDIFF assertion notices that the protected code state changed and rejects the transaction.

Scenario 15: assertion fails but user still pays gas

A user signs a transaction with strong protection.

The DApp attempts an outcome outside policy.

The assertion succeeds at its security purpose by reverting execution.

The user sees a failed transaction and a gas charge.

This is expected behavior, not evidence that the assertion failed to protect them.

EIP-7906 security risk matrix

What to do after an assertion unexpectedly fails

An unexpected assertion failure is useful security evidence.

It should not be treated automatically as a harmless DApp glitch.

Assertions belong inside a layered wallet security model

No single wallet standard can protect every stage of an Ethereum interaction.

Key custody protects the signing credential.

Clear signing protects intent comprehension.

Simulation estimates probable execution.

EIP-7906 can constrain final execution outcomes.

Approval management limits persistent token authority.

Transaction decoding verifies what happened afterward.

TokenToolHub's Wallet Safety 101 provides the broader operational framework for account separation, phishing resistance, signing discipline, approval hygiene, and incident response.

The strongest wallet design combines these layers rather than assuming one mechanism makes all the others unnecessary.

Why outcome assertions could materially change wallet security

Most wallet warnings today are informational.

The wallet says a transaction might transfer a token.

The wallet says an allowance is unlimited.

The wallet says simulation predicts a certain output.

The user still signs an execution whose actual result is determined later.

Transaction assertions move some security guarantees from description to enforcement.

A wallet could say:

"This transaction cannot succeed if more than 0.25 ETH leaves your account."

"This transaction cannot succeed unless at least 5,000 USDC reaches your account."

"This transaction cannot succeed if this vault changes."

"This transaction cannot succeed if an unknown token approval is created."

Those statements are substantially stronger than predictions when the assertion implementation is complete, mandatory, immutable, and correctly scoped.

The challenge shifts from predicting execution to specifying invariants correctly.

Common EIP-7906 misconceptions

EIP-7906 is a smart-wallet permission standard

No. It introduces transaction-outcome introspection and post-execution assertions. It does not create reusable execution authority.

Assertions run before the transaction executes

No. The POST_TX frame is designed to inspect the outcome after the execution body has run.

A failed assertion makes the transaction disappear

No. The transaction can still be included in the block with failed status, and gas is still charged.

A failed assertion reverts everything including payment validation

No. The execution body is reverted, but the validation prefix remains committed.

EIP-7906 works in ordinary EIP-1559 transactions

No. The new opcodes are restricted to EIP-8141 POST_TX frames.

TXTRACE shows every intermediate storage write

No. It exposes the net state difference between transaction prestate and the state observed at assertion time.

account_change_flags includes events

No. Events do not count as account-state modification in that bitmask and must be checked separately.

A zero account-change flag means the account emitted no events

No. The account can emit logs without changing its internal state.

Assertions automatically protect every wallet asset

No. They protect only the outcome properties that assertion code explicitly checks.

A maximum ETH-loss assertion protects ERC-20 tokens

Not necessarily. ERC-20 storage or approvals can change while ETH stays within the limit.

Assertions eliminate approval risk

No. They can constrain approval changes in a particular transaction, but valid approvals can still be intentionally created and persist afterward.

The protocol forces every transaction to include POST_TX protection

No. Smart accounts that require assertions need validation logic enforcing inclusion of the expected POST_TX frame.

An upgradeable assertion contract is equivalent to an immutable policy

No. Execution may be able to alter upgradeable policy logic before the assertion runs.

If an assertion runs out of gas, the transaction should proceed because no violation was proven

No. An unfinished assertion did not verify the outcome and should fail closed.

A valid assertion means the transaction costs no gas if it rejects execution

No. Failed assertions still leave the payer responsible for computation performed.

EIP-7906 replaces transaction simulation

No. Simulation remains useful for explaining likely behavior, estimating gas, and identifying expected outcomes before the wallet constructs assertions.

A practical EIP-7906 security framework

Assertion-aware wallets can reduce outcome security to seven questions.

What should happen?

Identify the intended economic effect.

What must never happen?

Identify unacceptable approval, transfer, deployment, storage, ownership, or code changes.

Which state proves that?

Choose balances, storage slots, code hash, events, or account-change flags according to authoritative protocol state.

Is the assertion mandatory?

Verify that smart-account validation prevents the DApp from removing the required POST_TX frame.

Can the enforcer change?

Use immutable policies where the assertion is a mandatory security boundary.

Can it finish within gas?

Bound enumeration and prefer targeted per-address lookups when possible.

What survives if it fails?

Remember that execution reverts while the validation prefix and gas payment remain committed.

Conclusion: EIP-7906 turns some wallet promises into enforceable execution boundaries

EIP-7906 transaction assertions address a fundamental weakness in transaction signing.

A user does not ultimately care that they signed calldata with a particular function selector.

They care about what happens to their assets and account after the transaction executes.

They care that the swap delivers enough output.

They care that no hidden spender receives unlimited approval.

They care that a vault remains untouched.

They care that a transaction does not deploy unexpected code.

They care that the smart wallet does not silently change ownership or storage outside the intended operation.

Pre-signing transaction decoding and simulation can estimate those effects.

EIP-7906 proposes infrastructure to inspect and constrain the actual resulting state.

The design depends on EIP-8141 frame transactions.

Normal validation and execution occur first.

POST_TX frames then run as a trailing suffix.

Inside that restricted phase, TXTRACE can enumerate net balance changes, storage differences, new code, events, and gas-payer context.

TXDIFF can make targeted queries against a specific account, code hash, balance, storage slot, event view, or account-change bitmask.

EVENTDATACOPY allows assertion logic to inspect variable-length event data.

If the assertion is satisfied, the execution result remains.

If the assertion fails, the execution body is reverted.

The transaction can still be included with failed status.

The gas payer still pays.

The validation prefix remains committed.

Those semantics are essential to understand because "protected" does not mean "free if blocked."

The design intentionally preserves network-level economic accountability.

The most powerful part of EIP-7906 is not the number of state fields it exposes.

It is the change in wallet security philosophy.

Instead of saying "our simulation thinks this transaction will do X," a wallet can potentially say "this transaction will not succeed unless invariant X remains true."

That is a much stronger security primitive.

It also transfers responsibility toward assertion quality.

An incomplete assertion can be dangerous precisely because it looks authoritative.

If the wallet constrains only ETH loss, ERC-20 approval risk can remain.

If the wallet checks only events, malicious state behavior can remain.

If the wallet checks one token but ignores another, value can escape through the uncovered asset.

If the wallet displays "Transaction protected" without explaining coverage, users can become less careful rather than more secure.

Assertions should therefore be described as exact guarantees.

"Your ETH balance cannot decrease by more than this amount."

"This USDC balance must increase by at least this amount."

"This vault account must remain unchanged."

"No approval event from this token may authorize an unknown spender."

Those claims are specific enough to test.

The next major requirement is mandatory inclusion.

EIP-7906 does not force every transaction to contain POST_TX frames.

If a smart account promises assertion protection, its validation logic must verify that the intended POST_TX enforcer is present.

Otherwise a malicious frontend can simply remove the checker.

The assertion target also needs strong immutability guarantees.

Checking that a transaction ends with calls to address A is not enough when address A can be upgraded during execution.

A mandatory security policy should not be replaceable by the very transaction it is supposed to police.

Gas exhaustion is another important boundary.

An assertion that runs out of gas has not established safety.

A malicious DApp can deliberately create many events or state-diff entries to stress a naive checker.

Targeted TXDIFF queries, per-address event views, bounded loops, entry-count checks, and sufficient gas stipends are therefore security mechanisms rather than mere performance optimizations.

Wallet builders also need to understand the limits of net state differences.

TXTRACE does not expose every intermediate write as a timeline.

Storage that changes and is restored can disappear from the final net diff.

That is appropriate for assertions focused on final outcome.

It is not equivalent to a complete historical execution trace.

This is where independent analysis remains valuable.

TokenToolHub's Transaction Decoder can provide transaction-level inspection of target contracts, nested calls, approvals, transfers, execution traces, gas, and failures.

The Clear Signing in Crypto guide addresses the pre-signing comprehension layer.

The Crypto Approval Risks guide covers persistent spender authority that can survive successful transactions.

And the Permit2 and Allowances guide covers another reusable authorization surface that EIP-7906 assertions can constrain in one transaction but do not replace as a permission system.

The broader security direction is layered.

Protect the key.

Explain the intent.

Simulate the likely result.

Assert the acceptable outcome.

Limit persistent authority.

Verify what actually happened.

EIP-7906 fits directly into that progression.

Its most useful principle can be summarized in one line:

If EIP-7906 or a similar outcome-assertion model reaches broad wallet adoption, transaction security could move beyond increasingly sophisticated warning screens toward enforceable user-defined boundaries on actual execution.

FAQs

References and further reading

These official Ethereum resources provide the primary technical basis for transaction assertions, frame transactions, and the broader wallet-security context.

• EIP-7906: Transaction Assertions via State Diff Opcode
• EIP-8141: Frame Transaction
• EIP-2929: Gas Cost Increases for State Access Opcodes
• Ethereum Improvement Proposals
• Ethereum.org: A More Secure Ethereum

EIP-7906 remains a Draft Core proposal and depends on the evolving EIP-8141 frame-transaction design. Opcode assignments, gas costs, frame semantics, and integration requirements can change before finalization. Transaction assertions also protect only the invariants explicitly implemented by their assertion logic. This guide is educational security research and is not financial, legal, or software-audit advice.