Newsroom
14 November, 2026 / News / AI / Tags: batch, claims, leaf, proof, provisional

A new pull request outlines rules for verifying multiple claims under one proof while splitting costs between sponsors and individual transactions, building on reserved cryptographic schemes
Ethereum contributor Marchhill submitted draft pull request 12664 on November 13, proposing a mechanism for generic proof verification and sponsored batch processing. The design would allow multiple transaction claims to share a single proof while each transaction retains its separate payment and signature. The draft remains under development and has not been assigned an EIP number or scheduled for network activation.
Under the proposal, builders could select any valid subset of batch members for inclusion in a block without requiring members to generate new signatures. Each transaction would preserve its original nonce and receipt. Payment matching would be verified during finalization, with recursive proofs authenticating the sources used in the batch. The approach separates the work of establishing claim validity from the confirmation that required payments accompany those claims.
Sponsors would cover costs for an aggregated node holding multiple claims, while member transactions would pay according to the claims they submit. Discounted claims and sponsor payments would flow directly to block builders. Ordinary proofs covering a single statement would continue to qualify for the public mempool.
The draft activates the LEANSTARK_SCHEME previously reserved under EIP-8288, which was authored by Vitalik Buterin and Thomas Coratell. EIP-8288 focuses on aggregating cryptographic signatures and proofs outside the main execution process so that transactions identify statements requiring verification and a recursive STARK establishes validity at the block level. Marchhill’s submission enables that reserved path and replaces a simpler data-hash statement with a stable digest representing a list of claims.
Provisional resource controls include a block-wide limit of 16,384 distinct dependencies applied independently of gas, along with a matching inclusion-list fit rule. A leaf could hold up to 256 claims, and a proof step could accept 16 inputs. Neither figure functions as a full-block ceiling. The proposal introduces no new networking messages.
The draft lists provisional gas figures that still require joint calibration: 15,400 for native verification, 572,000 for ordinary generic verification, 5,100 for an intrinsic proof share, 675,000 for a leaf payment, and 4,200 for a batch claim. Leaf payments carry a distinct charge because binding payments add fixed work beyond ordinary verification. Claims and payments would incur no additional intrinsic proof share. These numbers do not represent a final fee schedule or guaranteed user savings.
| Component | Provisional Gas |
|---|---|
| Native verification | 15,400 |
| General verification | 572,000 |
| Intrinsic proof share | 5,100 |
| Leaf payment | 675,000 |
| Batch claim | 4,200 |
The submission replaces an earlier pull request, 12654, and has not yet received a dedicated discussion thread. Full-block performance measurements are required before any activation decision. Benchmarks must cover the complete processing schedule, late sponsor repair, and per-proof charges that remain within transaction gas limits including overhead. Evidence and remaining performance gaps must be recorded in the associated benchmark material. An invalidated sponsorship could leave a builder’s work unreimbursed by inclusion gas. Concrete commitment construction and encodings stay defined in the pinned proof-system specification. No target date for mainnet inclusion appears in the draft.









