To use Manta bridge, check the route, then track the source and destination transactions. A transfer may be waiting for source-chain confirmation, bridge processing, or destination settlement; each calls for a different check. Choose the receiving network and asset before sending, compare the amount you will receive, and submit the transfer only once.
What happens between the two chains?
A Manta bridge transfer starts with an action on one blockchain and ends when value becomes available on another. The coins do not literally travel between chains. Depending on the route, the source asset may be locked, burned, or exchanged, while an asset is released or delivered at the destination. Ethereum.org describes lock-and-mint, burn-and-mint, and swap-based designs.
That sequence explains why a confirmed deposit does not always mean the transfer is finished. The bridge may still be waiting for enough source-chain confirmations or for its destination transaction to settle. A swap adds another decision: you must specify the asset you want to receive, rather than assuming it will be the same asset on a new chain.
What should you decide before sending?
Decide the exact source chain, destination chain, asset, and recipient before comparing routes. “USDC on Ethereum” and “USDC on Solana” name balances on different networks; the receiving wallet or service must accept the intended token on the intended chain. Check the token identity as well as its ticker, since assets with similar names can be issued by different contracts.
For a Manta bridge Bitcoin to Ethereum move, timing depends heavily on the Bitcoin deposit. The Bitcoin Developer Guide puts the average time to one block confirmation at about 10 minutes, and a route may wait for several confirmations before acting. A liquid route between faster chains may finish in minutes, while congestion, confirmation requirements, or limited destination liquidity can extend the wait to hours.
Compare the quoted amount received, not only a stated bridge fee. The difference can include source-chain gas or miner fees, a bridge or liquidity fee, destination execution costs, and, if you change assets, the exchange rate and price impact. For example, if you send $100 worth of an asset and the quote shows $98.80 arriving, the $1.20 difference is the useful figure to compare with another route. Keep enough of the source chain’s native coin to pay for the transaction.
How do you complete the transfer?
Complete the transfer by checking the route, approving its cost, sending once, and verifying the destination balance. Work through these steps even if an earlier attempt failed: the failed transaction’s state determines which step you need to repeat.
-
Check your wallet’s current network and available balance. This establishes where the funds actually sit and whether you have enough native coin for network fees. If you hold USDC on an Ethereum layer 2, selecting Ethereum mainnet as the source describes a different balance.
-
Set the destination network, receiving asset, and recipient address. Check that the recipient can use that network and asset before sending, because a correct address on the wrong chain may still leave the funds inaccessible in the intended wallet. For a first transfer to a new recipient, a small test amount can establish that the route and address behave as expected.
-
Choose whether the asset should stay the same or change on arrival. A Manta bridge swap is relevant when, for example, you hold USDC on Ethereum but want SOL on Solana. Choose Manta bridge over a separate bridge transfer and later swap when you need the chain move and asset exchange handled in one flow. Check the receiving asset in the quote before committing.
-
Review the quoted output, estimated time, and any minimum amount you may receive. A swap’s price impact can grow when the order is large relative to available liquidity, so two routes with similar stated fees can deliver different amounts. If the quote expires or changes before you send, review the new figures rather than relying on the earlier estimate.
-
Submit the source transaction once and save its transaction hash. The hash lets you check whether the source chain has seen and confirmed the payment. A wallet message saying “sent” may mean only that it broadcast the transaction; it does not prove the bridge received a confirmed deposit.
-
Check the destination wallet on the intended network after the source deposit confirms. Look for the received token and, where available, the destination transaction hash. If the transaction succeeded but the balance looks unchanged, check that the wallet is showing the correct network and token before sending again.
What should you do if it is pending or failed?
Find the last confirmed stage before taking another action. For a pending Manta bridge transaction, start with the source-chain hash in that chain’s block explorer. If it has no confirmation, the bridge may have nothing to process yet; a low network fee or congestion could be the cause. On chains that support transaction replacement, use your wallet’s replacement or cancellation method only after checking the original transaction’s status.
If the source transaction failed or reverted, check your wallet balance before trying again. A reverted contract transaction usually leaves the asset in your wallet, though the network fee may still be spent. If the source deposit succeeded but nothing has arrived, do not send a second deposit merely to clear the first one: record the source hash, destination address, networks, and asset so the route’s operator can trace where processing stopped.
If a destination transaction is confirmed, inspect the receiving network and token identity before treating the transfer as lost. If the destination transaction failed after a successful source deposit, the funds may require the route’s recovery process; a source-chain explorer alone cannot show their final disposition. Retry only when the source transaction failed without taking the deposit, or when the first route’s outcome has been established.
The decision rule is simple: check the source transaction first, then the destination result, and send again only when you know the original deposit was not taken.