What a Token Pause Does to Mantle Bridge Messages

A token pause can stop a Mantle bridge transfer before its cross-domain message is created, or make a message fail when the destination chain tries to execute it. Which outcome applies depends on the paused token contract, the direction of travel and whether the bridge transaction has already passed its token operation. A bridge message carries instructions between chains; it does not carry a token’s pause state with it.

On Mantle’s OP Stack bridge, the L1StandardBridge and L2StandardBridge handle token transfers, while the cross-domain messengers pass encoded calls between chains. A pause belongs to the token contract that enforces it. The Mantle Bridge route guide covers route selection and delays; the key distinction here is whether the token call fails before or during message execution.

Can a token pause stop a deposit before it becomes a message?

Yes. For an ERC-20 deposit from Ethereum to Mantle, the L1 bridge first calls the source token to move tokens into bridge custody, then sends a cross-domain message for the L2 bridge to finalize the deposit. If the token’s pause logic rejects that transfer, the Ethereum transaction reverts. Because the token transfer and message send occur in the same transaction, the revert rolls back both: there is no completed deposit and no pending message to relay.

This is different from an approval. An ERC-20 approval grants the bridge an allowance; it does not move tokens or create the bridge message. A successful approval followed by a reverting deposit leaves the allowance in place, but the user must resolve the token restriction before a new deposit can succeed.

The same ordering applies in reverse at the start of a withdrawal. On Mantle, the L2 bridge must perform the token operation and initiate the withdrawal message. If a paused L2 token blocks the bridge’s transfer or burn, that transaction reverts before the withdrawal is recorded. No withdrawal message reaches the L1 finalization stage.

What if the pause happens after the message is sent?

Then the source transaction can remain successful while destination execution fails. For a deposit, the L1 transfer and message may already be recorded when the L2 bridge tries to mint or release the corresponding token. If that L2 token is paused, its call can revert during message relay. The cross-domain messenger records a failed relay rather than treating the destination action as completed; the user’s L2 credit does not appear merely because the Ethereum transaction succeeded.

The message and token operation are separate checkpoints. A failed relay is not the same as a source transaction reverting, and it does not mean the destination token transfer happened. After the restriction is removed, the message may be retried through the messenger flow, subject to that message still being valid and the relevant contracts accepting it. Check the source transaction and destination relay status, rather than inferring completion from a wallet’s pending label.

For a withdrawal, the corresponding late failure can occur on Ethereum. The L2 withdrawal is initiated first; after the rollup’s proof and challenge process, the L1 bridge attempts to release the escrowed token. If the L1 token is paused at that point, its transfer can make finalization fail. The earlier Mantle withdrawal remains recorded, but the Ethereum recipient has not received the token. Finalization can be attempted again when the token call is permitted, following the bridge’s status and proof requirements.

So a pause can affect different stages:

• Before source transfer or burn: the transaction reverts and no bridge message is created.
• After source completion, before destination execution: the source transaction stands, while the destination call can fail.
• During L1 withdrawal finalization: the L2 withdrawal exists, but the escrow release can fail until the token allows it.
• After successful destination execution: a later pause can restrict subsequent token transfers without undoing the completed bridge message.

Does a pause on one chain pause the token on the other?

No, not automatically. The bridge does not copy arbitrary ERC-20 rules such as pausing, blacklisting or rebasing from an L1 token into its L2 representation. Mantle’s token and bridge audit explicitly notes that these features are not replicated unless the L2 token is designed to implement them. A pause on one contract therefore does not, by itself, set a pause flag on its counterpart.

This creates a practical edge case: a token may be transferable on one chain and blocked on the other. A deposit can lock the source asset but fail to create a usable destination balance if the L2 token rejects its finalization. Conversely, a token can be usable on Mantle while a pause on its L1 counterpart prevents a later withdrawal from releasing escrow. Whether a particular mapped token shares pause controls depends on its own contract design and administration, not on the message format.

For a stuck transfer, identify the direction, then inspect the source transaction receipt and the destination messenger’s relay result. If the source transaction reverted, there is no message to retry. If it succeeded but the destination relay failed, inspect the token call and pause state before retrying. A bridge message records an attempted cross-chain action; only successful destination execution completes that action.