Ethereum Draft Would Let Sponsors Pay for Shared Batch Proofs

Ethereum contributor Marchhill has filed a draft pull request that would let sponsors pay for batch proofs while individual transactions keep separate payments and signatures. The submission, posted to Ethereum's EIP repository on Nov. 13, has no EIP number, no mainnet activation date and no status as an adopted network upgrade — it's a working draft, and its fees are explicitly provisional.

How would shared proof payments work?

At the core of the draft is a two-sided payment arrangement. A sponsor covers each retained batch leaf — an individual proof component holding several claims — while member transactions pay for their own submitted claims. The draft activates the LEANSTARK_SCHEME reserved in EIP-8288 and introduces rules for sponsored batches.

Builders would gain flexibility under the design. A builder could include any valid subset of a batch without asking members to sign their transactions again, so a transaction ready for inclusion wouldn't need a fresh signature just because other members of its original group were dropped. The proposal supersedes an earlier submission, pull request #12654, and folds generic verification, proof identity, resource limits, dependency summaries and batch payments into a single document. A dedicated discussion thread remains unassigned.

The mechanism preserves account-level plumbing. Individual transaction nonces and receipts stay attached to each transaction even when proof work is shared, and payment matching would be checked during finalization, with recursive proofs authenticating the sources used in the batch.

Where do the payments go?

The economics route money directly to block builders. Discounted claims and sponsor payments would flow to builders, while ordinary single-statement proofs remain eligible for the public mempool, where transactions wait for inclusion. The draft separates proving that claims are valid from confirming the necessary payments accompany them.

What does it build on?

The foundation is EIP-8288, authored by Vitalik Buterin and Thomas Coratger, which proposes aggregating cryptographic signatures and proofs outside Ethereum's main execution process. Transactions would identify statements needing verification, and a recursive STARK would establish validity at block level. STARKs prove a computation ran correctly without every verifier repeating it; recursion lets one proof verify others.

EIP-8288 currently only reserves the generic leanSTARK scheme rather than permitting its use in dependency frames. Marchhill's draft enables that path and replaces the base draft's bare data-hash statement with a stable digest representing a list of claims. Buterin has previously backed handling complex cryptography through aggregated proofs; Marchhill's submission turns that architectural preference into a concrete verification and payment arrangement.

What are the proposed costs?

The revision lists provisional charges:

• 15,400 gas for native verification
• 572,000 gas for ordinary generic verification
• 5,100 gas for the intrinsic proof share
• 675,000 gas for a leaf payment
• 4,200 gas per batch claim

Leaf payments carry a separate charge because binding payments add fixed work beyond ordinary verification, the draft explains. The figures require joint calibration, so they don't establish a final fee schedule or a confirmed user saving.

Resource controls include a provisional block limit of 16,384 distinct dependencies, applied independently of gas, plus a corresponding inclusion-list fit rule. A leaf could hold up to 256 claims and a proof step could take 16 inputs — neither is a block-wide cap.

What stands between this and activation?

Performance evidence, first. The proposal requires measurements covering the full processing schedule, late sponsor repair, and per-proof charges that fit within transaction gas limits including required overhead. Its benchmark material distinguishes measured individual-node and single-machine results from modeled 16-worker figures, and remaining gaps must be recorded there.

One operational wrinkle: an invalidated sponsorship could waste a builder's work, and inclusion gas would not reimburse it. Commitment construction details stay in the pinned proof-system specification, and the proposal adds no new networking messages. Until the benchmarks land and an EIP number is assigned, the draft sits in Ethereum's review queue with its activation question open.