What happens if you send crypto on the wrong network?
It depends on one thing above all others: whether anyone who will help you controls the private key for the address the funds landed on. If you control it, the tokens are usually still there and reachable. If a service controls it, recovery is their decision. If nobody controls it, the funds are almost certainly gone.
Neither "your funds are lost forever" nor "it can always be fixed" is true as a general statement. Both get repeated constantly, and both cause harm — the first makes people give up on recoverable funds, the second makes people careless.
First, work out which case you are in
| Where the funds landed | Who holds the key | Realistic outcome |
|---|---|---|
| Your own wallet, wrong EVM chain | You | Usually recoverable yourself |
| Your own address on a different chain type | Depends on your wallet | Varies; do not assume |
| HYPE sent via HyperCore to a HyperEVM address (or the reverse) | Whoever holds that 0x key | Same key, separate balance: recoverable by the key holder, not automatic |
| A service's deposit address, wrong network | The service | Their call; sometimes possible, often with a fee |
| A contract address or a random string | Nobody, or a contract | Usually unrecoverable |
BNB Chain's own recovery guidance puts it plainly: recovery depends entirely on whether you control the private key of the address the tokens were sent to. That framing is the right one to start from.
Case 1: your own wallet, wrong EVM chain
This is the common case and the good one.
Ethereum, BNB Smart Chain, Polygon, Avalanche C-Chain and other EVM chains derive addresses the same way — the last 20 bytes of a Keccak-256 hash of a secp256k1 public key. The same private key therefore controls the same 0x… address on every one of them.
So if you meant to send on Ethereum and sent on BNB Smart Chain, your tokens are sitting at your address on BSC. BNB Chain's documentation describes this case as tokens that are "just on a different network" rather than lost.
Typically: switch your wallet to the chain you actually used, add the token's contract address for that chain so the balance displays, and move it. You will need a small amount of that chain's native coin to pay for the transaction.
Case 2: a service's deposit address
Here you cannot self-recover, because you never held the key.
Whether the funds come back is a support question, not a technical one. Some services can sweep a wrong-network deposit after manual review, sometimes charging a fee to cover the work. Others state up front that they cannot. The honest answer is that it varies, and that the outcome is not yours to determine.
Contact them promptly with the transaction hash, the network you actually used and the one you intended.
On SwapToZec specifically: your quote names the deposit network. If you send on a different one, those funds do not arrive at the swap, and the swap waits for a deposit that will not come. Contact support@swaptozec.com with the transaction hash — what can be done depends on the network and the address involved, and we would rather look than guess.
A special case: Hyperliquid. HyperCore and HyperEVM share one 0x address but keep separate HYPE balances, so a deposit sent on the side a service is not watching is neither lost nor detected. The key holder can move it across; a service will need to do that by hand. HYPE on HyperCore vs HyperEVM covers how to pick the right side before sending.
Case 3: what token issuers actually say
There is a widespread belief that Tether or Circle will simply reverse a mistake. Their own terms do not support that expectation, and it is worth reading what they actually say rather than what gets repeated.
Circle is explicit. Its USDC terms state that USDC transactions are not reversible, and that once you send USDC to an address you accept the risk of losing access to it indefinitely or permanently. The terms name sending to an incorrect address or an unsupported network as examples, and state that Circle bears no responsibility for the resulting losses. No recovery service is offered.
Tether's terms describe freezing and seizure, not assistance. They reserve the right to freeze tokens, terminate wallets, and seize or recover against tokens — powers exercised at Tether's discretion, typically in connection with suspected prohibited use or a request from authorities. That is not a facility you can invoke because you chose the wrong network.
Individual interventions have been reported in the press, but a discretionary act in one case is not a policy you can rely on. Plan on the basis of the published terms: assume no issuer will undo your mistake.
Case 4: genuinely unrecoverable
Some situations have no remedy:
- Sending to an address nobody controls — a contract not designed to receive that token, or a mistyped string.
- Sending a token to a chain where it does not exist and no key you hold maps to that address.
- Any asset sent somewhere you cannot reach, whether or not it has a central issuer.
BNB Chain's documentation is direct about this: where the recipient address is not one you control, there is no way to retrieve the tokens unless whoever does control it chooses to return them.
Why this keeps happening
The underlying cause is that an address does not encode its network.
0x… means EVM. It does not mean Ethereum. The identical string is a valid address on Ethereum, BNB Smart Chain, Polygon, Avalanche and others, because they all use the same derivation. Nothing in the string distinguishes them, and no wallet can warn you purely by looking at it.
Tron addresses are written differently — Base58Check with a leading T, 34 characters — so they are not visually confusable with 0x… strings. Solana uses Ed25519 keys on a different curve again, and its addresses are distinct from both.
Do not read this as "one key works everywhere." The EVM case above is specific: the same 0x… address exists on each EVM chain because those chains share a derivation. Moving between different address formats is a separate question that depends on your wallet, and is not something to attempt on assumption.
The practical rule: the network comes from whoever gave you the address, never from the address itself.
Reducing the risk
- Read the network on the deposit instruction, not just the token name.
- Send a small test amount first when the value is significant and you are unsure.
- Be most careful when the address is
0x…, because that format spans several chains. - Keep the transaction hash. Every recovery conversation starts with it.
For picking the right network in the first place: which USDT network should you use and choosing the right USDC network.