A relay bridge can deliver value in seconds to minutes on a fast-finality route or take roughly seven days for an optimistic rollup exit, depending on the source state the destination accepts. For a relay bridge crypto transfer, check the source-finality threshold and destination release condition before you sign.
What sets relay bridge wait time?
The wait is set by source finality, relay processing, and destination execution. A useful estimate is source inclusion plus the route’s required finality, proof or attestation production, destination inclusion, and any final claim transaction. “Sent” usually means only that the source transaction landed; it says little about when the recipient can use the funds.
On Solana, a route may accept confirmed commitment or wait for finalized commitment, commonly about 32 slots behind the newest confirmed block. At roughly 400 milliseconds per slot, that difference is around 13 seconds in normal conditions. Ethereum finality is closer to 13–15 minutes, so a route requiring a finalized Ethereum source block has a much longer floor even when its relayer responds immediately.
Optimistic rollups add a different clock for canonical exits to Ethereum: the dispute window on the posted state assertion, commonly around seven days. Sequencer confirmation and publication of transaction data are earlier milestones; neither makes an exit claimable. An application should expose the actual release milestone, especially if a relayer can deliver the message long before its proof can be executed.
Which settlement path changes the wait?
Three common paths produce different arrival times because they ask the destination to trust different evidence. The relay bridge security model follows that evidence, rather than the speed of the process carrying it.
-
Canonical optimistic exit. A source withdrawal burns or locks the asset, an assertion containing it is posted to Ethereum, and the dispute period runs. After confirmation, a relayer or user submits an inclusion proof and executes the claim. Expect roughly a week plus batching and claim time; paying more gas can speed the final transaction, but cannot shorten the dispute window.
-
Verified message delivery. A relayer carries the source event and either a consensus proof or a verifier committee’s attestation to the destination contract. The contract releases or mints only after its configured threshold is met. A fast-finality source can yield delivery in tens of seconds to a few minutes; a route requiring finalized Ethereum blocks starts with a roughly 13–15 minute floor. A committee attestation and an on-chain light client have different trust assumptions.
-
Liquidity-backed fast fill. A solver pays the recipient from inventory on the destination chain, then claims reimbursement after slower settlement completes. The recipient may see funds in seconds or minutes while the solver still faces days of rollup settlement. Check that the payout is final for the recipient, the quoted amount is available at the requested size, and the route has a defined refund or fallback if no solver fills it.
The direction matters as much as the chain pair. Depositing from Ethereum into an optimistic rollup need not wait through the rollup’s exit window; withdrawing to Ethereum usually does. Likewise, an optimistic messaging bridge can impose its own challenge period even when the source chain itself finalized quickly.
What will the route cost, and when will funds arrive?
A relay bridge quote combines source gas, destination execution gas, verification or relayer fees, and sometimes a liquidity spread. Canonical exits avoid paying for early liquidity but may require a separate Ethereum claim transaction. Fast fills charge for capital, inventory imbalance, and the risk of advancing funds before reimbursement; fees rise when the requested amount approaches available liquidity.
For example, suppose a 1,000-unit stablecoin withdrawal has a canonical seven-day exit and a fast-fill quote of 20 basis points. The spread is 2 units, before any separately charged source gas; an illustrative 45-second fill buys earlier recipient payout, not earlier final settlement of the underlying exit. Compare the amount received and every gas payment, since a small transfer can be dominated by a fixed destination execution cost.
There is no dependable universal fee in dollars: gas prices, payload size, destination gas limit, route utilization, and token representation all change the quote. For a liquid route, a spread of a few to tens of basis points is a useful planning range, while thin inventory can cost substantially more or yield no fast quote. Fetch a fresh quote immediately before submission and record its expiry, minimum received amount, and whether destination gas is included.
How should an integrator choose and monitor a route?
Choose the slow proof path when the application can wait and needs the destination contract to enforce the strongest available source-state guarantee. I would use a fast fill when the recipient needs usable funds promptly and the fee, liquidity limit, and payout guarantee are explicit. For high-value contract calls, I would also check whether “delivered” means destination inclusion or destination finality; those are different promises.
For crypto relay bridge flows, track source inclusion, required source finality, proof or attestation readiness, destination execution, and destination finality as separate states. Key each transfer by its source chain, transaction, log index or nonce, and destination chain; make the receiver idempotent so a relayer retry cannot credit twice. A stalled relayer should trigger a retry or manual proof path where supported, not a second source deposit.
Before sending, validate the destination token address, recipient, quote deadline, minimum output, and any route limit. A source transaction can succeed while destination execution reverts because the gas limit is too low or the recipient rejects the call; the recovery procedure then depends on the bridge contract’s retry and refund rules. The question to ask before acting is: which exact event makes this transfer usable for my recipient, and who bears the risk until then?