Latency requirements for cross‑chain bridges: how to set SLAs without guessing

A practical playbook for decision‑makers to turn chain finality, relayer behavior, and protocol knobs into concrete, defensible latency SLAs for cross‑chain messaging and asset transfers. Includes chain‑specific numbers, emerging options like CCTP “Fast Transfer,” and implementation checklists.

Executive summary

Don’t pick a round number and hope. End‑to‑end bridge latency is the sum of source‑chain finality, observation/attestation, relay, and destination execution. Use verified finality figures (e.g., Ethereum ≈15 minutes to “finalized,” Solana ≈13 seconds to “finalized”), protocol‑specific behavior (IBC median ≈19 seconds; CCIP waits for source finality), and explicit trust‑tradeoff features (Arbitrum fast withdrawals; CCTP Fast Transfer) to set P50/P95/P99 SLA targets with error budgets and fallbacks. (ethereum.org)

1) What “latency” really means in bridging

When a user “bridges,” four distinct timers start and stop:

Source inclusion: the deposit or message is included on the origin chain.
Source finality: the point at which your protocol considers that inclusion economically irreversible.
Attestation and relay: watchers/oracles/relayers observe, attest, and deliver a proof/message.
Destination execution: the target chain verifies the proof and executes the mint/call/unlock.

Your SLA must specify both:

The measurement points (on‑chain events or commitment levels), and
The percentile (P50/P95/P99 or P99.9) and scope (per pair, per asset, per route).

2) Current hard numbers you can anchor to

Below are the pieces most teams mis‑estimate. Use them to bound your SLOs before you test and tune.

Ethereum finality: Blocks are 12‑second slots; checkpoint finality is achieved after two epochs. In practice, Ethereum’s “finalized” tag implies ≈15 minutes time‑to‑finality today. That’s your lower bound whenever your bridge or oracle waits for “finalized” on Ethereum. Single‑slot finality (12‑second target) is on the roadmap but not live. (blocknative.com)
Solana commitment levels: Slots target ≈400–600 ms; “finalized” blocks lag “confirmed” by roughly 32 slots, i.e., ≈13 seconds under healthy conditions. Your latency depends on whether your system accepts processed/confirmed or requires finalized. (solana.com)
Cosmos IBC (ICS‑20) reality: Median time to receive an IBC packet is ≈22 seconds from send to recv (≈19 seconds for a full packet lifecycle metric reported), though academic measurements across chains show averages ≈55 seconds due largely to relayer timing variance. Design SLAs around the 20–60 second band, not “instant.” (ibcprotocol.dev)
OP Stack (Optimism/Base) nuance: Chain finality (for transactions) happens once data lands in a finalized Ethereum block—typically ≈20–30 minutes. But the infamous “7‑day” delay is the withdrawal bridge’s challenge window, not chain finality. Deposits typically land in 1–3 minutes; withdrawals via the standard bridge take ≈7 days. (docs.optimism.io)
Arbitrum: Default withdrawal challenge period ≈1 week (configurable by L1 blocks). Optional “fast withdrawals” (committee/DAC‑style) can bring L2→L1 confirmations down to ≈15 minutes (or ≈15 seconds for certain L3 setups), with a trust trade‑off. (docs.arbitrum.io)
CCIP (Chainlink) end‑to‑end depends on the source chain’s finality; Chainlink publishes estimated finality times by chain (e.g., Ethereum ≈15 minutes, Arbitrum ≈17 minutes, OP ≈20 minutes; Avalanche and Solana sub‑second). If your CCIP route waits for source finality, your P50 can’t beat those figures. (docs.chain.link)
Wormhole guardrails: A 19‑guardian network signs VAAs once a selected “consistency level” is met (e.g., waiting for finality vs. a faster, less‑final state). Performance is usually bounded by the underlying chains, not the guardians. Your SLA needs to declare which consistency level you accept. (wormhole.com)

3) Turn those constraints into SLAs (with concrete examples)

Design pattern: SLA = source finality budget + attestation/relay budget + destination execution budget + headroom for percentiles.

Example A — Ethereum L1 → Base using CCIP

Assumptions: CCIP waits for Ethereum “finalized” (≈15 minutes), then posts a Merkle root and executes on Base. Base finality estimate ≈18 minutes in CCIP docs (i.e., driven by when it commits to L1 and that L1 gets finalized), but the dominant leg is the source (Ethereum). In healthy conditions you’ll typically see total times 18–25 minutes P95; set P99 closer to 30 minutes to absorb sporadic congestion. Document that this SLA is source‑finality bound. (docs.chain.link)

Example B — Solana → EVM via Wormhole (finalized consistency)

Assumptions: Wait for Solana “finalized” (≈13 s). Guardians sign and a relayer submits the VAA on the EVM target; on‑chain verification is a single transaction. End‑to‑end P50 ≈20–40 s in quiet periods; set P95 ≈60–90 s to tolerate sporadic RPC/relayer hiccups. If you choose a faster consistency level (pre‑finality), declare the extra reorg risk and shorten the SLA accordingly. (solana.com)

Example C — IBC (Cosmos chain A → chain B) via Hermes

Assumptions: Median ≈19–22 s; observed averages across varied routes ≈55 s. Publish SLA as P50 25 s, P95 60–90 s, highlighting that relayer queueing and fee markets on either chain dominate tails. Use Hermes’ telemetry (tx_latency_submitted) to enforce. (ibcprotocol.dev)

Example D — L2 (OP/Arbitrum) → Ethereum withdrawals

Canonical route: SLA should state “≥7 days + user action to finalize,” because that’s the security model. Offer a “fast‑exit” lane via a liquidity bridge for user UX; then the SLA splits:
- User receive time: 1–2 minutes typical with intent/liquidity bridges like Across (state the trust/economic assumptions).
- Protocol settlement time (relayer repayment): 60–120 minutes after UMA optimistic verification, unless disputed. Publish separate SLAs for user delivery vs. protocol settlement capital lock. (li.fi)

Example E — USDC with CCTP V2 “Fast Transfer”

CCTP V2 introduces a Fast Transfer Allowance that lets destinations mint USDC in seconds while Circle later reconciles after the burn finalizes on the source. SLA: P95 “seconds” for user receipt on supported routes; clearly disclose dependence on Circle’s allowance and the specific chains enabled. Keep a fallback to normal CCTP if Fast Transfer capacity is exhausted. (developers.circle.com)

4) Choose the right commitment/finality knobs

Ethereum/EVM: If you choose the “finalized” tag, you inherit ≈15‑minute latency on Ethereum. If you instead use block depth (e.g., 12–64 blocks) for “sufficiently safe,” document the reorg risk and reduce the SLA accordingly. CCIP’s published table clarifies which chains use tags vs. depth. (docs.chain.link)
Solana: Pick commitment levels deliberately—processed (fastest, riskier), confirmed (≈1s; low reorg risk), finalized (≈13s; safest). Your alerting and retries must respect the 60–90s transaction blockhash expiration nuances. (solana.com)
Wormhole: Specify the consistency level per route. Faster settings raise reorg risk on probabilistic‑finality chains; “finalized” reduces risk but adds seconds to minutes depending on the chain. (wormhole.com)
Arbitrum/OP Stack: Distinguish “transaction finality on L2” (minutes) from “withdrawal finalization on L1” (days). If you enable “fast withdrawals” on an Arbitrum‑based appchain, state the committee/DAC trust assumption in the SLA. (docs.optimism.io)

5) Writing SLAs that actually hold up

Here’s a concrete template you can adapt:

Scope
- Coverage: [routes] [assets] [protocols].
- Measurement: Start = source chain [event + commitment level]; End = destination chain [event + inclusion level].
Targets
- P50: X; P95: Y; P99: Z (declare per route).
- Availability: % of messages meeting P95 per 30‑day window.
- Error budget burn‑rate alerts at 2× and 5× (four‑hour and one‑day windows).
Exclusions
- Source or destination chain halts/finality failures; incompatible protocol upgrades; user‑action delays (e.g., finalization step on canonical bridge).
Trust calls (must be explicit)
- Which oracles/relayers/committees you depend on; which consistency/finality levels you accept; any liquidity providers or allowances used (e.g., CCTP Fast Transfer). (developers.circle.com)
Fallbacks
- Secondary route if primary route SLO is violated for N minutes; degradation plan (e.g., auto‑switch Solana commitment from finalized→confirmed during incident, with banners and risk notice).

6) Measuring the right things (with minimal guesswork)

Capture end‑to‑end stamps on‑chain:
- Source tx hash + block number/slot + commitment time.
- Destination execution tx hash + block time.
- Your relayer/attestor submit times.
Instrument relayers/oracles:
- For IBC, scrape Hermes’ tx_latency_submitted and backlog metrics per channel to catch stuck queues early. (hermes.informal.systems)
- For Wormhole, poll guardian RPC and track VAA observation→delivery times per route. Guardians heartbeat at 15‑second intervals—alert on missing heartbeats across a quorum. (wormhole.com)
Align with chain semantics:
- EVM: Query with the “finalized” tag when your SLA says “finalized.” Don’t approximate with latest. (docs.chain.link)
- Solana: Respect blockhash expiry windows and pick commitment consistently across preflight, submit, and status checks. (solana.com)
Percentiles matter: Publish P50/P95/P99. P99 is where relayer gas spikes, RPC hiccups, and chain congestion show up.

7) Emerging options to tighten your SLAs (and their trade‑offs)

CCIP V2 “Fast Transfer” for USDC: Seconds‑level settlement backed by a Circle‑managed allowance; great for user SLAs, but you must monitor allowance headroom and have a fallback to normal CCTP. (developers.circle.com)
Arbitrum fast withdrawals: Committee/DAC‑assisted confirmations down to ≈15 minutes (L2) or ≈15 seconds (certain L3s). This adds a trust layer—state it plainly. (docs.arbitrum.io)
Ethereum roadmap: Single‑slot finality would compress Ethereum’s ≈15‑minute bound to roughly a slot—SLA headroom if/when it ships. Keep your template parameterized by “source finality requirement” so you can upgrade without rewriting contracts. (ethereum.org)

8) Route‑by‑route SLA drafting kit

Use these concrete starting points and tune with your own P50/P95 measurements.

ETH L1 → OP Mainnet via CCIP
- Start: Ethereum tx “finalized.”
- End: CCIP OffRamp execution included on OP Mainnet.
- Targets: P50 18–22 min; P95 25–30 min; P99 35–40 min.
- Note: Source‑finality bound; destination variance small. (docs.chain.link)
Solana → Ethereum via Wormhole (finalized)
- Start: Solana “finalized.”
- End: postVAA execution mined on Ethereum.
- Targets: P50 30–60 s; P95 60–120 s.
- Note: Assumes healthy RPC and fees; tune relayer gas strategy.
Cosmos chain A → chain B (IBC Hermes)
- Start: packet send on A.
- End: recvPacket on B.
- Targets: P50 25 s; P95 60–90 s; P99 2–3 min on busy links.
- Note: Use Hermes telemetry per channel and budget for relayer restarts. (ibcprotocol.dev)
Arbitrum → Ethereum withdrawals (two‑lane)
- Canonical: “7 days + user finalize,” no change. P95 = 7d + 1h.
- Fast‑exit UX: P50 < 2 min user receipt; P95 5–10 min; P99 15–30 min.
- Note: Publish separate SLAs for user receipt vs. settlement. (docs.arbitrum.io)
USDC (CCTP V2 Fast Transfer)
- P50/P95: seconds on supported pairs, contingent on allowance.
- Note: Declare dependency and fallback to standard CCTP path. (developers.circle.com)

9) Engineering best practices that actually move your P95

Commitment‑aware polling:
- EVM: Poll finalized heads, not latest; backoff aligned to slot/epoch cadence to avoid spurious delays. (docs.chain.link)
- Solana: Always fetch recent blockhash at confirmed or finalized consistently with your submit path to avoid accidental expiry. (solana.com)
Relayer gas strategy:
- Pre‑fund destination gas wallets; model surge pricing; auto‑bump fees when P95 slips.
Parallelism without duplication:
- Multiple independent relayers reading from the same source with idempotent destination execution.
IBC relayer hygiene:
- Monitor Hermes backlog and tx_latency_submitted; run dual relayers on distinct providers; alert if backlog grows for N minutes. (hermes.informal.systems)
Configuration for trust‑speed trade‑offs:
- Arbitrum appchains: evaluate fast withdrawals with 3+ validators/DAC members, SLA ≥ underlying L1 finality (≈12–15 min on Ethereum). Publish the assumption. (docs.arbitrum.io)
User‑perceived latency vs. protocol settlement:
- For intent/liquidity bridges (e.g., Across), separate the UX SLA (seconds/minutes) from back‑office settlement windows (60–120 minutes, or 2‑hour liveness by UMA default). (li.fi)

10) Governance and communications

Public status page with route‑level percentiles, not just up/down.
Incident policy: If source finality degrades (e.g., L1 under attack), auto‑switch to safer commitments and relax SLAs with banners and API flags.
Change management: When enabling features like CCIP Fast Transfer or Arbitrum fast withdrawals, run a 30‑day shadow period and publish before/after percentiles.

11) Quick checklist (copy/paste)

For each route:
- Source chain commitment level and expected finality time documented.
- Protocol/bridge behavior documented (e.g., CCIP waits for source finality; Wormhole consistency level).
- Destination execution criteria and gas strategy set.
- P50/P95/P99 targets set; error budget policy defined.
- Fallback route/setting and user disclosure wired.
- Telemetry: end‑to‑end stamps; relayer and chain health; per‑route dashboards.

12) Why this is the “non‑guess” way to do SLAs

You anchor to chain‑published or protocol‑published finality and behavior (Ethereum ≈15‑minute finalized; Solana commitment semantics; IBC median behavior; CCIP’s chain table; Arbitrum challenge defaults and fast‑withdrawal guidance). (ethereum.org)
You separate UX from settlement (Across/UMA, CCTP Fast Transfer) and disclose trust assumptions with measurable fallbacks. (docs.uma.xyz)
You instrument the relayers and chains with their native metrics (Hermes; guardian heartbeats), so your P95 is observed, not inferred. (hermes.informal.systems)

Make these decisions once, write them down, and your bridge SLAs will survive audits, outages, and roadmap upgrades.

Notes and sources

Ethereum single‑slot finality page; Ethereum slot/epoch primer and ≈15‑minute current finalized bound. (ethereum.org)
Solana transaction confirmation and expiration (slot 400–600 ms; commitment levels; practical expiry windows). (solana.com)
Cosmos IBC latency (median ≈19–22 s) and Hermes relayer telemetry (tx_latency_submitted). Independent study shows ≈55 s average across routes. (ibcprotocol.dev)
OP Stack finality vs. bridge withdrawal delay; deposit/withdrawal timing guidance. (docs.optimism.io)
Arbitrum challenge period defaults and optional fast withdrawals (trust trade‑off, 15 minutes L2 / 15 seconds L3 guidance). (docs.arbitrum.io)
CCIP execution latency and chain‑by‑chain finality reference. (docs.chain.link)
Wormhole guardians and consistency/finality behavior. (wormhole.com)
CCTP V2 Fast Transfer allowance enabling seconds‑level settlement on supported routes. (developers.circle.com)

If you want, 7Block Labs can run a one‑week latency study on your exact routes and deliver route‑level P50/P95/P99 with configuration and fallback recommendations you can paste into contracts, dashboards, and customer SLAs.