What Happens When a Bridge Token Callback Fails

A bridge token callback fails when the destination contract receives a cross-chain message but cannot complete the requested action. The source contract may already have locked or burned the tokens and recorded a message for the destination. A relayer or validator then helps deliver that message, and the destination contract checks it before calling the receiver’s function. The failure can happen at that final step, after the cross-chain message has arrived.

What does a bridge token callback do?

A callback tells a destination contract what to do with tokens or data after a bridge message is verified. The bridge may mint or release tokens, then call a function on the receiver, such as one that deposits the tokens into a lending position. The bridge message and the receiver’s function are separate moving parts, even if one transaction triggers both.

For a fuller account of the route and direction, see this manta bridge route and direction guide. The key distinction here is between delivering the message and successfully running the receiver’s function. Think of a delivery arriving at a building: arrival does not mean the person inside has accepted the package.

Why can a callback fail after delivery?

The receiver’s function can reject the call or run out of gas, leaving the requested action incomplete. A receiver may reject a token it does not support, require a minimum amount, or expect data in a particular format. Its state may also have changed between the time the source transaction started and the callback arrived.

What happens next depends on the bridge’s design. Some systems treat token release and callback execution as one atomic operation: if the callback reverts, the whole destination transaction reverts. Others record token delivery separately from the callback, so tokens may be available even though the follow-on action failed. A failed callback does not by itself tell you which case applies.

How can you check whether a failed callback can be retried?

Check the source transaction and the destination message status before taking another action. The source transaction shows whether the bridge accepted the transfer. The destination record or transaction shows whether the message was delivered and whether the callback reverted. A revert reason, when available, can point to a receiver rule or gas limit that needs attention.

• Find the bridge message identifier in the source transaction or bridge interface.
• Check whether the destination message is pending, delivered, or marked failed.
• Read any callback error and confirm whether the tokens were released or minted.
• Use the bridge’s documented retry path only if the message is retryable.

Do not resend the source transfer just because the receiver’s action failed; that can create a second transfer. If the message is retryable, the fix may be to adjust the receiver or supply valid callback data, then retry that message. If the bridge marks the message as final, use its stated recovery process. The practical takeaway is to track token movement and callback execution as separate states: a transfer can progress while the action it was meant to trigger remains unfinished.