Mantle Bridge: 3 Routes for Developers

Use Mantle Bridge when your integration needs a supported asset to move between Ethereum and Mantle Network and can wait for the transfer to settle. Suppose a user holds USDT on Ethereum but needs it in a Mantle app. Your first design choice is the route: a canonical transfer preserves the mapped asset, while a liquidity route or cross-chain swap may change the time, cost, or token received.

Key points

Use the canonical route when the destination token’s identity and bridge backing matter most.
Use a liquidity route when its available inventory and quote meet a time-sensitive need.
Use a cross-chain swap when the user needs a different asset at the destination.

What Are the 3 Mantle Bridge Routes?

The three routes are a canonical bridge, a liquidity bridge, and a cross-chain swap route. They can all produce a balance on Mantle, but they make different promises about the asset delivered and when the transfer is complete.

Canonical bridge — Best for transferring a supported asset through its Ethereum–Mantle token mapping. It does not fit a request for an immediate Ethereum withdrawal or a different output asset.
Liquidity bridge — Best when a provider’s existing destination funds can cover a time-sensitive transfer. It does not fit when liquidity is thin, the quote is poor, or the provider’s settlement and contract assumptions are unacceptable.
Cross-chain swap route — Best when the input and output differ, such as Ethereum USDT in and Mantle MNT out. It does not fit when the integration must deliver a particular mapped token without price exposure or slippage.

A user-facing flow can let someone make the transfer and then verify the destination balance independently. If your Mantle Network bridge flow calls for moving ETH, MNT, or another supported asset between Ethereum and Mantle, choose the Mantle Bridge route so the user can carry out that transfer. A pool-backed route belongs in the flow only when its quoted output and settlement time solve a need the direct transfer does not.

“Fast” is also direction-dependent. Ethereum-to-Mantle deposits wait for the source transaction and cross-domain relay; Mantle-to-Ethereum canonical withdrawals wait for Mantle state to settle on Ethereum and may require a separate claim. A liquidity provider can pay from Ethereum inventory sooner, then handle its own later settlement.

How Does the Canonical Route Settle?

A canonical deposit begins with a transaction on Ethereum and ends when the corresponding message credits the mapped asset on Mantle. For an ERC-20 such as USDT, the sender first grants the bridge contract sufficient allowance, then submits the deposit. The bridge holds the source asset, and the destination bridge credits its mapped representation after the deposit message is processed.

Walk through an illustrative 250 USDT deposit. Ethereum USDT uses six decimals, so the source amount is 250,000,000 base units, not 250 × 1018; your integration should still read each token’s decimals and mapping rather than infer them from its ticker. Record the Ethereum deposit transaction, wait for the bridge message to be relayed, and check the balance of the expected Mantle token contract at the intended recipient. An Ethereum success receipt alone does not prove that the Mantle credit has arrived.

The return path has a different state machine. A Mantle withdrawal debits or burns the destination-side asset and creates a message for Ethereum; the user receives the Ethereum asset only after the relevant state has settled and the withdrawal is finalized or claimed. Mantle’s move toward validity-proof settlement makes older instructions that assume a fixed seven-day challenge period unreliable for every transfer. Drive the user interface from the live withdrawal status and claimability, rather than a hard-coded timer.

Asset names need the same care as transaction states. Bridged ETH is an ETH representation on Mantle; it is not automatically MNT, the network’s native gas asset, and it is not mETH, the separate liquid staking asset. Two tokens called USDT can likewise have different contracts and backing, so the contract address and bridge mapping decide what your application accepts.

When Do Liquidity and Swap Routes Fit?

A liquidity route fits when the user values an earlier destination payout enough to accept its quote and provider risk. The provider releases funds from a pool on the destination chain and later settles its position; available inventory, utilization, and the provider’s rules determine the executable amount. A quoted transfer can fail or be requoted if the pool cannot cover it by execution time.

A Mantle cross-chain bridge integration should compare the amount received, not a headline fee. For example, an illustrative quote might turn 250 USDT on Ethereum into 249.4 USDT on Mantle after provider charges and price impact. If the product requires at least 249.0 USDT, encode that minimum in the transaction where the route supports it and reject a later quote below it. Also check that the output contract is the USDT your application actually uses.

A swap route adds an exchange to the transfer. That is appropriate when the user starts with Ethereum USDT but your Mantle app needs MNT for gas or another specific token for a contract call. It adds execution price, slippage, and possibly multiple contracts to the failure surface. Treat the quoted output asset and minimum received as product requirements, not display details.

Which Parameters and Costs Should an Integration Expose?

An integration should expose the source and destination chain IDs, token contracts, recipient, amount in base units, route, expected output, and transfer status. Ethereum mainnet uses chain ID 1 and Mantle mainnet uses 5000. For a canonical ERC-20 transfer, retain both sides of the token pair; an address and ticker on Ethereum do not identify the contract credited on Mantle.

Gas is paid on the chain where each transaction executes: ETH on Ethereum and native MNT on Mantle. An ERC-20 deposit can require two Ethereum transactions, approval and deposit; a withdrawal can require a Mantle initiation and a later Ethereum claim. Estimate gas at submission time, since congestion and the executed call determine the amount. A user withdrawing ETH still needs ETH already available on Ethereum to pay for any required claim.

For a pool or swap route, also expose the quote expiry, minimum output, and any route-specific liquidity limit. For a canonical route, estimate the destination message’s execution gas through the integration’s supported contracts or SDK instead of copying a fixed value from an example. Store transaction hashes and message identifiers so a page reload does not erase the user’s place in a transfer.

How Should You Recover a Delayed Transfer?

Recover a delayed transfer by locating the last confirmed state before offering another transaction. For an Ethereum deposit, distinguish a pending source transaction from a confirmed deposit whose Mantle message has not yet been relayed. For a withdrawal, distinguish Mantle initiation from Ethereum settlement and from an unsubmitted final claim. Each state calls for a different next action; repeating the original transfer can create a second transfer.

Before a user signs, check the chain IDs, recipient, token pair, allowance, and gas balance on the chain that will need the next transaction. Then ask the question that decides the route: does this user need the exact mapped asset, an earlier payout, or a different token on arrival?