What Latency Should I Expect if I Use a BLS Aggregator to Bundle Real-Time Micro-Transaction Proofs Before Settlement?

Quick Take for Decision-Makers

If you set up a solid BLS aggregation pipeline, you can achieve some impressive response times. For users in the same region, you’re looking at less than 250 ms for end-to-end acknowledgements. Globally, you can hit under 600 ms at the 95th percentile before settling on-chain. Just keep in mind that next-block settlement will add about 12 seconds, and full finality will take around 12.8 minutes on Ethereum.

Here are some concrete budget estimates, including specific costs for crypto, networking, and on-chain verification that you can plan around. Check it out here: (ethereum.github.io)

TL;DR description

If your users are signing micro-transaction receipts using BLS12-381 and you’re aggregating those before settling, here's the scoop: the cryptography only tacks on a few milliseconds--like single-digit milliseconds--for every 1,000 signatures. The network itself might add some time, usually in the range of tens to a few hundred milliseconds depending on the region. Then, when it comes to settlement, expect to spend about one Ethereum slot (that’s roughly 12 seconds) for inclusion, plus around 12.8 minutes for finality if you’re settling on Layer 1.

On May 7, 2025, Pectra made on-chain BLS verification a lot more doable with the introduction of EIP‑2537 precompiles. After that, EIP‑7549 improved consensus aggregation, and EIP‑7691 boosted blob capacity, all of which helped to reduce on-chain verification and propagation risks. You can read more about it here.

Why this matters now

Ethereum’s Pectra upgrade, which kicked in on May 7, 2025, at epoch 364032, introduced native BLS12‑381 precompiles (thanks to EIP‑2537). This means that verifying aggregate BLS signatures on-chain is now super quick and predictable when it comes to gas costs. If your aggregator is settling proofs on Ethereum, this really clears up a major bottleneck. Check out the details here.
With EIP‑7549, the attestation structures got a makeover, allowing for larger and more efficient on-chain aggregation. This is a solid sign that the ecosystem continues to optimize BLS‑style workflows. You can read more about it here.
The target blob capacity has been bumped up to 6 (with a max of 9) per block through EIP‑7691. This tweak really enhances data throughput for DA-heavy rollups that could be part of your multi-chain settlement route. For further insights, dive into the discussion here.

The moving parts of latency (and what they cost)

Picture your end-to-end path as being split into five segments. Each of these segments has clear, measurable limits right now.

User Signing Time (Device or Edge HSM)

When using production libraries like blst, herumi/mcl, or Chia's C++, signing with BLS12‑381 on regular CPUs usually takes about 0.9 to 1.7 milliseconds per signature. Verification comes in at around 1.9 to 3.4 milliseconds, while simply aggregating signatures is pretty quick at roughly 2 to 4 microseconds for each addition. These timings are based on wall-clock benchmarks from an i7‑8550U; you can generally expect server CPUs to be even quicker. (github.com)
The hash-to-curve process is standardized in RFC 9380. Most implementations use optimized Simplified SWU mappings for G1 and G2 with cofactor clearing, ensuring that the production outcomes stay consistent across different stacks. (ietf.org)

2) First‑mile Network Hop to an In‑Region Collector

When you're dealing with a single cloud region or a metro area, the round-trip times (RTTs) typically fall between 5 and 30 milliseconds. If you’re crossing the US, you’re looking at around 30 to 90 ms. Going from the US to Europe usually takes about 70 to 170 ms, and between Europe and APAC, it can be anywhere from 150 to 300 ms. These figures are just a peek at what inter-region measurements look like. You can check out more details here.

3) Aggregation and (optional) verification at the collector/aggregator

When it comes to crypto math, you’re not really hitting a wall here. Thanks to blst-class performance, bundling up 1,000 signatures into one big aggregate takes only about 2-4 milliseconds in total. For fast aggregate verification--when dealing with the same message and using Proof of Possession (PoP)--you're looking at around 2 pairings, which usually just takes a couple of milliseconds on modern CPUs. Keep in mind that verifying n distinct messages will cost you around n+1 pairings, so it’s best to steer clear of that in your hot path. (github.com)
Speaking of Proof of Possession (PoP), getting this sorted during registration is super important. It allows you to use FastAggregateVerify for cases where the messages are the same, and it really helps protect against rogue-key attacks. Remember, you only need to do it once for each key, not every single transaction. (datatracker.ietf.org)

4) Uplink to the Settlement Path (L2 or L1)

When it comes to timing with gossip and builders, you might find some delays creeping in. Proposer-builder separation along with MEV-Boost timing games can lead to propagation delays that can stretch up to around 3 seconds within a 12-second slot. It's a good idea to plan for p99 jitter. (ethresear.ch)
If you're thinking about posting blob data (DA) instead of just a simple transaction, you'll usually see consensus-layer blob propagation taking about 2 seconds on average. However, keep an eye out for those pesky long-tail outliers that can exceed 12 seconds, especially if your “micro-transaction proof” involves DA. (migalabs.io)

5) Settlement and Finality

Ethereum has a slot time of 12 seconds, which is great for getting the next block in. But if you’re looking for full finality, you’re looking at around 2 epochs, roughly 12.8 minutes as of January 2026. Just a heads up, single-slot finality is still in the research phase on the roadmap. You can check out more details here.

Concrete latency budgets you can plan for

Here are some practical budgets to consider (collector located right alongside cloud regions, top-notch libraries, Point of Presence (PoP) at registration, and no per-signer verification on the hot path):

A) In-region users → regional collector → immediate acknowledgement (pre-settlement)

Cryptography
- Signing on your device takes about 1-2 ms for user actions on desktop, but you might want to budget around 2-5 ms if you're on mobile or edge. (These are based on desktop measurements; mobile times can be a bit different.) (github.com)
- When aggregating 256-1,024 receipts, you're looking at roughly 0.5-4 ms. (github.com)
Network
- The round-trip time (RTT) from user to collector is usually around 5-30 ms if you're within the same cloud region or metro area. (zhiguang.me)
Acknowledge
- For the fast path where there's no synchronous verification, you can expect: p50 at about 40-80 ms; p95 around 120-180 ms; and for p99, it could be between 250-400 ms.

B) Global users → nearest collector → global reducer (two-hop) → acknowledgment

Network
- First mile (user→regional collector): Just like what we mentioned before.
- Collector→global reducer across continents: Expect round trip times (RTT) of about 70-170 ms for the US to EU and 150-300 ms for EU to APAC. You can check more details here: zhiguang.me.
Crypto
- Merge aggregates from 8-16 collectors: This process typically stays around sub-millisecond marks in terms of crypto. Take a look at this for further info: github.com.
Acknowledge
- Timing: For acknowledgments, p50 sits around 120-220 ms, p95 is about 300-600 ms, and p99 can go from 800-1,500 ms.

C) Settlement on Ethereum Mainnet (No DA, Signature Check On-Chain)

So, with EIP-2537, checking a fast-aggregate signature (same message, proof of possession) now involves a straightforward set of pairing checks through precompiles. This means we’re talking just milliseconds on the client side, and the gas costs on-chain are manageable and clearly defined by the EIP.

You can expect the target for next-block inclusion to be around 12 seconds on average, under normal conditions, but keep in mind there might be a bit of jitter, so plan for an extra 0 to 3 seconds. When it comes to finality, it's looking like about 12.8 minutes. You can dive deeper into the details on the official EIP page.

D) Settlement with Blob DA (Posting Batches/Receipts as Blobs)

You can expect an average blob propagation time of around 2 seconds, plus the usual slot cadence for inclusion. Don't forget to factor in some timing variance from the builders as well. If your micro-proofs are on a tight schedule, it’s a good idea to use off-chain pre-confirmations and consider the on-chain blob inclusion as the settlement event. Check out more details here.

What exactly are you aggregating? Two patterns, two latencies

Same-message aggregation (the quickest option)

Pattern: Users sign a common “batch root” or interval commitment, and the aggregator puts all those signatures together into one BLS signature.
Verification: It only takes 2 pairings with FastAggregateVerify, assuming all public keys have a Proof of Possession (PoP). This helps keep the computation and on-chain gas costs low. (datatracker.ietf.org)
When to use it: Great for pay-per-time window metering, joining or renewing streaming sessions, and for those IoT “tick” receipts during a shared timeframe.

Distinct-message aggregation (verify can be a bit heavier)

Pattern: Each user signs a different message--think of it like a micro-payment for each event. This method still cuts down on bandwidth, but keep in mind that verifying the aggregate can be costlier at about ~n+1 pairings compared to verifying 2n individually. To keep things efficient, try to stay away from full verification during the hot path; instead, consider batching or sampling off that critical path. (datatracker.ietf.org)
When to use: This approach is perfect for situations that involve lots of audits, like when you're dealing with receipts, or in cases of per-call billing where it’s crucial for every message to be unique.

Data sizes you should budget

BLS12‑381 (Ethereum’s standard curve):
- Public key (G1): 48 bytes (compressed)
- Signature (G2): 96 bytes (compressed)
- The aggregate signature is still 96 bytes; you’ll also need to keep track of a bitmap for participants (one bit for each signer) when it's relevant. (ethresear.ch)

Example sizing:

If you have 1,024 receipts, you’d be looking at 1,024×96 B, which totals about 98,304 B if you just ship raw signatures without thinking. However, if you use registered keys and bitmap aggregation, the total bundle you send upstream consists of 96 B for the aggregated signature, plus 128 B for the identity/bitmap (assuming 1,024 signers), and one 32-B batch root. That brings you to roughly 256-512 B in total. That's more than a 99.5% reduction for that aggregation step!

On‑chain realities after Pectra (2025-2026)

Precompiles make BLS verification cost-effective and straightforward
- EIP‑2537 introduces seven BLS12‑381 precompiles (like G1/G2 add, MSM, pairings, and map-to-curve). You can access them at 0x0b-0x11 in Solidity. This EIP also lays out pairing pricing, which helps you with precise gas budgeting. Check it out here.
Changes to attestation structure boost aggregation efficiency
- EIP‑7549 takes the committee index out of the signed attestation, allowing for better on-chain packing and cutting down the number of distinct messages that need verification. This is a solid win for aggregation patterns across the entire ecosystem. More info can be found here.
Blob capacity gets a nice bump
- EIP‑7691 has doubled the target blobs per block from 3 to 6 (with a max of 9), which should help ease DA congestion for L2s. You can expect about a 2-second average for blob propagation, so make sure to leave some room for those longer tails. Want to dive deeper? Check it out here.

Practical reference budgets (worked examples)

Sub-200 ms user feedback, next-block settlement

Setup
- Users are based in North America, with an aggregator located in us-east-1 and an EU mirror for backup. We're doing micro-batches every 50 ms, and all messages are signed using the same method with PoP.
Path
- The device signs in about 1-2 ms, it takes 10-25 ms to reach the regional collector, then we have 1-2 ms for aggregation and merging. After that, users get immediate confirmation.
Expectations
- We're looking at a p50 acknowledgment time of roughly 60-100 ms and p95 around 140-200 ms. For settlement, the next block should take about 12 seconds, while finality is expected in about 12.8 minutes. (github.com)

2) Global Users, Two-Hop Aggregation, Distinct-Message Receipts (Audit-Grade)

Setup
- We’ve got 12 collectors spread across NA, EU, and APAC, with a global reducer based in the EU. Everything’s running in micro-batches every 100 ms, focusing on distinct messages and using off-path batch verification.
Path
- The device signs in around 1-2 ms, then it takes about 10-30 ms for local processing. When we factor in inter-region travel, that jumps to 90-170 ms, followed by 2-4 ms for aggregation, before we finally get the acknowledgment.
Expectations
- You can expect the p50 acknowledgment to be roughly 150-220 ms. For p95, it’s around 350-600 ms, but if you’re looking at p99, it could stretch up to about 1.5 seconds, especially with some inter-region jitter thrown into the mix. Plus, if you’re posting blobs for DA, don’t forget to add an average of about 2 seconds on top of the slot cadence for them to be included. (zhiguang.me)

3) On‑Chain Verification of an Aggregate Signature (Same Message)

Setup
- The contract takes care of verifying one aggregate signature for each batch by using 0x0f (pairing check) through EIP‑2537, specifically the FastAggregateVerify path (PoP).
Expect
- We’re aiming for deterministic pairings on-chain, with an inclusion target of around 12 seconds. There’s a plan for a ±3 seconds variance due to MEV-builder timing. Don’t worry--finality remains unchanged. Check it out here: eips.ethereum.org

Emerging best practices (that actually move your p95/p99)

Use Proof‑of‑Possession at registration time
This lets you tap into FastAggregateVerify (which needs just 2 pairings), cutting down on both CPU and gas costs. Pro tip: don’t recompute PoP when you're in the hot path. (datatracker.ietf.org)
Prefer same‑message aggregation when business logic allows
When you’re signing a common batch root, you can slash verification costs from about ~n+1 to just 2 pairings, plus it reduces calldata. (datatracker.ietf.org)
Split your pipeline into collectors and a reducer
Set up collectors that run per region using QUIC/TCP, then gather everything at a global reducer. The calculations take microseconds - the real delays come from inter-region round-trip times.
Keep verification off the critical path
For messages that are distinct, think about sample-verifying in real-time (like doing 1-5% random checks) or running full batch verifications asynchronously on the reducer. You can expect around ~milliseconds for every thousand with batched pairings; make sure auditability is a priority over hot-path latency. (github.com)
Pre‑confirmations for UX, settlement for safety
If you need super quick “it stuck” signals, get off-chain pre-confirmations from your aggregator or trusted builders, then settle it all on-chain. Vendors typically promise ~200 ms pre-confirmation windows; think of this as user experience, not finality. (gate.com)
Size your micro‑batches to your network, not your cores
Remember, crypto isn't the slow part; it's the wire time. For metro-local flows, keeping 128-512 receipts per batch helps keep the p50 under 100-150 ms while still snagging over 95% of the aggregation benefits.
Prepare for growth in blob throughput and changed consensus packaging
Pectra has already boosted blob capacity, and EIP‑7549 is set to reduce consensus-layer overhead as well as tweak how votes get packed. So, make sure your proof formats can handle larger blocks and speedier propagation as things evolve. (eips.ethereum.org)

Key technical details you should anchor your design on

So, let's talk about the signature and public key sizes for BLS12‑381, which is what Ethereum is using: you've got 96-byte signatures (G2) and 48-byte public keys (G1). This is a big reason why aggregate signatures are such a game changer when it comes to bandwidth. (ethresear.ch)
Next up, the cost model for verification:
- A basic verification takes 2 pairings. If you're doing an aggregate verify on different messages, it bumps up to about ~n+1 pairings. But if you're using FastAggregateVerify (same message with PoP), that drops back down to just 2 pairings. On-chain, this translates to a small, consistent set of precompile calls. (datatracker.ietf.org)
Now, let's hit on Ethereum timing, which you really can't ignore:
- You've got a 12-second slot time and 32 slots per epoch, leading to around 2 epochs for finality, which is roughly 12.8 minutes by 2026. So, if your product is touting “instant settlement,” make sure you're clear about what that means: instant acknowledgment is different from L1 inclusion, and both are distinct from finality. (ethereum.github.io)
Finally, let’s talk about propagation realities:
- It's important to note that MEV builder timing games can snag up to ~3 seconds of useful time within a slot. Blob propagation generally takes about ~2 seconds, but there can be some heavy‑tail outliers. When you're planning for p95/p99, you've got to factor this in during busy times. (ethresear.ch)

A minimal reference architecture (you can pilot in 2-4 weeks)

Registration Service
- It handles BLS public keys and PoPs, writing down the registry and mapping keys to accounts.
Edge Collectors
- These guys accept receipt messages, keep rolling bitmaps going, and aggregate signatures every set interval (like every 50-100 ms). They then send a SignedAggregateAndProof off to the reducer.
Global Reducer
- This component merges the regional aggregates, carries out sample and batch verifications, keeps append-only logs, and creates those settle-ready bundles we need.
Settlement Adapter
- When verifying on-chain, it calls the EIP‑2537 precompiles for pairings; if not, it just stores the aggregate signature and holds onto the data to publish to DA (blobs) whenever it's required. The inclusion target is about 1 slot, and we keep an eye on that MEV jitter. (eips.ethereum.org)

SLOs You Can Set on Day One

Acknowledgment to User: Aim for p50 ≤ 150 ms (regional) and p95 ≤ 400 ms (global).
Next-Block Settlement Success Rate: Keep it at ≥ 95% during non-congested times. If MEV timing goes over 2.5-3 seconds, switch to block+1 and set up alerts. Check it out for more details: (ethresear.ch)

Final takeaways for decision‑makers

You’ll find that crypto is already outpacing your network. The aggregation cost for thousands of receipts is just in the milliseconds; so, let’s zero in on topology and batching.
In 2025, Ethereum really stepped up by making BLS verification a key feature. If your business can take advantage of those authenticated aggregates on-chain, you can say goodbye to those pesky L2-only workarounds. (eips.ethereum.org)
You can expect an “ack” in under 250 ms for p50 and less than 600 ms for p95 worldwide; just remember to include a single 12-second slot for acceptance and about 12.8 minutes for finality on L1. Make sure to plan for 2-3 seconds of propagation jitter during those busy times. (ethereum.github.io)

Sources and further reading

Check out EIP‑7600 (the Pectra meta EIP), which covers activation epochs and a bunch of EIPs, including EIP‑2537 and EIP‑7549. You can dive deeper here.
The Ethereum Foundation has made the announcement for the Pectra Mainnet, set to activate on May 7, 2025. Get the scoop here.
If you want to know about EIP‑2537 precompiles, including operations and pricing for BLS12‑381, head over here.
EIP‑7549 is bringing some cool changes to attestations to improve aggregation. Details can be found here.
The IETF has released a draft on BLS signatures (think aggregate verify and PoP) along with RFC 9380, which covers hash‑to‑curve. Check it out here.
Interested in benchmarks? Take a look at the AntelopeIO BLS12‑381 library--it includes timings for sign, verify, and aggregate operations. You can find it here.
For insights on Ethereum's time parameters and finality, you can explore the details here.
There are some fascinating insights on propagation and timing effects from builder games, along with blob propagation measurements. Discover more here.
Lastly, if you’re curious about typical inter-region RTTs for planning upper bounds, check it out here.