Sent your deposit on the wrong network?
It's the most common crypto-casino deposit mistake: the coin was right, but you sent it on a network the operator doesn't credit for that coin. Whether you can get it back comes down to one thing — whether the network you used and the one the operator expected belong to the same address family.
Is it recoverable? The network-family rule
Every network belongs to a family. Funds are only recoverable when the operator can control the destination address on the chain you actually used.
| You sent on | Operator expected | Recoverable? | Why |
|---|---|---|---|
| Any EVM chain | Same 0x address, different EVM chain | ⚠️ Sometimes | One key controls the same 0x address across all EVM chains, so the operator can sometimes sweep the funds — if they support that chain. |
| EVM (0x…) | Tron (T…) | ⛔ No | Different address scheme and keys; the operator cannot access the funds. |
| EVM or Tron | Solana / Bitcoin / native L1 | ⛔ No | Incompatible families — funds are unreachable by the operator. |
| Correct network | Correct network | ✅ Credits | Just wait for confirmations. |
EVM family = Ethereum (ERC-20), BNB Smart Chain (BEP-20), Polygon, Avalanche C-Chain, Arbitrum, Optimism, Base. Source: shared secp256k1 key/address scheme across EVM chains. Verified 2026-06-22.
Why the EVM case is different: every EVM chain derives a wallet address the same way from the same private key, so your 0x… address is identical on Ethereum, BNB Smart Chain, Polygon and the rest. If the operator controls that 0x address, it controls it on every EVM chain — including the one you sent on by mistake — so a sweep is technically possible. Tron addresses start with T and Solana and Bitcoin use entirely different schemes, so the operator's deposit address simply does not exist on those chains and there is nothing to sweep. You can confirm where the funds sit by checking the receiving address on the relevant explorer: an EVM address on Etherscan or BscScan, a Tron address on Tronscan.
Two worked examples
The same coin behaves completely differently depending on which boundary you crossed. Here are the two cases people hit most often.
USDT sent on ERC-20, operator wanted TRC-20 — generally lost
You meant to fund a Tron (T…) deposit address but your wallet was set to Ethereum, so the USDT moved as an ERC-20 token to a 0x… address instead. The tokens now sit on Ethereum at an address the operator never created and cannot sign for, because Ethereum and Tron use separate key schemes. There is no Tron key that maps to that Ethereum address, so nobody on the operator's side can reach the funds. This is the textbook unrecoverable case: a support ticket is a long shot, and the honest expectation is that the deposit is gone. The only realistic safeguard is to slow down before the next send and confirm the chain.
USDT sent on BEP-20, operator wanted ERC-20 — sometimes sweepable
Here you stayed inside one family. The operator gave you a 0x… Ethereum address, you sent USDT as a BEP-20 token on BNB Smart Chain, and because that address is byte-for-byte identical across EVM chains, the same private key the operator holds also controls the address on BNB Smart Chain. The USDT is parked at a real, reachable address — just on the chain you used by accident. If the operator's systems support BNB Smart Chain and they are willing to sweep, recovery is possible. It is never guaranteed: some operators do not run the infrastructure to move funds off a chain they did not intend to credit, and the gas to sweep can exceed a tiny deposit. But this is the case where asking is worth the effort.
How to ask for an EVM-to-EVM sweep
When your case is the second one above, the request you send shapes how fast it is handled. Give the operator everything they need to act in a single message, through their official support channel only:
- The transaction hash (TXID) of the deposit.
- The chain you actually used (for example, BNB Smart Chain / BEP-20).
- The destination
0x…address the funds landed at — the one they issued you. - A direct question: do you support that chain, and can you sweep the funds to credit my account?
Realistic odds: when the operator runs nodes for the chain you used and the amount covers the sweep cost, plenty of cases resolve within a few working days. When they do not support that chain, or the deposit is too small to move economically, the answer is no — and no amount of follow-up changes the underlying technical limit. A sweep is a manual favour, not a guaranteed service, so keep one polite ticket open and avoid pressuring the agent. If support confirms they cannot reach the chain, treat the funds as lost rather than chasing a third party.
"Confirmed on-chain" but still not credited?
Before you decide this is a network mistake at all, rule out the lookalikes. A transaction that shows as confirmed on the explorer but never lands in your casino balance is often a different problem with a normal fix:
- Below the minimum. The amount arrived but sits under the operator's deposit floor, so their system holds it without crediting. See minimum deposit thresholds.
- Missing memo or destination tag. On chains that need one, an absent memo leaves the funds unattributed even though they confirmed. See missing memo or destination tag.
- An internal or contract transfer the detection misses. Some exchange withdrawals or contract calls do not look like a standard transfer to the operator's deposit scanner.
- A processing or KYC hold. The deposit is seen but parked behind a verification or manual-review step. See why a deposit shows pending.
If the network matches what the operator asked for, the money is not lost — it is queued. Confirm the chain first, then work down that list before assuming the worst.
Prove which chain you used
You do not have to take your wallet's word for it. The transaction hash is the proof, and an explorer settles the question in seconds. Paste the TXID into each explorer in turn: it will resolve on exactly one chain and return nothing on the others. A hash that loads a full transaction on Etherscan but shows "not found" on Tronscan means you used Ethereum, not Tron — that single fact decides whether you are in the recoverable family or not. On the transaction page, the receiving address and the token contract confirm the asset; a USDT transfer on Ethereum points at the official Ethereum USDT contract, while the same coin on BNB Smart Chain shows a BscScan page and a different contract. Save the explorer link before you open a ticket, because it is the one piece of evidence support cannot argue with.
What to do right now
- Stop. Don't send anything else to the same address until you understand what happened.
- Find your transaction hash (TXID) in your wallet or exchange history, and confirm which chain it landed on by pasting it into the explorer for that chain — Etherscan (Ethereum/ERC-20), BscScan (BNB Smart Chain/BEP-20) or Tronscan (Tron/TRC-20). A hash that resolves on Etherscan but returns nothing on Tronscan is your proof of which network you actually used.
- Contact the operator's official support with the TXID, the network you used, and the network you intended. The recoverability checker generates a ready-to-paste message.
- If it's an EVM↔EVM case, specifically ask whether they can sweep the funds on the chain you actually used.
- Never pay a "recovery service." See the warning below.
Recovery scams
The only parties who can ever recover funds are the operator that received them or the exchange that sent them — directly, for free. Anyone who DMs you, guarantees recovery, charges an up-front fee, or asks for your seed phrase is a scammer, and handing over a seed phrase lets them empty every wallet it controls. The FBI's IC3 and the US FTC both warn that "recovery" services advertising guaranteed crypto recovery are themselves a common second scam aimed at people who already lost funds. No legitimate party charges you to return your own money. Read how we verify recovery claims.
Per-operator recovery: what we track
For each operator we record whether they recover wrong-network deposits, any fee, and turnaround — verified by first-hand testing. Those figures are being measured and will appear on each operator deposit guide as they're confirmed; we publish nothing we haven't verified.
Avoid this next time
The cleanest fix is to deposit somewhere that supports multiple networks, so a mismatch is far less likely.
FAQ
Is a wrong-network crypto deposit always lost?
No. If you sent on a different EVM network (for example BEP-20 instead of ERC-20) to the same 0x address, the funds sit at that address on the chain you used and the operator can sometimes sweep them. If you crossed incompatible families — an EVM chain to Tron, or to Solana — recovery is generally not possible.
I sent USDT on ERC-20 but the casino wanted TRC-20. Can I get it back?
Usually not. ERC-20 (Ethereum, 0x addresses) and TRC-20 (Tron, T addresses) use different address schemes and keys, so the operator cannot access funds sent across that boundary. Open a support ticket as a long shot, but set expectations low — and never pay a recovery service.
How do I know which network I actually used?
Open your sending wallet or exchange withdrawal history and read the network/chain field, or paste the transaction hash into a block explorer for that chain. The network is fixed at the moment you sent — you cannot change it afterward.
The transaction is confirmed on-chain but the casino hasn't credited it. Is that a wrong-network problem?
Not necessarily. A confirmed transaction the operator can see but hasn't credited is often a different issue — a deposit below the minimum, a missing memo or destination tag, or a normal processing or KYC delay. Check the network first; if it matches, look at those causes before assuming the funds are lost.
Related: missing memo or destination tag · deposit still pending · the same mistake on a withdrawal · run your case through the checker.