When a Mantle Bridge message fails, who pays?

A failed destination execution on Mantle does not automatically mean the deposit vanished or that the bridge pays every retry cost. On the canonical route, the sender pays for the Ethereum approval and deposit, while what happens next depends on whether the bridge message or a later Mantle transaction failed. That distinction matters: a confirmed source transaction and a completed destination action are separate events.

What happens when a Mantle deposit reaches its destination?

A canonical deposit moves an asset from Ethereum to its mapped representation on Mantle; it does not bundle a swap or an application call. The sender’s wallet submits the Ethereum transaction, so the sender pays its gas in ETH, along with any required token approval. The bridge message is then relayed to Mantle, where the balance becomes available if processing succeeds.

The Mantle Bridge cost breakdown covers the ordinary transaction steps; the key failure distinction is whether the deposit message itself was relayed. A pending message is not the same as a failed destination transaction, and a successful deposit does not prove that a separate action on Mantle also succeeded.

Who pays if destination execution fails?

For a plain deposit, the user has already paid the source-chain gas when the Ethereum transaction is included. If the bridge’s L1-to-L2 message reports a failure, do not assume that the source fee is refunded or that the destination asset is lost. Check the message status and the bridge’s available retry or recovery path before sending another deposit; the remedy depends on the message and contract state.

If the bridge has completed and the user then submits a transaction on Mantle—for example, to swap the received token—that transaction is a separate on-chain action. The wallet pays its gas in native MNT. A revert can still consume gas, even when the intended swap or call does not complete. In that case, the bridge did not cause the application transaction to fail and does not automatically cover its execution cost.

Routes that combine bridging with a destination swap or contract call add another fee arrangement. A provider may price destination execution into the quote, use a relayer, or specify a recovery process, but the user should read the route’s terms rather than assume those costs work like the canonical transfer. A faster, bundled route can save manual steps; it also adds provider and contract dependencies.

What should users check after a failure?

Start with the source transaction, then follow the cross-chain message to its destination status. This separates a transaction that never left Ethereum from a deposit waiting for relay, a failed relay, and a later Mantle transaction that reverted. The transaction hash and destination address are more useful than a wallet balance alone.

• Confirm the Ethereum transaction succeeded and note whether it was an approval or the deposit itself.
• Look up the corresponding message and check whether it is pending, relayed, or failed.
• If funds arrived on Mantle, check the separate transaction that tried to use them and its revert details.
• Use the bridge or route’s documented retry process; do not repeat the deposit just because the balance has not appeared yet.

The practical rule is to treat bridge delivery and destination execution as separate jobs with separate fee risks. Watch the message status, any retry instruction, and whether the destination action was actually submitted. Those signals show who paid, what remains to be done, and whether another transaction is necessary.