Update EIP-8141: statically disallow approval scope on atomic-batch frames

[Marchhill]

Statically disallows approval scope on any frame of an atomic batch (including its terminating frame), closing the in-batch APPROVE_PAYMENT divergence before execution — no nonce/max_cost rollback and no sender_approved-rollback escalation. Since APPROVE requires the scope in frame.flags, the check is static. Keeps the frame-revert clause (the inner-call-APPROVE-then-enclosing-revert case, independent of batches) and ties the refund to the final payer. Supersedes the earlier batch-unroll rollback approach per review.

Also: fixed linting.

[eth-bot]

File EIPS/eip-8141.md

Requires 1 more review from Authors: @derekchiang, @drortirosh, @fjl, @forshtat, @lightclient, @nerolation, @shahafn, @svlachakis, @vbuterin, @yoavw

[AnkushinDaniil]

The spec already closes the neighbouring cases statically, with ATOMIC_BATCH_FLAG disallowed on VERIFY frames and on any frame of the validation prefix. Disallowing APPROVE_PAYMENT in the flags of a frame belonging to an atomic batch would close this one the same way, and since APPROVE requires the scope to be present in frame.flags, the check is static. It would need to cover the terminating frame j too, which carries no batch flag but is part of the batch. That removes the divergence before execution and avoids rolling back a nonce increment and a balance collection. Is there a use case that needs payment approval inside a batch?

If the rollback stays, invalidity is only decidable after executing much of the transaction, so whoever builds from private order flow pays for that execution and learns the outcome at the end.

Rolling back sender_approved also gives a second path to invalidity: a later SENDER frame with sender_approved == false invalidates the whole transaction, so a batch failure, which is an ordinary outcome, turns into a consensus one. Worth saying whether that is intended, or whether such a frame should fail instead.

The refund is described as going to the resolved_target that called APPROVE, and with rollbacks two different targets can have called it in one transaction, so tying it to the final payer would read unambiguously.

[Marchhill]

Agreed — the static rule is the better fix. I couldn't find a real use case for approving inside a batch: the validation-prefix rules already exclude such transactions from the public mempool, and for private flow the rollback gives "pay from proceeds" nothing — a failed batch unsets payer, so the whole transaction is invalid and the builder has paid to execute it just to learn that. I went a bit further than payment-only and banned the whole approval scope on batch frames, including the terminating frame: banning only payment leaves in-batch APPROVE_EXECUTION, which keeps the sender_approved-rollback escalation from your third point; the full ban makes the approval context constant across a batch so that path can't exist. Kept the frame-revert clause (the inner-call case is independent of batches), and tied the refund to the final payer per your last point.