A destination deposit pause is a temporary block on accepting incoming funds or completing a deposit on the network or service a user chose. The key question is whether the pause happened before the source transaction was sent or after it became irreversible.
Model that distinction in your integration before you route a transfer. If your flow combines a bridge and a swap, quickswap versus bridge then swap describes the route choice; either design still needs a clear response when the destination cannot accept funds. quickswap can move and swap assets across chains in one flow, so check where a transfer is in that flow before deciding what to tell the user.
What does “deposits paused” mean for an in-flight transfer?
It can mean the destination chain is producing blocks but a particular exchange, custodian, or application has disabled deposits. It can also mean the chain itself is stalled or its RPC endpoint is unhealthy. Those cases have different remedies: a chain-level halt can prevent transactions from landing, while an application-level pause may leave the chain usable but block the intended deposit.
A cross-chain transfer usually has separate milestones: the source transaction is submitted and confirmed, a bridge or messaging layer verifies it, and a destination transaction is submitted and executed. A pause can occur between any two of them. For example, Axelar’s General Message Passing documentation describes a source call, validator approval, and a later destination execution; approval does not mean the destination application has already run.
Keep the status precise. “Source confirmed; destination execution pending” tells a user more than “failed,” and avoids implying that the funds have disappeared. For a swap route, distinguish the source asset being committed from the destination asset being delivered: they are different events.
What should the integration check before acting?
First identify who paused deposits and what exactly is paused. Check the destination’s own status or operator notice, then independently inspect recent blocks and the relevant transaction through a reliable node or explorer. A successful RPC response alone does not prove that the deposit contract is accepting transfers.
For Solana, for instance, the Solana RPC documentation defines processed, confirmed, and finalized as different commitment levels; a processed block can still be rolled back. Use the commitment required by your risk policy before marking source funds as settled, and verify the destination transaction separately. On other chains, apply that chain’s own finality rules rather than reusing Solana’s labels.
Then inspect the bridge or route’s message identifier and status. Is the source event observed? Has the message been approved? Was a destination transaction attempted and reverted, or has no transaction been submitted? These facts decide whether to wait, retry, or escalate. Never create a second transfer just because the destination deposit is taking longer than expected.
How should you handle funds already in transit?
When the source transaction is final but the destination is paused, preserve the existing transfer record and show it as pending. Poll the route’s authoritative status and the destination chain with backoff, while presenting a meaningful state and last-updated time. Set an operational timeout based on the service’s expected processing window; if it expires, open a recovery path rather than silently resubmitting.
Make retries idempotent: use the source transaction hash or protocol message ID as the unique key, and reject a second user request that would initiate the same economic action. If the destination transaction reverted, retry only through the protocol’s documented recovery mechanism and only after checking that the message remains executable. Some bridges allow an approved message to be executed later; others require different recovery steps.
Do not switch the destination address or route after the source action is committed unless the protocol explicitly supports that change. A safe fallback may be to keep the transfer pending until deposits reopen, or to offer a separately authorized recovery route if the protocol can prove control of the funds. The user must understand any new destination, asset, or price exposure before approving a distinct action.
What should change before you resume deposits?
Resume only after the destination’s operator or protocol indicates that deposits are accepted and your own checks confirm the chain is progressing. Test a small controlled transfer if the incident warrants it, then reconcile pending message IDs against destination execution records before releasing the backlog.
For example, before a pause your dashboard might show “complete” as soon as the source transaction confirms. Afterward, it should show “source confirmed; destination pending,” retain the same transfer ID, and update to “complete” only when the destination effect is verified. That small change prevents a delayed deposit from looking like a lost transfer—or from prompting a duplicate.
My default is to hold and reconcile an in-flight transfer, not to reroute it automatically. quickswap can provide the cross-chain move and swap in one flow, but the integration still owns accurate status, safe retries, and user communication when a destination pauses.