What a Rejected Bridge Deposit Can Cost

A rejected bridged deposit can cost the source-chain transaction fee, destination execution fees and any retry or swap charges the route has already incurred. The word “rejected” can describe several different failures: the source transaction may revert before the bridge accepts it, the bridge message may arrive but fail on the destination, or an application may refuse the credited asset. Each stage has its own accounting, and a failed destination action does not by itself tell you whether the principal is lost.

Cross-chain routes are asynchronous. A source-chain transaction can lock or transfer an asset and submit a message before the destination chain executes that message. The bridge’s contracts and the route’s failure rules determine what happens next. A Biswap cross-chain swap flow is a useful example of why the route’s stages matter: a transfer and a swap are separate operations, and a failure at one stage does not imply that earlier fees or actions are undone. The Biswap cross-chain swap flow and its hand-offs provide more detail on those steps.

Which costs are incurred before the destination rejects a deposit?

The source-chain transaction fee is usually the first sunk cost once the transaction is included, even if its execution reverts. That fee pays validators for processing the transaction; it is separate from the amount being bridged. If the source transaction fails before creating a bridge message or moving the asset, the principal may remain in the sender’s wallet, but the fee is still spent.

If the source transaction succeeds, it may also pay a bridge or messaging fee. Some routes use a relayer or message service, while others rely on destination-chain contracts to execute a message submitted from the source. The route can charge for submitting that message even if the destination call later fails. A swap route may add another execution step on either chain. These charges are not a single universal “bridge fee”: the route’s quote and transaction data determine which operations were funded.

The useful accounting unit is each completed stage, not the route’s final status. Separate the costs into:

• Source-chain gas for the transaction that initiates the deposit.
• Bridge, messaging or relayer charges for delivering the cross-chain instruction.
• Destination-chain gas for an execution attempt or a later retry.
• Swap fees or price impact, if the route exchanged the asset before or after bridging.

What happens to the principal when destination execution fails?

The principal’s fate depends on whether the bridge holds it in escrow, mints a representation on the destination, or has a recovery path that sends it back. A destination contract can reject a call while the bridge message remains available for retry. Another design may record a failed transfer and require a separate refund transaction. A route may instead complete the bridge transfer but fail at a later swap, leaving the asset on the destination in its bridged form.

Arbitrum’s retryable tickets illustrate one specific design. A parent-chain message can create a ticket for child-chain execution. If automatic execution fails, the ticket can be redeemed again while it remains available. The ticket’s call value is escrowed, and the system refunds it to the designated call-value refund address if the ticket expires without succeeding. The submission fee has a different rule: it covers the cost of storing the ticket and is paid to the system when an initial attempt fails and a retryable ticket is created. These rules do not apply to every bridge, but they show why “deposit failed” is not enough to infer a refund.

Even when the principal is recoverable, recovery may require a separate action and its own transaction fee. The refund destination also matters. A route can return funds to a configured refund address rather than the original wallet, and a contract address may not be able to act on another chain in the way its owner expects. A successful recovery can therefore leave the user with the bridged asset at a different address, less the fees already consumed.

How can you tell what is recoverable?

Trace the initiating transaction and the destination message separately. A source transaction hash establishes whether the deposit was submitted and whether the source call succeeded. The bridge or messaging record shows whether a message or retry ticket was created. The destination receipt shows whether execution succeeded, reverted, or remains pending. A wallet balance alone may not expose an unredeemed ticket or a token held by a bridge contract.

Before retrying or sending a second deposit, identify the failed stage and the route’s refund parameters. Check the asset, destination address, refund address, ticket or message status, and any expiry rule. If the transaction reverted on the source chain, verify whether the asset transfer also reverted. If the source transaction succeeded, do not assume the principal is gone—or available—until the bridge’s state and recovery path are clear.

The practical answer is route-specific: a rejected deposit can consume gas and message fees while leaving its principal recoverable, or it can strand value until a retry or refund action completes. Treat the principal, execution fees and swap costs as separate balances. The route’s contract rules, rather than the word “rejected,” decide which ones come back.