Summary: If you're using a proof aggregation API to handle your rollup, the best approach for submitting the combined proof to Ethereum L1 is to stick to a traffic-aware schedule. This means committing every 2 to 5 minutes or as soon as you've filled up a blob or hit your target batch size--whichever happens first. You can tweak this time frame depending on the current blob base fees, when your proof is ready, and your bridge or finality service level objectives (SLOs). Below, you’ll find a practical, numbers-driven framework complete with formulas and examples that you can easily implement in your production environment.

When Relying on a Proof Aggregation API, How Frequently Should I Commit the Combined Proof to L1 to Balance Latency and Gas?

Decision-makers often wonder about this because if you “commit too often,” you’re wasting gas and blob space. On the flip side, if you “commit too slowly,” it can really mess with the user experience, finality, and service level agreements (SLAs) with partners. The silver lining? With post‑EIP‑4844 blobs and modern verification layers, you've got tools to fine-tune both cost and latency just the way you need them.

This guide has got you covered with:

A solid commit policy you can implement right now
Up-to-date cost anchors (like gas, blob pricing, and verification overhead) complete with sources
A handy calculator you can tweak to fit your needs
Realistic profiles for rollups based on high-volume, mid-volume, and low-volume scenarios
Operational guardrails and the latest practices from the 2025-2026 infrastructure era

The two costs you’re balancing (post‑4844)

Data availability (DA) posting through blobs
- Each blob is sized at 128 KiB and is traded in its own “blob gas” market, complete with a unique base fee. Ethereum aims for about 3 blobs per block but can handle up to 6. One thing to note is that blobs get pruned after 4096 epochs (which is roughly 18 days). That’s part of why they’re way cheaper than calldata. Just a heads-up: you’ll be charged for an entire blob, even if it’s only partially used. (eips.ethereum.org)
- Key constants to remember (from EIP‑4844):
  - GAS_PER_BLOB = 2^17 = 131,072 blob‑gas units
  - TARGET_BLOB_GAS_PER_BLOCK = 393,216 (that’s about 3 blobs)
  - MAX_BLOB_GAS_PER_BLOCK = 786,432 (that’s around 6 blobs)
  - MIN_BASE_FEE_PER_BLOB_GAS = 1 wei
  - To find the blob fee per blob in ETH, use this formula: base_fee_per_blob_gas × 131,072 wei. (eips.ethereum.org)
Proof verification on L1 (for your aggregated proof)
- When it comes to Groth16 on BN254, you can expect verification to usually sit around ~200k-250k gas, plus an extra ~6-7k for each public input--big shoutout to EIP‑1108 for repricing those BN254 precompiles! The pairing check formula runs about 45,000 plus 34,000×k gas, making it the most cost-effective option for verification on Ethereum right now. (hackmd.io)
- On the flip side, Plonk/KZG and STARK verifications tend to be a bit heavier on gas, often racking up hundreds of thousands to millions of gas, which is why a lot of teams are wrapping their SNARKs in Groth16--it's a savvy way to cut down on on-chain verification costs. (blog.zkcloud.com)

Add this to your “per batch” bill:

The L1 execution overhead for your settlement contract calls (think state root updates and events). This usually runs up to tens of thousands of gas, so it’s a good idea to measure it in your own deployment.

The knobs you can turn

How to Batch Transactions into DA:

You get charged for each full blob, so it's smart to keep that blob utilization high--ideally at 85% or more. If traffic is a bit slow, it’s better to go with time-based sealing. This way, your users won’t be left hanging waiting for that perfect fill. (blocknative.com)

2) How to Batch L2 Blocks into a Proof

So, when it comes to zk rollups, they usually bundle several L2 blocks into one proof. This helps spread out the verification gas costs. If you check out ZKsync’s documentation, you'll see they take into account the “batch overhead,” which includes the costs for L2 proving and L1 verification. They decide when to seal a batch based on a few factors like time, bootloader capacity, memory limits, and the size of the pubdata. Plus, they’ve set a max latency to keep the user experience smooth, even when the batches aren’t completely full. You can dive deeper into this here.

How to Aggregate Multiple Proofs (using a proof aggregation API or service)

When it comes to aggregating multiple proofs, there are a couple of popular methods you might want to check out:

Off-chain verification with on-chain BLS attestation (think EigenLayer AVS style). This method works like a charm, with Aligned’s Verification Layer managing to verify thousands of proofs per second off-chain. They post a combined BLS signature, which can slash per-proof verification gas costs by a whopping 90-99% when you hit batch sizes of 20 or more. Plus, you're looking at latencies in just milliseconds until “soft finality” and can read the next block on-chain. For more details, take a look here.
Recursive aggregation into a single on-chain proof (“hard finality”) is another route. Aligned’s Aggregation Service aims for around 300k gas for each aggregated proof, no matter how many underlying proofs you're using. They do add a few minutes of latency while working through recursive proving. If you want to dive deeper, check it out here.
Other options in the ecosystem show similar economic trends. For example, Nebra UPA’s current Halo2-KZG aggregated verification runs at about 350k gas base plus an additional ~7k gas for each included proof, which comes to around 18k gas per proof when you have N=32. You can get the full scoop here.
Finally, decentralized prover networks like Succinct’s Prover Network (SP1) and Lagrange’s ZK Prover Network offer low-latency proving APIs and guarantees on liveness. These networks are increasingly becoming part of the OP Stack, zkEVMs, and app-specific rollups. More info is available here.

A production‑ready commit policy

Use a Dual Trigger with Guardrails:

When you're setting up a dual trigger system, it's essential to have some guardrails in place. This helps ensure that everything runs smoothly and that you're keeping your operations in check. Here’s how to go about it:

Identify Your Triggers: Start by clearly defining what your two triggers will be. These could be conditions or events that need to occur before something else happens.
Establish Guardrails: Think about the boundaries within which your triggers should operate. This could include limits on frequency, thresholds for activation, or conditions that, if met, would prevent the trigger from firing.
Test Your Setup: Once you’ve got everything laid out, run some tests to make sure your dual trigger system is working as intended. Check to see if the guardrails are effective in preventing any unwanted actions.
Monitor and Adjust: After implementation, keep an eye on things. If you notice that the triggers are firing too often, or not at all, you might need to tweak your guardrails for better performance.

By using a dual trigger with guardrails, you can maintain flexibility while also ensuring that your system operates within safe and controlled limits. Happy triggering!

Primary policy: Make sure to commit an aggregated proof to L1 every T_max minutes, or whenever you hit one of these two milestones:
- If your pubdata reaches a threshold that's equivalent to one full blob (or a set multiple), or
- If you hit a batch size threshold N_proofs (like the number of L2 blocks/mini‑proofs stacked in your aggregate).
Guardrails:
- Keep things user-friendly by never going over a hard UX limit (for example, 5 minutes) for consumer apps and bridges.
- If blob base fees jump up, feel free to extend the time window up to T_burst (think 10-15 minutes), but only if your bridge SLOs are still on track and you've got soft finality from an AVS attestation in the meantime.
- If proof generation is running behind (thanks, API lag!), don’t hit pause on DA: keep posting those blobs on schedule and submit the aggregate the moment the API signals that it’s ready.

How to Set Up the Triggers

To figure out the live blob cost, you'll want to work with EIP-7516’s BLOBBASEFEE opcode. The cost per blob in ETH can be calculated using the formula: BLOBBASEFEE × 131,072. If this cost exceeds your set per-blob limit, consider either delaying the process (for a maximum of T_burst) or switching to a partial fill if user experience demands it. You can dive deeper into the specifics here.
Keep an eye on proof readiness through your aggregator API callback or the AVS indexer. If the proofs aren’t ready by T_max, don’t sweat it; just submit the last completed aggregate and kick off a new one.

Default values we typically use for most chains these days are as follows:

T_max:
- 2-5 minutes for consumer DeFi and exchange integrations
- 5-10 minutes for enterprise or settlement-heavy flows
- 30-60 seconds for ultra-low-latency perps or gaming on chains that have solid soft finality through an AVS attestation.

Just a heads up, these are more like policy targets rather than strict protocol limits.

Why this works:

It maintains high amortization (with blobs being mostly full and verification gas spread out across more L2 blocks) while keeping user-visible latency and partner SLA windows in check.

The calculator (plug your numbers)

Define the following:

g = L1 gas price (in gwei)
p_blob = base_fee_per_blob_gas (measured in wei) from BLOBBASEFEE
ETHUSD = current spot price of ETH
C_verify = gas required to verify your aggregated proof (like 220,000 for Groth16 with a few public inputs)
C_overhead = additional L1 gas in your settlement path (around 40,000)
B = number of transactions per blob (calculated as utilized bytes divided by 128 KiB)
K = number of L2 blocks or mini-proofs included in each aggregated proof

I'm sorry, but it seems like you've missed providing the text you'd like me to rewrite. Please share the content, and I'll be happy to help!

Blob cost per transaction (ETH):

The formula to calculate it is: Cost_blob_per_tx = (p_blob × 131,072 wei) / B
For instance, if you take p_blob as 3 wei and B as 16,000 tx per blob (that's roughly 8 bytes/tx pubdata after compression--feel free to measure it yourself!), then the blob cost per transaction comes out to about 393,216 / 16,000 = 24.6 wei, which is roughly 2.46e‑17 ETH. This is pretty minimal in most gas scenarios. Just keep in mind that the exact pubdata per transaction can change depending on the codec and protocol used. (eips.ethereum.org)

2) Verification Cost Per Transaction (ETH)

Alright, let’s break down how to calculate the verification cost per transaction. Here’s the formula you'll need:

Cost_verify_per_tx = (C_verify + C_overhead) / (K × 1e9) × g (in gwei) × 1e‑9 ETH/gwei

Example:

Let’s say we're looking at the Groth16 aggregate with the following numbers:

C_verify = 220k
C_overhead = 40k
K = 12
g = 5 gwei

Now, if we plug those values into the formula, we get:

Cost = (260,000) × (5 gwei) = 1,300,000 gwei
That converts to 0.0013 ETH per aggregate.

Now, since we’re amortizing it over 12, it’s:

0.0001083 ETH per L2 block.

To find out the cost per transaction, just add your transaction count per block!

The total cost for settling a transaction at L1 is roughly the sum of the cost to process the blob per transaction and the verification cost divided by the number of transactions in the block.

To set your thresholds, follow these steps:

Pick a value for K that keeps Cost_verify_per_tx below your target--let’s say you want it to stay under $0.001 per transaction based on the expected gas ranges.
Determine B (also known as the “full-blob threshold”) to help maintain a steady Cost_blob_per_tx, even if p_blob increases.

Current anchors you can rely on (Jan 2026)

Blobs: Each blob is 128 KiB, aiming for 3 blobs per block with a max of 6. Fees are set by a separate 1559-style mechanism. Some constants to keep in mind are GAS_PER_BLOB=131,072 and MIN_BASE_FEE_PER_BLOB_GAS=1 wei. Oh, and blobs get pruned after about 18 days. Check it out here.
BN254 Precompile Costs (post EIP‑1108): Here’s the scoop: pairing will cost you 45,000 + 34,000×k gas, while ECADD is 150 gas and ECMUL is 6,000 gas. For verifying a small Groth16, expect around 200k-250k gas. More details can be found here.
Off‑Chain Verification (AVS): Aligned’s Proof Verification Layer does some cool stuff by batching proofs and posting aggregated BLS signatures. A single batch for proofs will run you about 350k gas, and if you batch it out to 20, the effective per-proof cost drops to around 40k gas. Plus, you’ll enjoy millisecond verification and one-block on-chain readability. This is great for getting that “soft finality” in between those “hard” L1 proofs. Dive deeper here.
Recursive Aggregation (“Hard Finality”): You’re looking at roughly 300-350k gas per aggregated proof, regardless of how many proofs you include, plus any storage/event costs for your app. Just a heads-up, there might be a few minutes’ latency. More info is available here.
ZKsync’s Timing Signals: According to their docs, proof generation is still pegged at “about an hour,” with final settlements adding in about a 3-hour delay. Some chains might be using a shared gateway aggregator, which can throw in an extra step. If you go with modern provers/AVS for your own setup, you could speed things up, but it’s smart to plan for the worst-case scenario that’s documented. You can check the details here.

Three deployment profiles with concrete schedules

High‑Volume Consumer L2 (AMMs, Perps, CEX Bridges)

Targets:

Aim for P95 cross‑domain finality to be under 5 minutes.
Keep the per-transaction L1 amortized cost to about $0.001 (using baseline gas).

Policy:

Data Availability (DA): Seal a blob if it hits 110 KiB utilization or every 60 to 90 seconds, whichever comes first.
Proofs: Combine 8 to 16 L2 blocks into a single Groth16 proof. Commit to L1 every 2 to 3 minutes, or right away if there are bridge withdrawals over a certain threshold (let’s say X USD) pending.
Attestation Verification Service (AVS): Submit off-chain verification attestations every block (or every 30 seconds) to enable "soft finality" while we’re waiting on the L1 aggregate. Check it out here.

Rationale:

We're trying to strike a balance between user experience and keeping blobs well-utilized. By sharing around a ~260k gas verify across plenty of blocks, we can drive the cost per transaction down into the “fractions of a cent” range during regular gas usage.

2) Mid‑Volume Enterprise or B2B Settlement Chain

Targets: Aim for a P95 finality of 10 minutes or less and keep those monthly costs predictable.
Policy:
- DA: We’re looking at time-based sealing--around 2 to 3 minutes--with a goal to fill to 80% so we don’t end up waiting too long during those slow hours.
- Proofs: Aggregate about 20 to 30 blocks. We’ll commit to L1 every 5 to 7 minutes, but if there's a spike in BLOBBASEFEE, we can stretch that to 10 to 15 minutes while still keeping those AVS attestations in check.
Rationale: It’s all about keeping costs predictable and making sure we comply instead of just chasing raw speed. The AVS soft finality helps us keep things running smoothly even when fees get crazy. (eips.ethereum.org)

3) Low-volume appchain or game

Targets: Players want that instant gratification, so L1 finalization can take a back seat.
Policy:
- Data Availability (DA): Seal every 60 seconds, no matter how full it is (nobody likes waiting around); it's okay to accept the occasional half-empty blob since the cost per blob is pretty minimal at low p_blob.
- Proofs: Group together a bunch of blocks (think 30-60) and send up the L1 proof every 8-10 minutes or when a big bridge event comes into play.
- Optional: For things like leaderboards or drops, consider using AVS attestation to provide a smooth user experience and then do a checkpoint later with a recursive proof. (blog.alignedlayer.com)

Handling volatility: three adaptive switches

Blob-fee aware throttling
- Check the on-chain BLOBBASEFEE; if p_blob goes above a certain threshold, you can expand the commit window up to T_burst. Just remember to stick to the AVS attestation schedule so that decentralized apps get their “soft finality,” and bridges can choose to accept AVS-backed checkpoints as per their policies. (eips.ethereum.org)
Proof-readiness backpressure
- If your aggregator API throws up a “proof not ready” signal, don’t hold up the data availability (DA). Keep those blobs coming and go ahead and submit the last complete aggregate right away; then, you can kick off a new aggregate window.
Withdrawal-driven fast paths
- If the pending L1 withdrawals are greater than W_USD, or if there’s a market event that causes a spike, just skip the timer and get that current aggregate committed to L1 immediately.

Security and vendor‑risk separation

Let's break down “soft” vs “hard” finality in user-facing docs and API responses:
- Soft finality: This means that the AVS attestation is posted and can be read on L1, with super quick verification (think milliseconds here; it’s just one block included). It gets its security from the restaked operators and quorum assumptions. Check out more details here.
- Hard finality: This is when the aggregated proof gets verified by Ethereum contracts.
When it comes to a multi-vendor setup:
- Make sure to wire up at least two proving backends, like the Succinct SP1 Prover Network and the Lagrange Prover Network, and put them behind a queue. If one is running late, the other can jump in and handle the batch. Just remember, you’ll want deterministic proof compatibility for your on-chain verifier. More info can be found here.
As for on-chain verifiers:
- It’s smart to keep the verification contract upgradable with a timelock, or consider routing it through a proxy that can point to BN254 Groth16 for now. But don’t forget to explore alternatives only if they come with production-grade precompiles and security reviews. EIP-1108’s repricing helps explain why BN254 Groth16 remains the most cost-effective route on Ethereum. Dig deeper into the details here.

Worked example: picking a commit cadence

Assume the following:

Target P95 latency: 4 minutes
Average gas price (g): 5 gwei
Price per blob (p_blob): 3 wei
Cost to verify plus overhead (C_verify + C_overhead): 260,000 gas (Groth16)
Your codec produces about 8 bytes of pubdata for each transaction on average (make sure to measure yours!)

Compute:

Blob cost: Each blob costs 3 × 131,072 wei, which comes out to 393,216 wei, or about 3.93216e‑4 mETH.
If you're packing 16,000 transactions into a blob (that's 128 KiB divided by 8 B), the cost per transaction is roughly 24.6 wei, or about 2.46e‑17 ETH.
Now, let's check the cost per aggregate in ETH: 260,000 × 5 gwei equals 1,300,000 gwei, which is 0.0013 ETH.
If you’re aggregating K=12 blocks for each proof and averaging 1,500 transactions per block, you get around 18,000 transactions per aggregate.
- To confirm the cost per transaction, it's approximately 0.0013 divided by 18,000, which gives you about 7.22e‑8 ETH.

So, the total per-transaction Layer 1 settlement is around 7.22e‑8 ETH plus 2.46e‑17 ETH, which still rounds to about 7.22e‑8 ETH (just double-checking that this remains the dominant cost at this level of efficiency).

Decision:

Keep K around 12 with this traffic; make sure to commit every 2-3 minutes to keep P95 ≤4 minutes. If g spikes by 10×, consider bumping up K briefly or extending the window to 5-7 minutes, but maintain AVS attestations per block so dapps stay responsive. (blog.alignedlayer.com)

Where today’s infra is heading (so you can future‑proof)

Off-chain verification layers are really making waves by slashing per-proof gas fees by 90-99%. This shift is helping us achieve “soft finality” in just milliseconds, while still maintaining on-chain availability after only one block. We should also expect a wider variety of proof systems to gain traction beyond just Groth16 and Plonk, including ones like SP1, RISC Zero, and the Kimchi/Binius families. (blog.alignedlayer.com)
Proving times across the ecosystem keep getting shorter, with several teams hitting sub-10-second proving times on the right hardware for Ethereum blocks. However, it's still wise to plan for production service level objectives (SLOs) that expect minutes for recursive aggregation and “hard finality.” Think of those speedy numbers as something to aim for until your own process proves it out. (bravenewcoin.com)
Some networks and services, like zkVerify, are taking the concept of “verify once, attest everywhere” a step further with domain-based aggregation APIs and relayers. This approach can really help you avoid getting locked into a single-chain setup and lets you relay attestations across multiple L1 and L2 solutions. When implementing this, consider integrating their batching parameters (like aggregationSize and queueSize) into your own scheduling routines for smoother operation. (github.com)

Implementation checklist (copy/paste into your runbook)

In-contract:
- Let's add a pricing guard that reads BLOBBASEFEE (opcode 0x4a) and holds off on blob posting until T_burst when p_blob exceeds the threshold. Check it out here: (eips.ethereum.org)
- Make sure to emit events that clearly mark “soft vs hard” finality so that downstream apps know what's going on.
In your sequencer/aggregator:
- Set up dual triggers based on time (T_max) and size (either full-blob or N_proofs), adding hysteresis to keep things steady and prevent oscillation.
- Don’t forget to integrate your proof API’s “proof ready” webhooks, and have backup vendors lined up in case SLAs aren’t met.
- Keep the AVS attestation timing separate from the “hard finality” timing; batching attestations helps to keep gas costs low for each proof while ensuring everything remains readable within a single block. You can read more about it here: (blog.alignedlayer.com)
Observability:
- Track key metrics like blob utilization percentage, p_blob history, gas usage per aggregate, proof latency distribution (P50/P95/P99), and bridge wait times.
- Set up alerts for: empty-blob rates exceeding X%, missed T_max windows, AVS quorum delays, or any verifier reverts.
Governance:
- Make T_max, T_burst, N_proofs, and blob utilization targets adjustable through on-chain configuration with a timelock; also, let market integrators know about any upcoming change windows.

FAQ for executives

Why not just “commit every block” to get the best user experience?
- Well, it turns out that verification gas really takes over when you're looking at practical blob efficiencies. If you batch 8 to 16 blocks together, you can slash your cost per transaction by a huge factor, and it won't mess with your P95 latency as long as you keep those AVS attestations nice and tight. (blog.alignedlayer.com)
What happens if blob fees suddenly drop or shoot up?
- Blob fees operate in their own little world. Keep an eye on BLOBBASEFEE and adjust as needed. Over the past year, blob fees have usually hovered around the minimum, but they're pretty unpredictable, so it's smart to prepare for both ends of the spectrum. (eips.ethereum.org)
Is BN254 Groth16 “future-proof”?
- It’s still the most cost-effective option on Ethereum thanks to EIP-1108. Just make sure your verifier is swappable through a proxy; that way, if new precompiles or more affordable curves become the norm in the ecosystem, you can easily switch things up. (eips.ethereum.org)

Bottom line

The general rule is to commit the combined proof every 2-5 minutes, or whenever you’ve filled up a blob or hit your batch target--whichever happens first. For AVS attestations, keep things running on a tighter schedule (think every block or every 30-60 seconds) to create that “soft finality” while you work through the costs of “hard finality.” Don’t forget to tweak both settings using the live BLOBBASEFEE and proof‑readiness signals. This approach is the simplest way to provide great user experience, solid security, and predictable costs as we roll into 2026 market conditions. (eips.ethereum.org)

Sources and further reading

EIP‑4844: Check out the scoop on Shard Blob Transactions, covering everything from constants and pricing to throughput and gas accounting. (eips.ethereum.org)
Blocknative's Take on Blobs: They’ve got a solid breakdown of blobs including size, block targets, and retention info. (blocknative.com)
EIP‑1108: Dive into BN254 precompile repricing and get familiar with the pairing cost formula. (eips.ethereum.org)
BN254 Pairing Gas Breakdown: Here are some worked examples that make it easier to understand. (voltaire.tevm.sh)
ZKsync Docs: They discuss batch overhead and give you a window into the finality timeline. (docs.zksync.io)
Aligned Layer: This one covers AVS verification and aggregation with insights on throughput, gas, latency, and the security model. (blog.alignedlayer.com)
Nebra UPA: A deep dive into on-chain aggregation gas. (blog.nebra.one)
Succinct OP Book and Prover Network: They’re tackling production proving for the OP Stack. (succinctlabs.github.io)
Lagrange ZK Prover Network: Focused on decentralized proving with liveness, this one’s got some interesting insights. (lagrange.dev)
zkVerify Domain: Their mainnet is all about aggregating multi-chain attestations. (github.com)

7Block Labs is here to help you fine-tune those parameters to match your specific traffic profile, codec, and bridge SLOs. Plus, we’ll connect fallback proving providers so you can enjoy the benefits right from day one--without worrying about any operational hiccups down the line.