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

A Handy Guide for Decision-Makers

This playbook is all about helping you nail down those latency SLAs for cross-chain messaging and asset transfers. We’ll dive into chain finality, relayer behavior, and protocol tweaks to turn complex ideas into clear, actionable steps.

What’s Inside?

• Chain-Specific Stats: Get the lowdown on numbers that really matter for each chain.
• Emerging Solutions: Check out new options like CCTP’s “Fast Transfer” that can speed things up.
• Implementation Checklists: Handy lists to keep you on track as you roll out your strategies.

With this guide, you'll have everything you need to create solid, defensible SLAs that work for you!

Executive summary

Don't just choose a round number and cross your fingers. End-to-end bridge latency involves a few key components: the source-chain finality, observation/attestation, relay, and then the execution on the destination side. Make sure to use verified finality figures--like Ethereum taking about 15 minutes to reach "finalized" status and Solana managing it in roughly 13 seconds.

Keep an eye on protocol-specific behaviors too--like IBC's median time being around 19 seconds and how CCIP waits for source finality before moving on. Don't forget about the trust-tradeoff features, such as Arbitrum's fast withdrawals and CCTP Fast Transfer. These insights should help you set realistic P50/P95/P99 SLA targets, complete with error budgets and fallback plans. (ethereum.org)

---

1) What “latency” really means in bridging

When a user bridges, four different timers kick off and then eventually stop:

• Source inclusion: This is when the deposit or message gets added to the original chain.
• Source finality: This is the moment when your protocol decides that this inclusion is economically irreversible.
• Attestation and relay: Here, watchers, oracles, and relayers keep an eye on things, confirm what's happening, and send over the proof or message.
• Destination execution: On the target chain, this step involves verifying the proof and then going ahead with the mint, call, or unlock.

Your SLA needs to clearly outline two main things:

• Where you’re measuring (like on-chain events or commitment levels)
• The percentile you’re targeting (like P50, P95, P99, or even P99.9) and the scope (whether it’s per pair, per asset, or per route).

---

2) Current hard numbers you can anchor to

Here’s a rundown of the common areas where teams tend to miss the mark. Check these out to help you set realistic SLOs before you dive into testing and tweaking.

• Ethereum finality: So, Ethereum operates with blocks that come in every 12 seconds, and we hit checkpoint finality after two epochs. In real terms, when you see Ethereum tagged as “finalized,” think about a timeframe of around 15 minutes for it to actually stick. That’s your minimum wait time whenever your bridge or oracle is looking for that “finalized” status on Ethereum. There’s an idea for single-slot finality (the 12-second goal) floating around on the roadmap, but it’s not live yet. (blocknative.com)
• Solana commitment levels: For Solana, we’re looking at slots targeting around 400 to 600 milliseconds. Blocks that are “finalized” actually lag behind “confirmed” ones by about 32 slots, which adds up to roughly 13 seconds when everything’s running smoothly. Your system's latency will depend on whether you're okay with processed/confirmed blocks or if you need those finalized ones. (solana.com)
• Cosmos IBC (ICS-20) reality: When you send an IBC packet, the median time to receive it is about 22 seconds. If we’re talking about the whole packet lifecycle, it’s closer to 19 seconds, but various studies across chains show an average closer to 55 seconds, mainly due to timing differences with relayers. So when you’re designing your SLAs, aim for that 20 to 60 seconds window, and skip the “instant” talk. (ibcprotocol.dev)
• OP Stack (Optimism/Base) nuance: Chain finality for transactions happens once the data lands in a finalized Ethereum block, usually taking about 20 to 30 minutes. But don’t confuse that with the notorious “7-day” delay--that's just for the withdrawal bridge’s challenge window, not the actual chain finality. You can expect deposits to show up in about 1 to 3 minutes, while regular withdrawals via the standard bridge can take about 7 days. (docs.optimism.io)
• Arbitrum: The default withdrawal challenge period is roughly a week (though you can tweak it using L1 blocks). There are optional “fast withdrawals” available (think committee/DAC-style) which can cut down L2→L1 confirmations to around 15 minutes, or even about 15 seconds for some L3 setups, with a bit of a trust trade-off. (docs.arbitrum.io)
• CCIP (Chainlink): The end-to-end timing for CCIP depends on how long it takes for the source chain to finalize. Chainlink does publish estimated finality times for different chains--like about 15 minutes for Ethereum, 17 minutes for Arbitrum, 20 minutes for Optimism, and Avalanche and Solana are down to sub-second. If your CCIP route is waiting on the source finality, your P50 results won't be better than those times. (docs.chain.link)
• Wormhole guardrails: Wormhole uses a 19-guardian network to sign VAAs once a particular “consistency level” is reached, like waiting for finality or opting for a quicker, less-final option. Generally speaking, performance is more hampered by the underlying chains than by the guardians themselves. It’s a good idea to clearly state which consistency level your SLA will support. (wormhole.com)

---

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

Design Pattern

When it comes to designing your system, the SLA (Service Level Agreement) can be broken down into a few key components:

• Source Finality Budget: This is all about how quickly and reliably you can finalize information from the source.
• Attestation/Relay Budget: Here, we’re looking at the resources you need for validating and relaying that information.
• Destination Execution Budget: This part covers what’s required to execute actions at the destination effectively.
• Headroom for Percentiles: Lastly, don't forget to leave a little wiggle room for those higher percentiles--it's crucial for handling peak loads.

By balancing these budgets properly, you'll create a robust system that can handle various demands while still meeting your SLA goals.

Ethereum L1 → Base using CCIP

• Assumptions: So, the way CCIP works is that it waits for Ethereum to reach a “finalized” state, which takes about 15 minutes. After that, it posts a Merkle root and executes on Base. According to the CCIP documentation, Base’s finality is estimated to be around 18 minutes. This is mainly influenced by when it commits to L1 and when that L1 gets finalized. Typically, in good conditions, you're looking at a total time of around 18-25 minutes for the P95, but if you want to be on the safe side, you might want to set the P99 closer to 30 minutes to account for occasional congestion. Just keep in mind that this SLA is bound by the source finality. Check out more details in the CCIP docs.

Solana → EVM via Wormhole (finalized consistency)

• What to Expect: First off, you’ll want to wait for Solana to be “finalized,” which takes about 13 seconds. Once that's done, the Guardians will sign off, and a relayer will handle submitting the VAA on the EVM side. The good news? On-chain verification is done in just one transaction.
• Timing: In quiet moments, the end-to-end P50 is around 20 to 40 seconds. If you want to be on the safe side, you can set P95 at approximately 60 to 90 seconds--this helps cover you for those times when RPC or relayer hiccups pop up unexpectedly.
• Go Faster?: If you're feeling bold and opt for a faster consistency level (pre-finality), make sure to acknowledge the extra risk of reorgs and adjust your SLA accordingly. You can check out more details over at solana.com.

IBC (Cosmos chain A → chain B) via Hermes

• Assumptions: The median time is around 19-22 seconds, while the average we've seen across different routes is about 55 seconds. We’re setting the Service Level Agreement (SLA) as P50 at 25 seconds and P95 between 60 and 90 seconds. It's important to note that the delays are often influenced by relayer queueing and fee markets on either chain. To keep everything in check, we’ll use Hermes’ telemetry data (specifically tx_latency_submitted). You can check out more about this here.

L2 (OP/Arbitrum) → Ethereum Withdrawals

• Canonical Route: Your Service Level Agreement (SLA) should mention “≥7 days + user action to finalize” since that’s the security setup we’re working with. To make things smoother for users, consider adding a “fast-exit” lane through a liquidity bridge. Here’s how the SLA will break down:
  • User Receive Time: Typically, you’re looking at about 1-2 minutes with liquidity bridges like Across (just keep in mind the trust and economic assumptions involved).
  • Protocol Settlement Time (Relayer Repayment): Expect this to take around 60-120 minutes post-UMA optimistic verification, unless there’s a dispute. It’s a good idea to have separate SLAs for user delivery versus the protocol settlement capital lock. For more details, check out li.fi.

USDC with CCTP V2 “Fast Transfer”

CCTP V2 is shaking things up with a new Fast Transfer Allowance! This means that destinations can mint USDC almost instantly while Circle sorts things out later after the burn is finalized on the source. Just so you know, the Service Level Agreement (SLA) aims for a P95 time of just “seconds” for user receipts on supported routes. It's important to clearly mention that this depends on Circle's allowance and which specific chains are enabled. And don’t worry, there’s still a fallback option to the regular CCTP if the Fast Transfer capacity runs out. Check out more details here: (developers.circle.com).

---

4) Choose the right commitment/finality knobs

• Ethereum/EVM: When you go with the “finalized” tag, keep in mind you’re looking at roughly a 15-minute wait on Ethereum. If you opt for block depth instead (like 12-64 blocks) to gauge “sufficiently safe,” make sure to note the risk of reorgs and adjust your SLA to fit. Check out CCIP's table that breaks down which chains are using tags versus depth. (docs.chain.link)
• Solana: Be intentional about your commitment levels--“processed” is the quickest but it's a bit riskier, “confirmed” takes about 1 second with low reorg risk, and “finalized” is around 13 seconds for the safest option. Don’t forget to factor in the 60-90 second expiration nuances for transaction blockhashes when setting up alerts and retries. (solana.com)
• Wormhole: It’s important to clarify the consistency level for each route. If you opt for faster settings, be aware that it could increase reorg risk on chains with probabilistic finality. Choosing “finalized” lowers that risk, but it can add anywhere from seconds to minutes depending on the chain. (wormhole.com)
• Arbitrum/OP Stack: Make sure to differentiate between “transaction finality on L2” (which takes minutes) and “withdrawal finalization on L1” (which can take days). If you switch on “fast withdrawals” for an Arbitrum-based appchain, you’ll need to outline the committee/DAC trust assumptions in your SLA. (docs.optimism.io)

---

5) Writing SLAs that actually hold up

Here’s a solid template you can tweak:

• Scope
  • Coverage: [routes] [assets] [protocols].
  • Measurement: We start with the source chain--think of it as the [event + commitment level]--and we finish off at the destination chain with the [event + inclusion level].
• Targets
  • For P50, we’re aiming for X; for P95, it's Y; and for P99, we're looking at Z (make sure to declare these for each route).
  • Availability: This is the percentage of messages that hit the P95 benchmark over a 30-day period.
  • We’ll set up alerts for the error budget burn-rate when we hit 2× and 5× (with four-hour and one-day windows).
• Exclusions
  • We’re not covering issues like source or destination chain halts or finality failures, incompatible protocol upgrades, and delays caused by user actions (think finalization steps on the canonical bridge).
• Trust calls (this part needs to be clear)
  • Be sure to specify which oracles, relayers, or committees you rely on; what levels of consistency and finality you’re okay with; and any liquidity providers or allowances you’re using (like CCTP Fast Transfer). You can find more info at developers.circle.com.
• Fallbacks
  • If our primary route misses the SLO for N minutes, we’ll jump to a secondary route; plus, we’ll have a degradation plan lined up (for example, automatically switching Solana commitment from finalized to confirmed during incidents, and we'll post banners and risk notices).

---

6) Measuring the right things (with minimal guesswork)

• Capture those end-to-end on-chain stamps:
  • Make sure to note the source transaction hash, block number or slot, and the commitment time.
  • Don’t forget the destination execution transaction hash and block time.
  • Keep track of when your relayer or attestor submits their times.
• Get your relayers and oracles in check:
  • For IBC, make sure to scrape Hermes’ tx_latency_submitted and backlog metrics for each channel. This way, you can spot any stuck queues before they become a bigger issue. (hermes.informal.systems)
  • If you’re dealing with Wormhole, keep an eye on the guardian RPC and monitor the VAA observation to delivery times for each route. Remember, guardians ping every 15 seconds, so set up alerts for any missing heartbeats across a quorum. (wormhole.com)
• Stay in sync with chain semantics:
  • For EVM, always query with the “finalized” tag when your SLA mentions “finalized.” Don’t just use the latest as a stand-in. (docs.chain.link)
  • In the case of Solana, be mindful of the blockhash expiry windows. Make sure you choose the commitment consistently across preflight, submit, and status checks. (solana.com)
• Percentiles are key: Share your P50, P95, and P99 stats. P99 is where you’ll really see those gas spikes, RPC hiccups, and chain congestion creeping in.

---

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

• CCIP V2 “Fast Transfer” for USDC: This feature offers super quick settlement times--think seconds! It’s backed by an allowance managed by Circle, which is awesome for meeting user service level agreements (SLAs). Just keep an eye on your allowance and have a backup plan in case you need to switch back to the regular CCTP. Check it out here.
• Arbitrum Fast Withdrawals: Thanks to some help from a committee or DAC, you can get confirmations as fast as about 15 minutes on Level 2 or even around 15 seconds on specific Level 3s. This adds a layer of trust--just saying it like it is! For more details, visit this link.
• Ethereum Roadmap: With single-slot finality on the horizon, we’re looking at shrinking Ethereum’s typical 15-minute wait down to just one slot. This could give you some SLA wiggle room when it finally rolls out. Make sure your template is flexible with the “source finality requirement” so you can easily update it without needing to rewrite your contracts. Dive into the details here.

---

8) Route‑by‑route SLA drafting kit

Start with these solid reference points and then adjust them using your own P50/P95 measurements.

• ETH L1 → OP Mainnet via CCIP
  • Start: Once the Ethereum transaction is “finalized.”
  • End: When the CCIP OffRamp execution shows up on OP Mainnet.
  • Targets:
    • P50: 18-22 min
    • P95: 25-30 min
    • P99: 35-40 min
  • Note: This is tied to source finality, and there's only a small variance at the destination. (docs.chain.link)
• Solana → Ethereum through Wormhole (finalized)
  • Start: Solana is “finalized.”
  • End: postVAA execution is mined on Ethereum.
  • Targets: P50 30-60 seconds; P95 60-120 seconds.
  • Note: This assumes that RPC and fees are in good shape; make sure to adjust the relayer gas strategy.
• Cosmos chain A → chain B (IBC Hermes)
  • Start: packet sent on A.
  • End: recvPacket on B.
  • Targets: P50 25 s; P95 60-90 s; P99 2-3 min on busy links.
  • Note: Make sure to use Hermes telemetry for each channel and keep some budget in mind for relayer restarts. (ibcprotocol.dev)
• Arbitrum → Ethereum Withdrawals (Two-Lane)
  • Canonical: Still sticking with “7 days + user finalize,” no changes here. Just so you know, P95 is around 7 days plus an hour.
  • Fast-Exit UX: For the user experience, P50 is under 2 minutes for receipt; P95 falls between 5 to 10 minutes; while P99 can take about 15 to 30 minutes.
  • Note: We’ll be publishing separate SLAs for user receipts versus settlement. You can check it out for more details here: docs.arbitrum.io
• USDC (CCTP V2 Fast Transfer)
  • P50/P95: Just a few seconds on supported pairs, depending on your allowance.
  • Quick Reminder: Make sure to declare your dependency and have a fallback to the standard CCTP path. Check it out here: (developers.circle.com)

---

9) Engineering best practices that actually move your P95

• Commitment-aware polling:
  • EVM: When finalizing polls, make sure you're checking the finalized heads, not just the latest ones. Also, align your backoff strategy with slot/epoch timings to dodge any unnecessary delays. (docs.chain.link)
  • Solana: Always grab the most recent blockhash at the confirmed or finalized stage, and keep this consistent with your submission process to steer clear of accidental expirations. (solana.com)
• Relayer gas strategy:
  • Think about pre-funding your destination gas wallets. Keep an eye on surge pricing, and don't forget to auto-bump fees when your P95 slips.
• Parallelism without duplication:
  • Use multiple independent relayers drawing from the same source while ensuring idempotent execution at the destination.
• IBC relayer hygiene:
  • Keep tabs on the Hermes backlog and the transaction latency submitted. It’s a smart move to run dual relayers using different providers, and set up alerts if the backlog starts to grow for a specified time. (hermes.informal.systems)
• Configuration for trust-speed trade-offs:
  • For Arbitrum appchains, check out fast withdrawals with at least 3 validators or DAC members. Aim for a service level agreement (SLA) that matches or is better than the underlying L1 finality--which is around 12-15 minutes on Ethereum. And make sure to share that assumption publicly. (docs.arbitrum.io)
• User-perceived latency vs. protocol settlement:
  • When dealing with intent/liquidity bridges (like Across), it's important to distinguish between the user experience SLA (which might be in seconds or minutes) and the back-office settlement times (typically between 60-120 minutes, or even a 2-hour liveness as per UMA’s default). (li.fi)

---

10) Governance and communications

• A public status page that shows route-level percentiles, going beyond just whether things are up or down.
• Incident policy: If source finality takes a hit (for instance, if L1 is under attack), automatically switch to safer commitments and ease up on SLAs using banners and API flags.
• Change management: When rolling out features such as CCIP Fast Transfer or Arbitrum fast withdrawals, implement a 30-day shadow period and share before/after percentiles.

---

11) Quick checklist (copy/paste)

• For each route:
  • Make sure to document the source chain commitment level and what the expected finality time is.
  • Keep a record of how the protocol or bridge behaves (like how CCIP waits for source finality or what the consistency level is for Wormhole).
  • Set up the criteria for executing on the destination and figure out the gas strategy.
  • Establish P50/P95/P99 targets and define the error budget policy.
  • Wire up the fallback route/setting and make sure users are informed about it.
  • Set up telemetry that includes end-to-end stamps, relayer and chain health, plus dashboards for each route.

---

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

• You base your approach on the finality and behavior of chain or protocol published data. For example, Ethereum’s finality takes about 15 minutes, Solana has its own commitment semantics, IBC tends to behave in a median way, CCIP has a chain table you can refer to, and Arbitrum provides guidance on challenge defaults and fast withdrawals. (ethereum.org)
• You keep user experience (UX) and settlement separate, using tools like Across/UMA and CCTP Fast Transfer. Plus, you’re transparent about trust assumptions and offer measurable fallbacks. (docs.uma.xyz)
• You make sure to monitor relayers and chains with their own native metrics (like Hermes and guardian heartbeats), so your P95 stats are tracked accurately, not just guessed. (hermes.informal.systems)

Make these choices once, jot them down, and your bridge SLAs will easily handle audits, outages, and any changes in the roadmap.

---

Notes and sources

• For a deep dive into Ethereum’s single-slot finality, check out their page here. It breaks down the Ethereum slot and epoch, plus gives you a quick peek at the current finalized bound--around 15 minutes. (ethereum.org)
• If you're curious about how Solana handles transaction confirmations and expirations, their documentation covers it well! You'll find that confirmations take about 400 to 600 ms, with some details on commitment levels and practical expiry windows. (solana.com)
• Over on the Cosmos side, there's some interesting info about IBC latency. The median is around 19 to 22 seconds, and the Hermes relayer telemetry notes the tx_latency_submitted. Plus, an independent study found the average latency across routes to be about 55 seconds. Check it out! (ibcprotocol.dev)
• If you're looking at OP Stack, you'll want to understand the difference between finality and bridge withdrawal delays. They've got some guidance on the timing for deposits and withdrawals too. (docs.optimism.io)
• For those using Arbitrum, you might want to know about their challenge period defaults and the option for fast withdrawals. There’s a bit of a trust trade-off here, with guidance saying to expect around a 15-minute delay for L2 and just 15 seconds for L3 withdrawals. (docs.arbitrum.io)
• Chainlink's CCIP execution latency and the finality specifics for different chains are covered in their docs, which can be super helpful if you’re implementing cross-chain transactions. (docs.chain.link)
• Interested in Wormhole? They explain how their guardians work and the consistency and finality behavior you can expect. Definitely worth a read! (wormhole.com)
• Lastly, the CCTP V2 allows for fast transfers, making seconds-level settlements possible on supported routes. It's pretty neat! (developers.circle.com)

---

If you're interested, 7Block Labs can conduct a one-week latency study tailored to your specific routes. We'll provide you with detailed route-level P50/P95/P99 data along with configuration and fallback suggestions that you can easily include in contracts, dashboards, and customer SLAs.