Message expiry: why a bridge transfer can get stranded

A bridge transfer can expire after its source transaction succeeds, leaving the destination action blocked and your funds awaiting recovery. Expiry is a rule attached to a quote, order or message; it does not undo a transaction already recorded on the source chain. What happens next depends on where the route holds the funds and what recovery path its contracts support.

What expires when a bridge message expires?

Usually, a deadline limits when a relayer may fulfil the transfer or when a destination contract will accept its instruction. That can be different from the source-chain confirmation period: a transaction may be final on the source while verification, delivery or destination execution is still pending. For a useful overview of the relay bridge transfer flow, see this guide to using a relay bridge across chains; the key detail here is that sending and completing are separate steps.

Check the transfer record for the exact deadline and what it governs. A quote can expire before you submit the source transaction, while a fill deadline can expire after funds have been deposited. Those cases call for different actions, even if an interface labels both “expired.”

Why can funds stay stranded after expiry?

Expiry can stop a late fill without automatically returning funds. If the route escrowed tokens on the source chain, the contracts may need a separate refund transaction, settlement step or cross-chain cancellation message before you can reclaim them. If the destination call already failed after verification, the message may instead remain retryable under that protocol’s rules.

This is why “expired” does not always mean “refunded,” and “sent” does not mean “received.” The route’s design determines whether recovery is automatic, user-triggered or dependent on relayer settlement. Never submit a second transfer just because the first one has not appeared on the destination.

How do you check whether to retry or wait?

Trace the original transfer before acting: confirm the source transaction succeeded, then check whether the destination execution occurred and whether the route reports a refund or recovery step. Use the transaction hash and route’s status page or tracker, and compare the reported state with onchain transactions. Look for:

• A source transaction that deposited, locked or burned the asset.
• A destination transaction that executed the transfer or reverted.
• A refund or cancellation transaction returning funds to the stated address.

If the message is verified but execution failed, follow that route’s documented retry path; if the deadline passed before fulfilment, follow its refund process and wait for the return transaction. Watch the specific fill or message deadline shown for your transfer, then verify the recovery transaction on the chain where the funds are held.