Ethereum EIP-7906 Adds Transaction Checks but Leaves a Key Gap

Ethereum Foundation research published Oct. 5 examines transaction assertions that could reject executions when their final outcome violates a specified rule. EIP-7906 remains a draft as of Oct. 9, depends on EIP-8141 frame transactions, and is listed as considered for the Hegotá upgrade, while EIP-8141 is listed as scheduled for inclusion.

Why it matters

EIP-7906 proposes read-only POST_TX frames that inspect a transaction's resulting state. Its instructions can enumerate specified net changes and events, retrieve values by key, and copy event data. The defined scope includes ETH balances, storage changes, newly deployed contracts and code hashes. Token-balance checks would need to interpret contract storage and apply a chosen limit.

The proposal could support policies that reach beyond a single swap, including preserving account controls or restricting approvals across a route. But it does not require every transaction to include an assertion. Accounts must configure validation to require the specific check without a bypass, and protocols must enforce the required assertion themselves. In solver-settlement flows, the signed order or protocol must bind the solver to the policy.

Market impact

Uniswap v3 already rejects swaps that breach a minimum receipt or maximum input, but those thresholds come from the call parameters. Its guide warns that setting a minimum output to zero is risky in production. A correctly enforced limit can still permit a poor trade if the builder chooses a permissive threshold or derives it from a bad quote.

EIP-7906 also has limits: it evaluates net changes, so intermediate writes that are later reversed may not appear. A failed assertion would revert the execution body, but the transaction remains in the block, gas is charged, and changes in the validation prefix remain committed. The proposal's security guidance calls for immutable assertion targets and references that execution cannot manipulate, such as values fixed at signing or taken from the transaction's starting state. Ethereum could enforce a check precisely while still enforcing the wrong bargain if the policy or its reference is poorly chosen.