For a New Rollup Launch: What Benchmarks or Throughput Numbers to Request From Proof Verification API Providers?

A concise guide for founders, CTOs, and product leaders: exactly which throughput, latency, gas, and reliability numbers to demand from proof verification API providers in 2026—and how those targets change with Ethereum’s latest upgrades and the proof systems you use.

Summary: With Ethereum’s 2025–2026 upgrades (BLS12‑381 precompiles, higher gas limits, calldata repricing, more blobs), realistic per‑block verification ceilings and cost models changed. Use the concrete checklists and example RFP targets below to size on‑chain verification capacity and pick providers that can keep your rollup live during demand spikes. (eips.ethereum.org)

Who this is for, and why “proof verification APIs” matter now

If you’re launching a new rollup in 2026, you’ll likely outsource at least part of the proof lifecycle to specialized services:

Verification layers/AVSs that batch‑verify many app/rollup proofs and attest to Ethereum (e.g., Aligned). (blog.alignedlayer.com)
Dedicated verification chains that check SNARKs/STARKs natively and post attestations to multiple L1/L2s (e.g., zkVerify). (docs.zkverify.io)
zkVM stacks and coprocessors that ship small, cheap on‑chain verifiers (e.g., SP1, Axiom, Brevis/RISC Zero pipelines). (docs.succinct.xyz)

These vendors publish big, round performance claims. Your job is to pin them to precise, L1‑aware numbers that map to your finality, fee, and uptime goals.

What changed in 2025–2026 that affects verification budgets

Ethereum mainnet block gas limit is now 60,000,000. That’s a 2× capacity increase vs early 2025, directly raising the ceiling for “verifications per block.” You can verify more small SNARKs per slot—or larger batches via a BLS‑aggregated attestation. Evidence: Etherscan shows blocks with a 60,000,000 gas limit by December 2025; industry trackers confirm the raise. (etherscan.io)
BLS12‑381 precompiles (EIP‑2537) are live on mainnet (May 7, 2025 Pectra). Pairing cost is 32,600·k + 37,700 gas; typical 2‑pair checks (as used by many aggregate‑signature flows) cost ~102,900 gas. This meaningfully reduces the on‑chain cost of “verify‑once, attest‑many” designs. (blog.ethereum.org)
Calldata got repriced upward (EIP‑7623) to push rollups into blobs. Don’t price verification strategies assuming cheap calldata dumps; budget for blob‑centric pipelines. (eips.ethereum.org)
Blob capacity increased (EIP‑7691; target 6, max 9 blobs per block), with per‑fork blob schedules formalized (EIP‑7840). Expect more blob headroom as PeerDAS lands in upgrades after 2025, raising sustainable DA throughput. (eips.ethereum.org)

Bottom line: You now have more L1 gas per block for verifications, cheaper BLS aggregation, and a fee structure that penalizes calldata over blobs. Your provider’s throughput promises must reflect these realities.

On‑chain ceilings you can actually plan against

When providers quote “we can verify X proofs/second,” translate that into concrete Ethereum block‑level limits given current gas schedules.

Groth16 on BN254 (alt_bn128) via Solidity verifier:
- Pairing precompile gas: 34,000·k + 45,000 (EIP‑1108/EIP‑197). (eip.directory)
- Realistic end‑to‑end verifier cost: ~207,700 gas base + ~7,160 gas per public input; a simple circuit with 2 public inputs is ~220k gas. At 60M gas, that’s ≈ 272 proofs per block if every tx were a Groth16 verify. (medium.com)
Groth16/PLONK wrappers from modern zkVMs:
- SP1 Groth16 wrapper: ~270k gas (docs) to ~300k gas (blog). That’s ≈ 200–222 proofs per 60M‑gas block. (docs.succinct.xyz)
- PLONK (SP1 mode): ~300k gas; proof size ~868 bytes—mind calldata if not using blobs. (docs.succinct.xyz)
BLS12‑381 aggregate‑signature verify (EIP‑2537):
- 2‑pair check ~102,900 gas. One attestation can cover hundreds/thousands of off‑chain verifications if your provider aggregates properly. At 60M gas, theoretical max is ≈ 583 such verifications per block, but protocol overhead will reduce that. (eips.ethereum.org)
KZG point evaluation (EIP‑4844 precompile 0x0A): fixed 50,000 gas per opening—useful for blob‑based verification patterns and commitments. (eips.ethereum.org)

Use these as the hard bounds for “how many direct on‑chain verifications could fit if the block was yours.” Providers must show how they batch/aggregate to get near these ceilings during spikes.

Off‑chain verification layers: what they can do today

Aligned (EigenLayer AVS): claims present‑day mainnet beta around ~200 verifications/second, with test throughput >1,000–4,000 verifications/second. Costs are amortized: one batch (even with one proof) is ~350k gas, with a single BLS aggregate on Ethereum ~113k gas; unit costs drop as the batch grows. Ask for their sustained p95 throughput under public fee conditions and proof mix similar to yours. (blog.alignedlayer.com)
zkVerify (Substrate L1): purpose‑built chain for proof verification, marketing a >90% cost reduction vs verifying on Ethereum and millisecond‑level processing; then they attest to Ethereum/L2s. Validate real p50/p95 submission‑to‑attestation latency under L1 congestion, and exact gas used for the attestation path you’ll call. (docs.zkverify.io)
Brevis/Pico Prism: published real‑time L1 block proving metrics (e.g., 6–7s average for 36–45M‑gas L1 blocks on large GPU clusters). This is relevant if you want near‑real‑time settlement or zk light‑client flows. Tie their “coverage under 12s” claims to your finality budget. (chainwire.org)
RISC Zero Bonsai: positioned as a scalable proving service with parallel clusters and “99.9% uptime” messaging. Ask for a signed SLA plus public status‑page history, and confirm their production readiness for your chain. (risc0.com)

The five benchmark categories you must require

Ask every verification provider for concrete, testable numbers in these categories. We include “good targets” based on 2025–2026 mainnet conditions and current vendor disclosures.

End‑to‑end latency and coverage

Define your unit: “proof submission → on‑chain attestation included on Ethereum mainnet (L1)” or “proof submission → contract verifyProof() success on L1.”
Require p50/p95/p99 and max jitter across:
- direct SNARK verify,
- BLS‑aggregated attestation,
- recursive aggregation path.
Targets to request:
- BLS‑aggregated attestations: p95 < 2 Ethereum slots (≤24s) during ≥90th percentile blob/basefee conditions. (eips.ethereum.org)
- Direct Groth16 verify: provider must demonstrate that your per‑block batching plan consumes ≤40% of 60M gas at p95. With ~220k gas/proof, that’s ≤109 proofs per block at p95 load. (medium.com)
- If “real‑time proving” is part of your design, request p95 ≤10s per proof for your circuits at specified hardware budgets (EF north‑star targets), and cite independent public runs. (chainwire.org)

Throughput under contention

Ask for sustained and burst throughput in “verifications/second” and “verifications/block on Ethereum” for your proof types:
- Direct Groth16/PLONK on BN254: 200–270 proofs per block is the theoretical max at 60M gas; request a measured, reproducible ≥60% of this capacity in public load tests. (medium.com)
- BLS‑aggregated mode: request proof that one Ethereum transaction can cover ≥500 verified items with <200k gas end‑to‑end (agg + housekeeping). Benchmark submission → inclusion within ≤1 slot median. (eips.ethereum.org)
- Vendor‑specific claims (example): if a provider markets “200 verifications/second on mainnet beta,” ask for 24‑hour p95 and p99 SLOs plus the exact on‑chain gas footprint per batch. (blog.alignedlayer.com)

Gas, calldata/blob, and cost math for “your” circuit

Require per‑verify gas broken down by:
- precompile usage (BN254 pairings via 0x06–0x08; BLS12‑381 via 0x0b–0x11),
- base overhead (21k),
- calldata vs blob payload,
- public‑input count.
Concrete checks to include:
- BN254 Groth16 gas ≈ 207,700 + 7,160·(#public inputs). Vendor must produce a reproducible measurement (e.g., Foundry test) for your verifier with target public inputs. (medium.com)
- If they use SP1 Groth16 wrapper, demand a live mainnet tx sample showing ~270–300k gas. (docs.succinct.xyz)
- If they rely on blob data or KZG checks, include 50,000 gas per point evaluation (0x0A) in the budget and confirm their calldata vs blob routing under EIP‑7623. (eips.ethereum.org)

Reliability and settlement guarantees

Insist on:
- Signed SLA with monthly p99 latency and “% of blocks included within N slots.”
- Degradation plans: if aggregation fails, can they fall back to direct per‑proof verify within your gas budget?
- For EigenLayer AVSs, ask for operator count, stake at risk, slashing conditions, and mainnet history. (blog.alignedlayer.com)
- For verification chains, ask for L1 attestation finality times, re‑org handling, and precise gas used to post the attestation to your destination chains. (docs.zkverify.io)

Interop, curves, and proof systems

Confirm support for:
- BN254 Groth16 now, BLS12‑381 MSM/pairing now, and your preferred zkVM proof mode (SP1, RISC0, Halo2/PLONK, STARKs direct or via recursion). (eips.ethereum.org)
- If using STARKs, require a plan for recursion to a small SNARK or native verification off‑EVM plus attestation; vendors should quantify gas saved vs direct STARK verification. (orbiter-finance.medium.com)

Example calculations you should force vendors to do with you

Direct Groth16 path

Assumptions: BN254 Groth16 verifier, 2 public inputs → ~220k gas/verify. At 60M gas, that’s ~272 proofs/block; at 2 slots/minute, you can include ~544 proofs/minute if blocks were entirely yours.
Your ask: vendor demonstrates, on mainnet, a batched submitter that fits ≥100 verifications into ≤30% of one block’s gas, p95, with receipts. (medium.com)

Aggregated BLS attestation path

Assumptions: per batch verify cost ≈ 103k gas (2‑pair BLS check) plus housekeeping; target ≤150k total. At 60M gas, max theoretical ≈ 400–580 batches/block.
Your ask: with 1,000 proofs batched, show end‑to‑end “proof submitted → attested on Ethereum” p95 ≤ 24s during a day with median blob utilization ≥ target (post‑EIP‑7691). (eips.ethereum.org)

Blob‑assisted verification

Assumptions: post EIP‑7623, keep calldata minimal; use blobs for large artifacts and KZG 0x0A for point checks (50k gas/claim).
Your ask: a measurement showing blob posting + point‑evaluation calls that keep total ≤200k gas for your verification flow, with a fallback to pure SNARK verify if blob basefee spikes. (eips.ethereum.org)

What to ask, proof‑system by proof‑system

Groth16 (BN254)

Benchmarks to demand:
- Gas: show 207.7k base + 7.16k/public input on mainnet for your verifier. Include calldata bytes, and the precise ABI encoding used. (medium.com)
- Block capacity: vendor should plan ≤40% of a block for your worst‑case batch, giving headroom for congestion.
- Security consideration: if you need ≥120‑bit security or BLS signatures, plan migration to BLS12‑381 verifiers as EIP‑2537 is live. (eips.ethereum.org)

PLONK/Halo2

Demand:
- Gas for your verifier on BN254 vs BLS12‑381; compare to SP1’s ~300k figures. Include proof size (~868 bytes) and calldata vs blob plans. (docs.succinct.xyz)

STARKs

Real talk:
- Direct on‑chain STARK verification can be multi‑million gas; best practice is recursion to a small SNARK or off‑EVM verification with an L1 attestation. Ask for measured gas savings and latency tradeoffs; 300–350k gas is a common ballpark for “outer SNARK” verifies today. (orbiter-finance.medium.com)

zkVM stacks (SP1, RISC Zero)

Targets to request:
- For SP1 Groth16 wrapper: <300k gas verify on mainnet; p95 submission→inclusion under your finality SLO; and recursive aggregation options if you need many small proofs. (docs.succinct.xyz)
- For Bonsai/RISC Zero: production SLOs and public status history that justify “99.9% uptime,” plus per‑second concurrency limits. (risc0.com)

Verification layers (Aligned, zkVerify)

Ask for:
- Sustained verifications/sec with your proof mix, priced at mainnet blob/gas medians.
- Exact per‑batch gas on Ethereum: Aligned documents ~350k for a single‑proof batch and ~113k for the BLS aggregate signature component; confirm with mainnet txids. (blog.alignedlayer.com)
- Multi‑chain attestations and replay protection; zkVerify claims multi‑chain posts; quantify gas per destination and p95 cross‑posting latency. (prnewswire.com)

RFP checklist you can paste into an email

Ask vendors to fill this out with mainnet tx links and Grafana/Prometheus screenshots where applicable:

Protocol coverage
- Proof systems supported today (Groth16 BN254, PLONK, Halo2, STARK native, SP1, RISC0) and curves (BN254, BLS12‑381). Provide verifier addresses and ABIs. (eips.ethereum.org)
On‑chain gas and data
- For “my circuit” with N public inputs:
  - Gas mean/p50/p95 per verify, calldata bytes, blob usage. Include KZG precompile calls if any (0x0A at 50k gas). (eips.ethereum.org)
- For aggregated attestations:
  - Total gas per batch at sizes [1, 10, 100, 1000]; include BLS precompile usage and gas per pairing. (eips.ethereum.org)
Throughput and latency SLOs
- Sustained verifications/second and verifications/block on Ethereum, at basefee and blobfee p50 and p90.
- p50/p95/p99 submission→on‑chain inclusion, under “peak” conditions (define basefee and blob utilization windows).
Reliability
- 90‑day SLO attainment, incident postmortems, failover plan (fallback to direct verify).
- For AVSs: operator set size and restaked ETH today; slashing/attestation fraud handling. (blog.alignedlayer.com)
Economics
- Fee schedule in gwei and USD terms at [basefee, blobfee] bands.
- For external verification chains: posting costs per destination chain and re‑org handling; sample attestation txs. (docs.zkverify.io)
Roadmap alignment
- Support plans for PeerDAS‑driven blob growth and any future changes to precompiles or gas accounting (e.g., use of BLS MSM discounts, planned verifier upgrades). (eips.ethereum.org)

Emerging best practices we’re using with clients

Prefer BLS12‑381 for new aggregate‑verification flows. It’s now cheaper per pairing on Ethereum than BN254 and offers modern security levels; keep BN254 Groth16 for tiny “outer” SNARKs if it’s meaningfully smaller today, but design to swap. (eips.ethereum.org)
Treat calldata as a last resort. After EIP‑7623, large payloads should live in blobs; small on‑chain checks use KZG 0x0A and a succinct outer SNARK. (eips.ethereum.org)
Engineer for the 60M gas reality. Max “direct‑verify” proofs per block jumped; so did the feasible size of aggregated attestations. Make providers show capacity plans at p95 block fullness. (etherscan.io)
Verify in layers. For many rollups, the sweet spot is: off‑EVM verification for heavy STARK/zkVM proofs → small, fast L1 verification via BLS aggregate or outer SNARK, with clear fallbacks. (blog.alignedlayer.com)
Demand live, public proofs. Marketing decks are easy; mainnet tx hashes and 24‑hour soak tests are hard. Insist on the latter.

Worked example: a “Stage 1” rollup SLO

Suppose you target 10‑minute “economic finality” on Ethereum mainnet with 1 proof per rollup batch.

Direct Groth16 (BN254) outer proof path:
- Budget 220–300k gas per verify. Even if blocks are 50% full from other activity, your submitter can fit dozens of proofs per block; schedule to p95 under real basefee. (medium.com)
Aggregated path via AVS:
- Batch hundreds of batch‑proof validations into one BLS‑verified attestation at ~100–150k gas and aim for ≤24s p95 submission→inclusion. Use direct verify as automatic fallback when AVS is degraded. (eips.ethereum.org)

Ask your provider to run this end‑to‑end for 72 hours on mainnet, publish the dashboards, and escrow penalties for missed SLOs.

Final notes as you draft your RFP

Make vendors do the math with you—on your circuits, your public input counts, and your desired batch sizes.
Tie every claim to an Ethereum block gas budget and a blob budget consistent with today’s parameters (EIP‑7691 and EIP‑7840) and plan for PeerDAS‑driven blob growth. (eips.ethereum.org)
Get signed SLAs that speak in “verifications per block” and “p95 slots to inclusion,” not just “verifications/second.”

If you want a second set of eyes on a provider’s numbers—or a one‑week, mainnet‑based bake‑off—we’ve helped multiple teams translate marketing claims into production SLOs and gas budgets tailored to their launch timelines.

References for parameters and figures cited:

EIP‑2537 BLS12‑381 precompiles and gas formulas. (eips.ethereum.org)
EIP‑1108 BN254 pairing gas; Groth16 verification math. (eip.directory)
SP1 Groth16/PLONK verification gas and proof sizes. (docs.succinct.xyz)
EIP‑4844 KZG point evaluation precompile and blob parameters. (eips.ethereum.org)
EIP‑7623 calldata repricing; blob target/max increases (EIP‑7691) and per‑fork blob schedules (EIP‑7840). (eips.ethereum.org)
Ethereum 60M gas limit evidence. (etherscan.io)
Aligned Layer throughput and gas amortization notes; zkVerify positioning and cost reductions; Brevis real‑time proving results; Bonsai service posture. (blog.alignedlayer.com)