Why a Bridge Refund Can Need Another Message

A bridge refund can require a second cross-chain message because the source chain cannot simply reverse an action recorded on another chain. A route may first lock or burn the sender’s asset, then ask a destination contract to release or mint the corresponding asset. If that second step fails, the bridge must establish what happened and tell the source contract what it is allowed to do next.

The moving parts are the source contract, which handles the original asset; the destination contract, which handles the receiving side; and the bridge’s message system, which carries instructions or proofs between them. A delay or failure in one part does not automatically erase the others. For a route-specific comparison of how these choices affect a transfer, see manta bridge. The key distinction is whether the route can verify a refund condition on the source chain itself or needs a message from elsewhere.

Why can’t the bridge just reverse the transfer?

A blockchain records actions in order; it does not provide a general undo button. Once the source contract has locked or burned an asset, a refund is a new permitted action, not deletion of the original one. The contract needs a rule that says when a return is valid and a way to verify that rule.

That rule matters because a delayed transfer may still complete. If the source contract returned the original asset while the destination contract also released the bridged asset, the sender could end up with both. In some routes, a timeout lets the source contract refund after a defined wait. In others, the bridge requires proof that the destination action failed or never occurred. The details depend on the route’s contracts and message design.

What does the second message do?

In a message-based route, the refund instruction is a separate event that must be carried back and accepted by the source contract. Think of it like a return slip: the first message requests delivery, while the second carries the information needed to authorize a return. The sequence can look like this:

• The sender submits a transfer to the source contract, which locks or burns the asset and records the request.
• The bridge’s validators or other verification mechanism check the source event and pass a message toward the destination contract.
• If delivery cannot complete under the route’s rules, a failure proof or refund instruction may need to travel back.
• The source contract checks that instruction against its rules, then releases the locked asset or enables another refund step.

The exact roles vary. A relayer may carry a message, while validators or another verification system determine whether it is valid. Carrying the message and validating it are different jobs. If a message is delayed, the refund can remain pending even when the destination transfer has failed.

What should you check when a refund is pending?

Check the route’s transfer status and the transaction records on both chains. Look for whether the source action completed, whether the destination action executed, and whether a refund message was created, delivered, or rejected. A source transaction hash alone may confirm only the first step.

Some routes let a user trigger or claim a refund after the contract’s conditions are met; others handle the return through the bridge’s message flow. Follow the route’s stated process and avoid submitting a second transfer just because the first is slow. The practical takeaway is simple: a refund may be a new cross-chain operation, with its own proof, delivery, and execution steps.