Update EIP-8141: specify the canonical paymaster implementation

[svlachakis]

Draft. Replaces the canonical paymaster placeholder ("authorizes with a single secp256k1 signer via ecrecover... may change in later specifications") with the implementation: normative storage layout, payment authorization, treasury rules, admin interface, runtime behavior, and per-fork code-hash recognition. The assembled bytecode and its code hash follow once the reference implementation's test run completes; the runtime behavior in the section is the normative definition it will be assembled from.

The design is one invariant applied three times: every state transition that can change a pending transaction's validity is either visible in the tracked set, or delayed longer than the mempool horizon. The three such transitions are a balance decrease, a withdrawal, and a signer change. Balances decrease only through APPROVE charges (tracked) and matured withdrawals (tracked and delayed); signer rotation shares the withdrawal timelock, because payments are an exit a timelock cannot guard - whoever holds the signer key holds the treasury, so changing the key must be as slow as removing the money. With the invariant in place, node accounting is mechanical: admission is a hash comparison plus four slots, revalidation is a diff of the same four slots plus balance, and solvency is arithmetic on slot 1.

Specific choices, briefly:

• No signature recovery in the contract. The sponsor's authorization is a protocol-validated signature entry at index 1 over compute_sig_hash - already verified before any frame runs - so validation is an identity check, not a cryptographic one: ~2,150 gas (three SIGPARAM reads, one cold SLOAD, APPROVE). Because the hash covers the chain id, the sender, its nonce, and the pay frame's own target, one authorization binds exactly one transaction against exactly one instance on exactly one chain; replay protection needs no additional machinery. compute_sig_hash elides only signature bytes for empty-msg entries, so the authorization commits to the signer at index 1 without circularity. Index 1 follows the existing convention for payment signatures.
• The signer lives in storage (slot 0) because code-hash recognition forbids per-instance bytes; the slot joins the tracked dependency set - a finalized rotation invalidates pending transactions authorized by the old key, exactly like a withdrawal maturing.
• One pending action at a time (withdrawal or rotation, shared maturity clock) keeps the observable state to four slots and node accounting O(1) per instance, permanently, regardless of how many transactions the instance sponsors.
• Recognition by per-fork pinned code hash makes canonical status immutable between forks and gives versioning a clean mechanism (pin a new hash; unpinned versions demote to non-canonical). The two other recognition references (the validation-trace exception and acceptance step 4) are aligned to the same code-hash wording, so this carries the recognition change of Update EIP-8141: recognize the canonical paymaster by stable identity, not exact bytecode match #12010 in full - credit to @AnkushinDaniil for the pinned-hash framing.
• Raw-calldata admin interface mirrors the expiry verifier's convention; empty calldata is the validation path, so the hot path pays no dispatch beyond CALLVALUE/CALLDATASIZE.

Also adds a Security Considerations subsection stating the honest boundary: the canonical paymaster protects the mempool from the sponsor, not the sponsor from key compromise beyond the delay window.

[eth-bot]

File EIPS/eip-8141.md

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

[svlachakis]

work is moved to #12041, closing this one