A wrong-network transfer is not one problem with one recovery method. Start with the original transaction status, then work out who controls the receiving address. A payment still being processed by the sender, a successful transfer to your own wallet and a deposit sent to an exchange on an unsupported network need different responses.
Keep the original record before doing anything else. You will need the asset, actual sending network, destination and transaction reference.
First check whether the transfer left the sender
| What the record shows | What to do next | What it does not establish |
|---|---|---|
| Processing, with no TxID | Check whether the original service offers cancellation or needs a support enquiry. | That a wrong-network transaction has already executed. |
| Failed or canceled | Check the platform’s handling of the amount and available balance. | That you can safely repeat the send without checking the account. |
| A blockchain TxID | Use the explorer for the actual sending network and inspect execution status. | That the transaction succeeded or the receiver credited it. |
| An internal transfer label | Trace the platform’s internal reference and recipient. | That a missing blockchain hash means funds were lost. |
If the transaction was initiated through an exchange, use its record and available controls. Wallet instructions for canceling an unconfirmed transaction are not instructions for canceling an exchange withdrawal: you do not control the exchange’s signing account. If the service provides no cancellation option, ask support about the original request rather than trying a workaround.
If I send a second transfer on the right network, does that offset the first?
No. It creates a separate payment. The original transaction retains its own network, destination and status. A second successful deposit does not prove that the first payment was recovered.
Read the transaction on the network actually used
Copy the network and TxID from the sending record. The network you intended to use may differ from the one you selected. Searching only the intended network can therefore produce an empty result even when a transaction exists elsewhere.
On the correct explorer, inspect the status before interpreting the amount. A pending transaction, a failed execution and a successful token transfer are different outcomes. Then compare the destination and token details with the original receiving instructions.
- Is this the TxID from the original send, rather than a platform order number?
- Does the explorer correspond to the actual network in that record?
- Did execution succeed?
- Which token and amount moved, and to which address?
- Does the receiving service support that exact token on that network?
A transaction hash or public address is enough for viewing public transaction data. Reading an explorer does not require you to enter a seed phrase, connect a wallet or approve a token transaction. Avoid a “recovery” page that asks for those actions merely to look up a payment.
If the explorer finds the hash, does that mean I can get it back?
No. Finding a record does not mean execution succeeded, and success does not mean the funds can be recovered. Recovery depends on the asset, network, destination’s control and any receiving service’s policy.
If the asset, network and address all match the receiving instructions, investigate ordinary deposit conditions as well. The receiving service may require confirmations or a minimum amount. A missing or incorrect tag is another possibility. Describe the evidence before labeling the problem as a wrong-network transfer.
Who controls the destination?
Case 1: an exchange or custodial service supplied the address
Contact that receiving service. Your account with the exchange normally does not give you control of the private key for its deposit address. Adding the address to a personal wallet as a watch-only account cannot change that or force the platform to credit the deposit.
The sending platform can help identify what it sent, whether it broadcast the transaction and which reference to use. After a successful transfer to an external destination, the receiving service is the party to ask about supported recovery or manual-credit procedures. It may decline, limit assistance to certain assets or networks, or charge for an eligible recovery.
Ask about this exact transaction, not whether the platform “supports crypto recovery” in general. Its ability to handle one EVM network or token does not mean it can handle every network. A forum story about another user’s successful case is not confirmation of eligibility.
The person who gave you the deposit address may need to open the request from their own receiving account. Coordinate the evidence with them, while keeping the sending platform’s record available. Do not ask them to export a key from an exchange account or assume they can switch networks to claim the funds.
Case 2: you or the recipient controls a self-custody wallet
Confirm that the destination is genuinely an account controlled by that wallet. For an ordinary account on compatible EVM networks, the same account can often access the same address on the network used. The token may simply be absent from the wallet’s currently selected network or displayed token list.
MetaMask’s official wrong-destination guide explains this distinction and directs users to check transaction status and network. Use the documentation for the wallet that controls the address; do not import a recovery phrase into an unfamiliar “recovery tool.”
After selecting the correct supported network, verify the token identity from a trusted source before adding it to a display list. Seeing a token balance is different from being able to transfer it. An onward transfer may need the network’s native fee asset and must use a destination that supports the asset on that network.
Do not apply the ordinary-account explanation automatically to a smart-contract wallet, an exchange address or a non-EVM destination. Control and address derivation can differ. If the account type is unclear, stop at gathering the public transaction evidence and consult the wallet’s official support.
If the recipient can access the assets, agree what happens next: leave them on that network, return them through a supported route, or use a separately understood cross-chain service. A bridge is a further transaction with its own support requirements and costs; it is not a way to edit the original withdrawal.
Case 3: the address itself was wrong or belongs to a contract
Compare the complete destination with the instructions you intended to use. If the characters differ, this is an address error as well as, or instead of, a network error. Knowing where the transfer went does not give you control of that address.
A token contract address is not the same as a recipient’s wallet address. Contracts may not provide a way to return tokens sent to them. The relevant project may be able to explain its contract’s behavior, but the existence of a public contract page is not a recovery guarantee.
If you know the actual recipient, you can ask about a voluntary return through a new transaction. If you do not, an explorer’s address label or transaction history should not be treated as proof that a stranger contacting you controls it.
Worked example: a successful transfer with an empty exchange balance
Assume a recipient requested USDT on Ethereum, but the sender selected BNB Smart Chain. This is a hypothetical example, not a record of a recovered payment. The sending history shows a TxID, and the corresponding BNB Smart Chain explorer shows a successful USDT transfer to the supplied address.
Those observations answer two questions: which network was used, and whether that transfer executed. They do not answer whether the receiving exchange controls that address on BNB Smart Chain or will assist with the token. The recipient should submit the original instructions alongside the actual transaction, describing the mismatch as “requested Ethereum; sent on BNB Smart Chain.”
If the exchange confirms that the transaction qualifies for its recovery process, follow that process. If it rejects the network or asset, a wallet tutorial cannot override the decision or provide the recipient with the exchange’s key. If support asks for a different identifier, check whether it wants the original withdrawal reference or the blockchain TxID before supplying it.
Now change one assumption: the address belongs to the recipient’s own ordinary EVM wallet. The recipient can consult the wallet’s official instructions for the network actually used, inspect the balance and decide on an onward route if the asset is accessible. The same public transaction therefore leads to a different next step because control of the destination changed.
Make the support request reproducible
A useful request lets support locate the same transaction and see the exact mismatch. Copy identifiers rather than retyping them. Include the network names in full, particularly where an abbreviation could refer to either a token or a network.
| Evidence | Detail to include |
|---|---|
| Sending record | Asset, amount, time, status and actual network |
| Blockchain reference | TxID and the corresponding explorer link |
| Destination | Complete receiving address and any tag supplied |
| Intended route | The receiving asset and network requested |
| Account outcome | Whether the recipient sees a deposit record, credit or neither |
Explain missing tags separately from wrong networks. The official Tag/Memo guide uses its own eligibility rules and distinguishes incoming deposits from transfers sent to another platform. If the network is correct and the tag is the issue, use the tag recovery steps to prepare the right details.
When support asks for another document, add it to the existing case when possible. Retain the case reference and keep the same transaction identifiers in subsequent messages. Different staff should be able to recognize that they are looking at the same payment.
When two records appear to disagree
A sender’s status and the receiver’s account status describe different stages. “Withdrawal completed” may describe the sending service’s work, while “no deposit” describes the receiver’s internal record. Put both statements in the request instead of discarding one as necessarily wrong.
Check that both sides are referring to the same amount and transaction. A later test payment, an earlier deposit or a recovery return can share the same asset and address. Match by the reference and network first, then use time and amount as supporting details. When quoting a timestamp, retain the time zone displayed by its source so the records are not compared as if all clocks used the same zone.
If a support reply appears to address the wrong transaction, reply within the case with a short correction: identify the original TxID, specify which later payment the reply seems to describe, and ask which one is being investigated. Avoid starting a second recovery request with different amounts unless the platform asks you to.
Support says processing. How long do I wait?
Use the receiving service’s case status and stated handling arrangements. There is no universal recovery deadline. Ask whether the transaction is eligible, whether it has been accepted for processing and what the next update will cover.
Before paying any recovery charge, verify the request through the official service. Ask what the charge covers, how it is collected, what happens if recovery fails and where recovered assets would be returned. Paying a fee is not itself evidence that the assets can be recovered.
A return to the original sending platform may require another crediting step there. Save the return TxID and ask the sending platform to trace it if needed. Keep “application accepted,” “return broadcast” and “account credited” separate in your records.
Confirm the original payment’s outcome before marking it recovered
Recovery is evidenced by a return transaction, an account credit or an official completed outcome explaining what happened. A new payment arriving correctly is a separate event. Record the original amount as unresolved until you have evidence of its own outcome.
For the next transfer, obtain fresh receiving instructions and use the pre-send checklist. A test amount must meet the deposit minimum, and the recipient must confirm actual credit before you send the remainder. Keep the token, network, address and tag unchanged.
If the final answer is that recovery is unavailable
Keep the reason and case reference with the original record. A refusal based on unsupported network, an inaccessible destination and an incomplete application are different outcomes. If the issue is missing evidence, provide the evidence requested; if the service has confirmed it cannot recover the transaction, repeated identical submissions will not create a new technical option.
Record any amount still unresolved separately from any replacement payment. This helps you and the recipient avoid counting a replacement as a refund or paying the same obligation again. If the service later offers a supported procedure, assess the new official terms and evidence at that time rather than paying a stranger for a promised shortcut.
Be cautious of unsolicited offers to “unlock” the original funds. Official support does not need your seed phrase to inspect a public transaction. A private message promising guaranteed recovery in exchange for another transfer is not a reason to abandon the verified support route.