Ethereum's EIP-8141 frame-transaction proposal was updated on October 8 to specify that approval state must roll back when a call reverts. The merged change adds two variables, payer and sender_approved, to the state journal used to restore an earlier execution checkpoint.
Frame transactions split validation, fee-payment approval and user operations into separate contract calls. Under the proposed rules, payer identifies the account paying transaction fees, while sender_approved records whether execution on the sender's behalf has been authorized. The current specification remains Draft.
The distinction is between a whole frame failing and a call inside that frame reverting. Previous text already described discarding approval changes when the frame itself failed. The new wording explicitly includes approval context in the journal for calls, frames and atomic batches.
The pull request's explanation describes the nested-call case: an inner call can approve an action, a call above it can then revert, and the enclosing frame can still finish successfully. Restoring the corresponding checkpoint means undoing approval changes from the reverted scope. It does not mean erasing every approval made earlier in the transaction.
For implementers, the concrete requirement is to track these approval variables alongside the state changes whose rollback they follow. A specification edit establishes the expected behavior; it does not demonstrate that a particular client or wallet has implemented it.
This is a distinct follow-up to earlier discussion of inspecting future frames. That discussion concerned what planned calls expose before execution. Today's change concerns which approval effects remain after a nested call is reverted.
Earlier coverage of this event: EIP-8141 exposes future transaction steps, with limits on execution results.
Related reporting: Token Primer: How gas sponsorship lets an Ethereum wallet cover your transaction fees.