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

Short answer for decision-makers: with a well-engineered BLS aggregation pipeline, you can deliver sub-250 ms p50 end-to-end acknowledgement for in-region users and sub-600 ms p95 globally before on-chain settlement, with next-block settlement adding ~12 seconds and full finality ~12.8 minutes on Ethereum. Concrete budgets below, with exact crypto, networking, and on-chain verification costs you can plan for. (ethereum.github.io)

TL;DR description

If your users sign micro-transaction receipts with BLS12-381 and you aggregate them before settlement, the cryptography adds single‑digit milliseconds per 1k signatures, the network adds tens to low hundreds of milliseconds per region, and settlement adds one Ethereum slot (~12 s) for inclusion and ~12.8 minutes for finality if you settle on L1. Pectra (May 7, 2025) made on-chain BLS verification practical via EIP‑2537 precompiles; EIP‑7549 improved consensus aggregation, and EIP‑7691 raised blob capacity—together lowering on-chain verification and propagation risk. (blog.ethereum.org)

Why this matters now

Ethereum’s Pectra upgrade (activated May 7, 2025 at epoch 364032) shipped native BLS12‑381 precompiles (EIP‑2537), so verifying aggregate BLS signatures on-chain is finally fast and predictable in gas. If your aggregator settles proofs on Ethereum, that removes a major bottleneck. (blog.ethereum.org)
EIP‑7549 changed attestation structures to enable larger, more efficient on-chain aggregation—good signal that the ecosystem keeps optimizing for BLS‑style workflows. (eips.ethereum.org)
Target blob capacity increased to 6 (max 9) per block (EIP‑7691), improving data throughput for DA-heavy rollups that may be part of your multi-chain settlement path. (ethresear.ch)

The moving parts of latency (and what they cost)

Think of your end-to-end path as five segments. Each has tight, measurable bounds today.

User signing time (device or edge HSM)

With production libraries (e.g., blst, herumi/mcl, Chia’s C++), BLS12‑381 signing on commodity CPUs is ≈0.9–1.7 ms per signature; verification ≈1.9–3.4 ms; pure aggregation of signatures is ≈2–4 microseconds per add. These are measured wall-clock benchmarks on i7‑8550U; server CPUs are typically faster. (github.com)
Hash‑to‑curve is standardized in RFC 9380; implementations use optimized Simplified SWU mappings for G1/G2 with cofactor clearing, so production behavior is consistent across stacks. (ietf.org)

First‑mile network hop to an in‑region collector

In a single cloud region or metro, RTTs are usually 5–30 ms. Cross‑US is often 30–90 ms; US↔EU ~70–170 ms; EU↔APAC ~150–300 ms. (Representative inter‑region measurements.) (zhiguang.me)

Aggregation and (optional) verification at the collector/aggregator

Crypto math is not your bottleneck. With blst-class performance, adding 1,000 signatures into an aggregate takes ≈2–4 ms total; fast aggregate verification (same message, PoP) is ~2 pairings, typically a couple of milliseconds on modern CPUs. Aggregate verify of n distinct messages costs ~n+1 pairings—avoid it in the hot path. (github.com)
Proof‑of‑possession (PoP) at registration time is critical. It enables FastAggregateVerify for “same message” cases and avoids rogue‑key attacks. Do it once per key, not per transaction. (datatracker.ietf.org)

Uplink to the settlement path (L2 or L1)

Gossip and builder timing can add seconds at the tail. With proposer‑builder separation and MEV‑Boost timing games, propagation delays of up to ~3 s inside a 12 s slot have been documented; engineer for p99 jitter. (ethresear.ch)
If you post blob data (DA) instead of a simple transaction, consensus‑layer blob propagation averages around ~2 s, with long‑tail outliers beyond 12 s observed in field studies—relevant if your “micro‑transaction proof” includes DA. (migalabs.io)

Settlement and finality

Ethereum slot time is 12 seconds. Next‑block inclusion is a good optimistic target; full finality takes ~2 epochs ≈ 12.8 minutes as of January 2026. Single‑slot finality remains roadmap research. (ethereum.github.io)

Concrete latency budgets you can plan for

Below are realistic budgets (collector co-located in cloud regions, blst-class libraries, PoP at registration, and no per-signer verify on the hot path).

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

Cryptography
- Sign on device: 1–2 ms/user action (desktop‑class), budget 2–5 ms for mobile/edge. (Measured desktop values; mobile varies.) (github.com)
- Aggregate 256–1,024 receipts: ≈0.5–4 ms. (github.com)
Network
- User → collector: 5–30 ms typical RTT within a cloud region/metro. (zhiguang.me)
Acknowledge
- Fast path (no synchronous verify): p50 ≈ 40–80 ms; p95 ≈ 120–180 ms; p99 ≈ 250–400 ms.

B) Global users → nearest collector → global reducer (two‑hop) → acknowledgement

Network
- First mile (user→regional collector): as above.
- Collector→global reducer across continents: 70–170 ms (US↔EU) or 150–300 ms (EU↔APAC) RTT. (zhiguang.me)
Crypto
- Merge aggregates from 8–16 collectors: still ≈sub‑millisecond, crypto‑wise. (github.com)
Acknowledge
- p50 ≈ 120–220 ms; p95 ≈ 300–600 ms; p99 ≈ 800–1,500 ms.

C) Settlement on Ethereum mainnet (no DA, signature check on-chain)

With EIP‑2537, verifying a fast‑aggregate signature (same message, PoP) is a fixed set of pairing checks via precompiles—milliseconds on clients; on-chain gas is now practical and specified by the EIP. Target next‑block inclusion ≈12 s median under normal conditions; engineer for +0–3 s jitter. Finality ≈12.8 minutes. (eips.ethereum.org)

D) Settlement with blob DA (posting batches/receipts as blobs)

Expect ~2 s average blob propagation plus normal slot cadence for inclusion; add builder timing variance. If your micro‑proofs are time‑sensitive, use pre‑confirmations off‑chain and treat on‑chain blob inclusion as the settlement event. (migalabs.io)

What exactly are you aggregating? Two patterns, two latencies

Same‑message aggregation (fastest)

Pattern: users sign a common “batch root” or interval commitment; aggregator aggregates all signatures into one BLS sig.
Verify: 2 pairings with FastAggregateVerify if all public keys have PoP. This keeps compute and on-chain gas minimal. (datatracker.ietf.org)
When to use: pay‑per‑time window metering, joins/renews of streaming sessions, IoT “tick” receipts for a shared period.

Distinct‑message aggregation (heavier at verify)

Pattern: each user signs a unique message (e.g., per‑event micro‑payment). Aggregation still compresses bandwidth, but aggregate‑verify costs ~n+1 pairings (vs. 2n individually). Avoid full verify in the hot path; batch or sample off the critical path. (datatracker.ietf.org)
When to use: audit‑heavy receipts, per‑call billing where every message must remain distinct.

Data sizes you should budget

BLS12‑381 (Ethereum’s standard curve):
- Public key (G1): 48 bytes (compressed)
- Signature (G2): 96 bytes (compressed)
- Aggregate signature stays 96 bytes; you also carry a bitmap of participants (one bit per signer) when applicable. (ethresear.ch)

Example sizing:

1,024 receipts → 1,024×96 B = 98,304 B over the wire if you naïvely ship raw sigs; with registered keys and bitmap aggregation, the bundle sent upstream is 96 B (aggregate sig) + identity/bitmap (128 B if 1,024 signers) + one 32‑B batch root = ~256–512 B total. That’s a >99.5% reduction on the aggregation hop.

On‑chain realities after Pectra (2025–2026)

Precompiles make BLS verification cheap and predictable
- EIP‑2537 adds seven BLS12‑381 precompiles (G1/G2 add, MSM, pairings, map-to-curve). You can call them at 0x0b–0x11 in Solidity. The EIP also describes pairing pricing, enabling gas‑accurate budgeting. (eips.ethereum.org)
Attestation structure changes improve aggregation efficiency
- EIP‑7549 moves the committee index outside the signed attestation, enabling better on‑chain packing and fewer distinct messages to verify—an ecosystem‑scale endorsement of aggregation patterns. (eips.ethereum.org)
Blob capacity increased
- EIP‑7691 doubled target blobs per block (3→6; max 9), reducing DA congestion for L2s. Expect ≈2 s average blob propagation; leave headroom for long tails. (ethresear.ch)

Practical reference budgets (worked examples)

Sub‑200 ms user feedback, next‑block settlement

Setup
- Users in North America; aggregator in us‑east‑1 with an EU mirror; micro‑batch every 50 ms; same‑message signing with PoP.
Path
- Device sign 1–2 ms → 10–25 ms to regional collector → 1–2 ms aggregation/merge → immediate ack.
Expect
- p50 ack ≈ 60–100 ms; p95 ≈ 140–200 ms. Settlement: next block ≈12 s; finality ≈12.8 minutes. (github.com)

Global users, two‑hop aggregation, distinct‑message receipts (audit‑grade)

Setup
- 12 collectors (NA/EU/APAC), global reducer in EU; micro‑batch every 100 ms; distinct messages; off‑path batch verification.
Path
- Device sign 1–2 ms → 10–30 ms (local) → 90–170 ms (inter‑region) → 2–4 ms aggregate → ack.
Expect
- p50 ack ≈ 150–220 ms; p95 ≈ 350–600 ms; p99 up to ~1.5 s under inter‑region jitter. If posting blobs for DA, add ~2 s avg propagation on top of slot cadence for inclusion. (zhiguang.me)

On‑chain verification of an aggregate signature (same message)

Setup
- Contract verifies one aggregate signature per batch using 0x0f (pairing check) through EIP‑2537; FastAggregateVerify path (PoP).
Expect
- Deterministic pairings on-chain; inclusion target ~12 s; plan ±3 s MEV‑builder timing variance. Finality unchanged. (eips.ethereum.org)

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

Use Proof‑of‑Possession at registration time
- This unlocks FastAggregateVerify (2 pairings), minimizing both CPU and gas. Don’t recompute PoP in the hot path. (datatracker.ietf.org)
Prefer same‑message aggregation when business logic allows
- Signing a common batch root slashes verify cost from ~n+1 to a constant 2 pairings and shrinks calldata. (datatracker.ietf.org)
Split your pipeline into collectors and a reducer
- Run per‑region collectors over QUIC/TCP, then aggregate at a global reducer. The math is microseconds; your tail is inter‑region RTT.
Keep verification off the critical path
- For distinct messages, either sample‑verify in real time (e.g., 1–5% random sampling) or run full batch verifies asynchronously on the reducer. Expect ~milliseconds per thousand with batched pairings; prioritize auditability over hot‑path latency. (github.com)
Pre‑confirmations for UX, settlement for safety
- If you need sub‑second “it stuck” signals, use off‑chain pre‑confirmations from your aggregator or trusted builders, then settle on-chain. Vendors advertise ~200 ms pre‑confirm windows; treat as UX, not finality. (gate.com)
Size your micro‑batches to your network, not your cores
- Crypto isn’t the bottleneck; wire time is. For metro‑local flows, 128–512 receipts per batch keeps p50 under 100–150 ms while retaining 95%+ aggregation benefits.
Prepare for growth in blob throughput and changed consensus packaging
- Pectra already lifted blob capacity; EIP‑7549 reduces consensus‑layer overhead and changes how votes get packed. Design your proof formats to tolerate larger blocks and faster propagation over time. (eips.ethereum.org)

Key technical details you should anchor your design on

Signature/public key sizes for BLS12‑381 (Ethereum’s choice): 96‑byte signatures (G2), 48‑byte public keys (G1). That’s why aggregate signatures are such a win on bandwidth. (ethresear.ch)
Cost model for verification
- Basic verify is 2 pairings. Aggregate‑verify on distinct messages uses ~n+1 pairings; FastAggregateVerify (same message with PoP) reduces to 2 pairings. On-chain, that maps to a small, fixed set of precompile calls. (datatracker.ietf.org)
Ethereum timing you cannot escape
- 12 s slot time; 32 slots per epoch; ~2 epochs to finality ≈ 12.8 minutes as of 2026. If your product claims “instant settlement,” be precise: instant acknowledgement vs. L1 inclusion vs. finality are different milestones. (ethereum.github.io)
Propagation realities
- MEV builder timing games can steal up to ~3 s of useful time within a slot. Blob propagation averages ~2 s with heavy‑tail outliers. p95/p99 planning must account for it in busy periods. (ethresear.ch)

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

Registration service
- Accepts BLS public keys and PoPs; writes registry and key→account mapping.
Edge collectors
- Accept receipt messages; maintain rolling bitmaps; aggregate signatures per interval (e.g., 50–100 ms); emit SignedAggregateAndProof to reducer.
Global reducer
- Merges regional aggregates; runs sample/batch verification; persists append‑only logs; produces settle‑ready bundles.
Settlement adapter
- If verifying on-chain, call EIP‑2537 precompiles for pairings; otherwise store only the aggregate signature and publish data to DA (blobs) when needed. Inclusion target ~1 slot; monitor MEV jitter. (eips.ethereum.org)

SLOs you can set on day one:

Ack to user: p50 ≤ 150 ms (regional), p95 ≤ 400 ms (global).
Next‑block settlement success rate: ≥ 95% during non‑congested periods; fall back to block+1 with alerts when MEV timing exceeds 2.5–3 s. (ethresear.ch)

Final takeaways for decision‑makers

The crypto is already faster than your network. Aggregation cost for thousands of receipts is millisecond‑scale; focus on topology and batching.
Ethereum made BLS verification first‑class in 2025. If your business case benefits from authenticated aggregates on-chain, you no longer need L2‑only workarounds. (eips.ethereum.org)
Expect “ack” in <250 ms p50 and <600 ms p95 globally; add a single 12 s slot for inclusion and ~12.8 minutes for finality on L1. Engineer explicitly for 2–3 s propagation jitter at the tail during busy periods. (ethereum.github.io)

Sources and further reading

EIP‑7600 (Pectra meta EIP), activation epochs and EIP list; includes EIP‑2537 and EIP‑7549. (eips.ethereum.org)
Ethereum Foundation Pectra Mainnet announcement (activation May 7, 2025). (blog.ethereum.org)
EIP‑2537 precompiles: operations and pricing for BLS12‑381. (eips.ethereum.org)
EIP‑7549 attestation changes for better aggregation. (eips.ethereum.org)
IETF BLS signatures draft (aggregate verify and PoP) and RFC 9380 (hash‑to‑curve). (datatracker.ietf.org)
Benchmarks: AntelopeIO BLS12‑381 library (sign/verify/aggregate timings). (github.com)
Ethereum time parameters and finality. (ethereum.github.io)
Propagation/timing effects from builder games; blob propagation measurements. (ethresear.ch)
Typical inter‑region RTTs (planning upper bounds). (zhiguang.me)