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

A Quick Guide for Founders, CTOs, and Product Leaders

Wondering what kind of throughput, latency, gas, and reliability numbers you should expect from proof verification API providers in 2026? You're in the right place! We'll break it down for you, including how these targets shift with Ethereum’s latest upgrades and the proof systems you decide to use.

Throughput

• What to Expect: Aim for higher transaction throughput, ideally in the thousands per second. As Ethereum continues to evolve, these numbers should consistently improve.

Latency

• Ideal Targets: Keep latency as low as possible--think in the single-digit milliseconds range. With advancements in technology, this is becoming more achievable.

Gas Fees

• Your Goal: Look for gas fees that remain manageable. As Ethereum upgrades roll out, the hope is for costs to lower, making transactions more affordable.

Reliability

• Key Numbers: Reliability should be a top priority, aiming for uptime of at least 99.9%. You want to be sure that the service is there when you need it.

Adapting to Changes

• Ethereum Upgrades: Stay informed on the latest Ethereum upgrades, as they directly impact these metrics. The better the infrastructure, the better your performance.

Proof Systems

• Choosing Wisely: The proof systems you choose can also influence these targets. Make sure to pick systems that align with your performance goals.

By keeping an eye on these factors and being proactive about the changes in the ecosystem, you’ll be well-equipped to make informed decisions in 2026 and beyond!

---

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

If you're planning to roll out a new rollup in 2026, chances are you'll want to tap into specialized services for at least some part of the proof lifecycle:

• Verification layers and Aggregation Verification Services (AVSs) that batch-verify loads of app and rollup proofs while giving a thumbs up to Ethereum (like Aligned). Check it out here!
• Chains dedicated to verification that dive into SNARKs and STARKs natively, posting their attestations across various L1 and L2s (for example, zkVerify). You can read more about it here.
• zkVM stacks and coprocessors that provide affordable, lightweight on-chain verifiers (think SP1, Axiom, Brevis/RISC Zero pipelines). Want to learn more? Head over here!

These vendors love to throw around impressive performance claims. Your task is to hold them accountable by nailing down specific, Layer 1-aware numbers that align with your goals for finality, fees, and uptime.

---

What changed in 2025-2026 that affects verification budgets

• The Ethereum mainnet block gas limit has officially bumped up to 60,000,000. That’s double what it was in early 2025, which means you can fit in more “verifications per block.” This means you can verify a greater number of small SNARKs in each slot, or handle larger batches using a BLS-aggregated attestation. If you want to check it out, Etherscan has blocks showing this new gas limit from December 2025, and industry trackers back this up too. (etherscan.io)
• We’ve got BLS12-381 precompiles (EIP-2537) up and running on the mainnet as of May 7, 2025 (hello, Pectra!). The pairing cost is 32,600·k + 37,700 gas, and if you’re looking at a typical 2-pair check--popular in many aggregate-signature processes--that’ll set you back around 102,900 gas. This update seriously cuts down the on-chain cost for those “verify-once, attest-many” setups. You can read more about it here. (blog.ethereum.org)
• Calldata pricing has been adjusted upward (EIP-7623) to encourage rollups to adopt blobs more actively. So, if you’re thinking about verification strategies, don't just assume that calldata will be cheap. Be sure to plan for blob-centric pipelines instead. (eips.ethereum.org)
• Blob capacity has increased too (EIP-7691), with a target of 6 and a maximum of 9 blobs per block. They’ve also formalized per-fork blob schedules (EIP-7840). So, expect to see even more blob headroom as PeerDAS rolls out in updates after 2025, which should boost sustainable data availability throughput. (eips.ethereum.org)

Here’s the deal: you’ve got more L1 gas available per block for verifications, BLS aggregation just got cheaper, and the fee setup now hits you harder for calldata compared to blobs. Make sure your provider’s throughput claims line up with these updates.

---

On‑chain ceilings you can actually plan against

When providers say, “we can verify X proofs/second,” it’s important to break that down into actual Ethereum block-level limits based on the current gas schedules.

• Groth16 on BN254 (alt_bn128) with a Solidity verifier:
  • The gas cost for the pairing precompile is about 34,000·k + 45,000 (thanks to EIP‑1108/EIP‑197). Check it out here: (eip.directory).
  • If you're looking at the whole verifier cost, it’s roughly 207,700 gas as a base, plus around 7,160 gas for each public input. So, for a simple circuit with 2 public inputs, you're looking at about 220k gas. If we assume 60M gas, that means you could fit in roughly 272 proofs per block if every transaction was a Groth16 verification. More details can be found here: (medium.com).
• Groth16 and PLONK wrappers from the latest zkVMs:
  • For the SP1 Groth16 wrapper, you’re looking at around 270k gas (according to the docs) to about 300k gas (from the blog). That translates to approximately 200-222 proofs per 60M-gas block. Check out the docs for more details: (docs.succinct.xyz).
  • As for PLONK in SP1 mode, it costs about 300k gas, and the proof size is roughly 868 bytes--just a heads-up about calldata if blobs aren't in the mix. More info here: (docs.succinct.xyz).
• BLS12‑381 aggregate-signature verification (EIP‑2537):
  • For a 2-pair check, you’re looking at around 102,900 gas. An attestation can actually cover hundreds or even thousands of off-chain verifications, assuming your provider does the aggregation right. If we’re still at 60M gas, you could theoretically manage about 583 of those verifications per block, though protocol overhead will trim that number down a bit. More on this here: (eips.ethereum.org).
• KZG point evaluation (EIP‑4844 precompile 0x0A): It has a fixed cost of 50,000 gas per opening, which is handy for blob-based verification patterns and commitments. Get the details here: (eips.ethereum.org).

Think of these as the solid limits for “how many direct on-chain verifications could fit if the block belonged to you.” Providers really need to demonstrate how they batch or aggregate their transactions to get close to these upper limits during those hectic spikes.

---

Off‑chain verification layers: what they can do today

• Aligned (EigenLayer AVS): They’re currently hitting around 200 verifications per second on their mainnet beta, but in testing, they’ve seen throughput soar with over 1,000 to 4,000 verifications in a second. The costs are pretty reasonable; for one batch (even if it's just a single proof), you’re looking at about 350k gas. Meanwhile, a single BLS aggregate on Ethereum is around 113k gas. Just keep in mind that unit costs decrease as the batch size increases. It’s worth asking them about their sustained p95 throughput when public fees apply and using a proof mix that’s similar to what you have in mind. Check them out here: (blog.alignedlayer.com).
• zkVerify (Substrate L1): This chain is designed specifically for proof verification and they’re bragging about cutting costs by more than 90% compared to verifying directly on Ethereum, plus they’ve got millisecond-level processing. They do attestations to Ethereum and L2s, too. Make sure to validate the p50 and p95 submission-to-attestation latency during L1 congestion, and get the exact gas used for the attestation path that you'll be calling. Here’s where you can learn more: (docs.zkverify.io).
• Brevis/Pico Prism: They’ve put out some real-time metrics for L1 block proving, showing an average of 6 to 7 seconds for blocks around 36 to 45 million gas on large GPU clusters. This info is super relevant if you’re aiming for near-real-time settlements or zk light-client flows. Tie their claim of “coverage under 12 seconds” to your finality budget to ensure it lines up. More details can be found here: (chainwire.org).
• RISC Zero Bonsai: They’re marketing themselves as a scalable proving service with parallel clusters and a promise of “99.9% uptime.” It’s a good idea to ask for a signed SLA along with their public status-page history. Also, confirm that they’re production-ready for your specific chain. Check them out at: (risc0.com).

---

The five benchmark categories you must require

Be sure to reach out to every verification provider for specific, testable numbers in these areas. We’ve included some “good targets” based on what we expect for the 2025-2026 mainnet conditions, along with the latest info from vendors.

1) End-to-End Latency and Coverage

• Define Your Unit: Choose between “proof submission → on-chain attestation included on Ethereum mainnet (L1)” or “proof submission → contract verifyProof() success on L1.”
• Requirements for Performance: We need to see p50/p95/p99 and max jitter across the board:
  • direct SNARK verify,
  • BLS-aggregated attestation,
  • recursive aggregation path.
• Targets to Aim For:
  • For BLS-aggregated attestations, we’re looking for p95 to be less than 2 Ethereum slots (or 24 seconds) during at least 90% of blob/basefee conditions. You can find more info here.
  • With Direct Groth16 verification, the provider needs to show that their per-block batching plan uses 40% or less of 60M gas at p95. Considering it takes about 220k gas per proof, that puts us at a cap of 109 proofs per block at p95 load. Check out more details here.
  • If “real-time proving” is in your plans, we’re asking for p95 to be 10 seconds or less per proof for your circuits, given certain hardware budgets (think EF north-star targets), and please reference some independent public runs. More info can be found here.

2) Throughput Under Contention

• When you’re diving into throughput, make sure to grab the sustained and burst throughput numbers in “verifications/second” and “verifications/block on Ethereum” for your proof types:
  • Direct Groth16/PLONK on BN254: We're looking at a theoretical max of 200-270 proofs per block at 60M gas. It’s a good idea to ask for a measured, reproducible ≥60% of this capacity in public load tests. You can read more about it here: (medium.com).
  • BLS‑aggregated mode: Ask for confirmation that one Ethereum transaction can handle ≥500 verified items with less than 200k gas from start to finish (including aggregation and housekeeping). You should also benchmark the submission to inclusion within a median of ≤1 slot. More details can be found at (eips.ethereum.org).
  • Vendor-specific claims (for example): If a provider is boasting “200 verifications/second on mainnet beta,” don't hesitate to request a 24-hour p95 and p99 SLOs along with the exact on-chain gas usage per batch. Check out what they’ve got to say here: (blog.alignedlayer.com).

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

Alright, let’s break down the gas requirements for verifying your circuit. You’ll want to factor in the following:

• Gas per verify should be detailed as:
  • Precompile usage: For BN254 pairings, check 0x06-0x08, and for BLS12-381, look at 0x0b-0x11.
  • Base overhead, which sits at around 21k.
  • Calldata vs blob payload.
  • The number of public inputs.

Now, for some concrete checks, here’s what to keep an eye on:

• The gas cost for BN254 Groth16 is roughly 207,700 plus an additional 7,160 multiplied by the number of public inputs. Make sure the vendor provides a reproducible measurement, like a Foundry test, that reflects your verifier with the expected number of public inputs. Check out this post for more details: (medium.com).
• If they’re using the SP1 Groth16 wrapper, ask them for a live mainnet transaction sample that shows gas usage around 270-300k. You can find more info here: (docs.succinct.xyz).
• Additionally, if they’re counting on blob data or KZG checks, you should plan for 50,000 gas for each point evaluation (0x0A) in your budget. Also, make sure to confirm their routing for calldata vs. blob under EIP-7623. More about that can be found here: (eips.ethereum.org).

4) Reliability and Settlement Guarantees

Make sure to ask for:

• A signed SLA that includes the monthly p99 latency and the percentage of blocks that get included within N slots.
• Degradation plans: if the aggregation fails, can they switch to direct per-proof verification without exceeding your gas budget?
• For EigenLayer AVSs, get info on the number of operators, how much stake is at risk, slashing conditions, and their history on mainnet. (blog.alignedlayer.com)
• For verification chains, inquire about the finality times for L1 attestations, how they handle re-orgs, and the exact amount of gas used to post the attestation to your destination chains. (docs.zkverify.io)

5) Interop, Curves, and Proof Systems

• Make sure to check off support for:
  • BN254 Groth16, which is good to go, BLS12-381 for MSM/pairing, and let’s not forget your favorite zkVM proof mode--whether it’s SP1, RISC0, Halo2/PLONK, or STARKs, either directly or through recursion. You can find more details here: (eips.ethereum.org).
  • If you’re diving into STARKs, it’s crucial to have a solid plan for recursion that leads to a compact SNARK or some native verification off the EVM, plus attestation. Vendors should definitely be able to break down the gas savings compared to doing direct STARK verification. Check out more on this: (orbiter-finance.medium.com).

---

Example calculations you should force vendors to do with you

1) Direct Groth16 Path

• Assumptions: We're looking at a BN254 Groth16 verifier here. With 2 public inputs, you’re looking at around ~220k gas per verification. If you’ve got a block with 60M gas, that means you could squeeze in about ~272 proofs per block. And if you’re cranking out 2 slots a minute, that could lead to around ~544 proofs per minute--assuming those blocks are all yours.
• Your ask: You want the vendor to show off a batched submitter on the mainnet that can pack in at least 100 verifications using no more than 30% of a single block’s gas, at p95, along with receipts. Check out the full details here: medium.com.

2) Aggregated BLS Attestation Path

• Assumptions: When we're checking a batch, the estimated cost is around 103k gas, thanks to the 2-pair BLS check, plus some extra housekeeping. We're aiming to keep the total gas usage at or below 150k. With 60M gas to play with, we can theoretically handle about 400 to 580 batches per block.
• Your Request: With a goal of batching 1,000 proofs, we want to see an end-to-end process where the time from “proof submitted” to “attested on Ethereum” hits p95 at or below 24 seconds on a day when the median blob utilization is at least at the target (after EIP-7691). You can check out more about it here: eips.ethereum.org.

3) Blob‑assisted verification

• Assumptions: After EIP‑7623, let’s keep calldata minimal. We'll use blobs for the big stuff and KZG 0x0A for point checks, which will set us back about 50k gas per claim.
• Your ask: We need to measure the blob posting and point-evaluation calls so that the total stays at or below 200k gas for your verification flow. And just in case blob basefee spikes, we should have a backup plan to switch to pure SNARK verification. You can check out more details here.

---

What to ask, proof‑system by proof‑system

Groth16 (BN254)

• Benchmarks to watch out for:
  • Gas: You’ll want to expect around 207.7k for the base gas cost, plus about 7.16k for each public input when you're running your verifier on the mainnet. Don't forget to include the calldata bytes and the exact ABI encoding you used. You can dive into more details here.
  • Block capacity: When planning, aim to keep your worst-case batch to 40% or less of a block's capacity--this gives you some breathing room for any congestion that might pop up.
  • Security consideration: If you're looking for security of 120 bits or more, or if you need BLS signatures, it's a good idea to start planning your move to BLS12-381 verifiers since EIP-2537 is now live. You can check those details here.

PLONK/Halo2

• Demand:
  • Check out the gas requirements for your verifier on BN254 compared to BLS12‑381; it’s worth noting SP1’s figures are around ~300k. Don’t forget to consider the proof size (~868 bytes) and how calldata stacks up against blob plans. You can find more details here.

STARKs

• Let’s get real:
  • When it comes to direct on-chain STARK verification, you might be looking at multi-million gas costs. To keep things efficient, it’s usually best to go with recursion to a smaller SNARK or use some off-EVM verification along with an L1 attestation. Always ask for those measured gas savings and consider the latency tradeoffs. Typically, you can expect the “outer SNARK” verification to fall in the 300-350k gas range these days. (orbiter-finance.medium.com)

zkVM stacks (SP1, RISC Zero)

• Targets to request:
  • For SP1 Groth16 wrapper: We're aiming for less than 300k gas for verification on mainnet. Also, we need the 95th percentile for submission → inclusion to be under your finality SLO. If you’re working with a bunch of small proofs, check out recursive aggregation options. You can find more details here.
  • For Bonsai/RISC Zero: We’ll need some solid production SLOs and a public status history that supports that “99.9% uptime” claim. Plus, don’t forget about per‑second concurrency limits! You can read more about it here.

Verification Layers (Aligned, zkVerify)

• Here’s what you need to ask for:
  • Sustained verifications per second using your proof mix, with costs aligned to the median blob and gas prices on mainnet.
  • Get the exact gas fees per batch on Ethereum: For Aligned, you're looking at about ~350k for a single-proof batch and around ~113k for the BLS aggregate signature component. Make sure to double-check with the mainnet txids. (blog.alignedlayer.com)
  • Don’t forget about multi-chain attestations and replay protection! zkVerify talks about multi-chain posts; it’s worth quantifying the gas costs per destination and measuring the p95 cross-posting latency. (prnewswire.com)

---

RFP checklist you can paste into an email

Could you please ask the vendors to fill this out? They should include mainnet transaction links and screenshots from Grafana/Prometheus where it makes sense:

• Protocol Coverage
  • We're currently supporting a bunch of proof systems like Groth16 on BN254, PLONK, Halo2, STARK native, SP1, and RISC0, along with curves such as BN254 and BLS12‑381. Don't forget to check out the verifier addresses and ABIs. You can find more details on this here.
• On-chain Gas and Data
  • Let’s talk about “my circuit” which has N public inputs:
    • We’ve got the average gas usage, along with the p50 and p95 figures for each verification, the number of calldata bytes, and blob usage. Also, if you’re curious, KZG precompile calls are included where applicable (0x0A at 50k gas). More info is available here.
  • When it comes to aggregated attestations:
    • We’ll break down the total gas per batch for sizes [1, 10, 100, 1000], plus we’ll add in the BLS precompile usage and the gas per pairing. Details can be found here.
• Throughput and Latency SLOs
  • We’re eyeing sustained verifications per second and verifications per block on Ethereum, focusing on the p50 and p90 for both basefee and blobfee.
  • For submission to on-chain inclusion, we’ve got p50/p95/p99 metrics that we’ll analyze under peak conditions (just remember to define those basefee and blob utilization windows).
• Reliability
  • We’re keeping track of our 90-day SLO attainment, diving into incident postmortems, and making sure we have a solid failover plan (which includes a fallback to direct verification).
  • For AVSs, let’s go over the operator set size and how much ETH is restaked today; we’ll also touch on slashing and how we handle attestation fraud. Check out more on this topic here.
• Economics
  • We've got a fee schedule laid out in both gwei and USD terms across the [basefee, blobfee] bands.
  • When it comes to external verification chains, we'll look at the posting costs per destination chain and how we manage re-orgs; plus, there will be sample attestation transactions. You can find more details here.
• Roadmap Alignment
  • We're aligning our support plans with PeerDAS-driven blob growth and keeping an eye on any future changes to precompiles or gas accounting (like utilizing BLS MSM discounts and upcoming verifier upgrades). More on this can be found here.

---

Emerging best practices we’re using with clients

• If you're starting new aggregate-verification flows, go with BLS12‑381. It’s now more cost-effective per pairing on Ethereum compared to BN254 and offers up-to-date security. You can still use BN254 Groth16 for those tiny “outer” SNARKs if they’re significantly smaller right now, but plan to switch it out down the line. (eips.ethereum.org)
• Think of calldata as your last option. With EIP‑7623 in play, hefty payloads should be stored in blobs, while smaller on-chain checks can use KZG 0x0A along with a compact outer SNARK. (eips.ethereum.org)
• Get ready for the 60M gas reality. The number of “direct-verify” proofs per block has shot up, and so has the possible size of aggregated attestations. Make sure that providers have their capacity plans ready at p95 block fullness. (etherscan.io)
• Think in layers when you're verifying. For lots of rollups, the best approach seems to be: off-EVM verification for those bigger STARK/zkVM proofs → quick and small L1 verification using BLS aggregates or outer SNARKs, with obvious fallback options. (blog.alignedlayer.com)
• Push for live, public proofs. It’s easy to create flashy marketing decks, but getting mainnet transaction hashes and running 24-hour soak tests? That’s the real deal. Make sure you're insisting on the latter.

---

Worked example: a “Stage 1” rollup SLO

Let’s say you’re aiming for a 10-minute “economic finality” on the Ethereum mainnet, using just 1 proof for each rollup batch.

• Direct Groth16 (BN254) outer proof path:
  • You’re looking at a budget of around 220-300k gas per verification. Even if blocks are about 50% packed with other stuff, your submitter can still squeeze in quite a few proofs per block. Just make sure to aim for that p95 under real base fee. (medium.com)
• Aggregated path via AVS:
  • Here, you can batch hundreds of those proof validations into one BLS-verified attestation, which usually costs about 100-150k gas. Your goal should be to get that submission to inclusion in 24 seconds or less on the p95 front. And if AVS isn’t performing well, no worries--just fall back on the direct verify option. (eips.ethereum.org)

Please reach out to your provider and request that they run this end-to-end test for 72 hours on the mainnet. Also, ask them to publish the dashboards and set aside the penalties for any missed SLOs.

---

Final notes as you draft your RFP

• Work through the numbers with vendors--talk about your circuits, how many public inputs you’re counting, and the batch sizes you’re aiming for.
• Connect every claim to an Ethereum block gas budget and a blob budget that matches today’s standards (check out EIP‑7691 and EIP‑7840) and keep an eye on blob growth driven by PeerDAS. (eips.ethereum.org)
• Make sure to snag signed SLAs that focus on “verifications per block” and “p95 slots to inclusion,” instead of just saying “verifications/second.”

If you're looking for a fresh perspective on a provider's numbers or need help with a week-long, mainnet-focused bake-off, we've got you covered. We've assisted several teams in turning marketing claims into practical SLOs and gas budgets that fit their launch schedules perfectly.

---

References for Parameters and Figures Cited

• Check out the EIP‑2537 BLS12‑381 precompiles and gas formulas right here.
• For details on EIP‑1108, which covers BN254 pairing gas and Groth16 verification math, visit this link.
• If you’re interested in SP1 Groth16/PLONK verification gas and proof sizes, you can find the info here.
• The EIP‑4844 KZG point evaluation precompile and blob parameters are detailed at this location.
• For insights into EIP‑7623, which includes calldata repricing, blob target/max increases (check out EIP‑7691), and the per-fork blob schedules from EIP‑7840, head over here.
• You can find evidence of the Ethereum 60M gas limit on Etherscan.
• Lastly, for some interesting notes on aligned layer throughput, gas amortization, zkVerify positioning, cost reductions, and Brevis real-time proving results, plus the Bonsai service posture, take a look at this blog post.

---