A wrong-network crypto transfer records the asset on a blockchain different from the intended receiving network. A wrong-address transfer delivers it to a different destination on the selected chain. Check the network, exact asset identifier and complete receiving address together before sending. An address can look valid on several networks, and a successful transaction does not prove an exchange will credit it or can recover it.
A matching address does not identify the network
A receiving address answers only part of the routing question. MetaMask documents that an ordinary account can use the same address on Ethereum and other EVM-compatible networks. The account's familiar appearance therefore cannot establish which blockchain a transfer will use. MetaMask's explanation of shared EVM addresses.
Suppose a receiving service displays an address after you select a particular token and network. Copying that address correctly preserves the destination bytes. Selecting another network in the sending interface changes the ledger on which the transfer occurs. It does not carry the receiving service's acceptance policy across with it.
A wrong-address problem is separate: the actual transfer recipient differs from the verified destination, even if the correct network was selected. Both errors can occur in the same transfer. An address format check may catch some malformed inputs, but it cannot tell you whether a well-formed address belongs to your intended recipient.
This distinction also guides investigation. OKX's current wrong-address guidance asks customers to compare the receiving address in the sending record with the address obtained from its deposit page. An address match moves the investigation toward other causes; it does not establish that every other deposit requirement was met. OKX's wrong-address deposit guidance.
Write down the complete transfer identity
Use the receiver's authenticated deposit screen or a verified request from the intended recipient as the starting point. Read it before choosing a cheaper withdrawal option. Preserve the exact network name and production or test environment; for an EVM network, record the chain ID where the interface exposes it. Treat an unfamiliar abbreviation as unresolved until its network is identified.
The worksheet below is for one specific transfer. Fill in the sending and receiving evidence separately, then reconcile them.
| Check | Evidence to save | Reason to pause |
|---|---|---|
| Network and environment | Sender's selected chain and receiver's accepted chain, both on mainnet or the intended testnet | Different chains, or an unexplained label |
| Asset identity | Native network asset, or exact token contract, mint or other chain-specific identifier | A ticker matches but the identifier does not |
| Receiving address | Complete address from the verified receiving instruction and final send preview | Any unexplained difference |
| Account routing | Required memo or destination tag, including its exact value | Missing or different routing data |
| Net amount | Expected amount received after deductions, against the receiver's current minimum | A test or full deposit falls below the limit |
| Receiving status | Current support, deposit availability and credit requirements | Deposits paused, unsupported or unclear |
| Control and evidence time | Who controls the destination, and when instructions were checked | Assuming the sender can recover a custodian's deposit |
The token identifier is not the receiving address. One identifies the asset's contract or record; the other identifies where the intended balance should be credited. Do not paste an issuer's token contract into a destination field merely because it came from official documentation.
Circle, for example, publishes USDC identifiers by blockchain and separates mainnet from testnet. Its Ethereum and Base entries have different contract addresses. That establishes token identity on those networks, not acceptance by a particular exchange. Circle's USDC contract directory.
A native gas asset also differs from a token represented by a contract. Where the asset is the network's native asset, record that explicitly instead of inventing a token contract. If the holding is a bridged representation, check its actual identity and the receiver's support for that variant. The wrapped-token and bridge-risk guide explains why a matching ticker does not make representations interchangeable.
A shared deposit address may additionally require a memo or tag to identify the customer's account. That is a separate field in the deposit memo and destination-tag guide. A correct tag cannot repair a wrong network, and the correct network cannot supply an omitted tag.
A hypothetical deposit with correct bytes and zero credit
Consider two invented EVM networks, Network A and Network B, and an invented token called U. Each network has its own U token contract. Exchange R is also fictional. For this example, R accepts U deposits only on Network A and displays receiving address D. These labels are explanatory placeholders, not addresses or current exchange policies.
A sender controls an ordinary wallet account on Network B holding 2,000 U. D is a valid-looking address on B as well. The sender copies D correctly but selects Network B and transfers 250 U. Assume the transfer succeeds, D initially has zero U on both networks, and no other U transfers occur. Gas is paid separately in B's native asset and is excluded from this token ledger.
| Observation | Sender's U on B | U at D on B | U at D on A | R account credit |
|---|---|---|---|---|
| Before transfer | 2,000 | 0 | 0 | 0 |
| Transfer included on B | 1,750 | 250 | 0 | 0 |
| More B confirmations, unchanged support | 1,750 | 250 | 0 | 0 |
| Sender switches wallet view to A | 1,750 on B | 250 on B | 0 | 0 |
The B token ledger reconciles: 2,000 minus 250 equals 1,750, and 1,750 plus 250 equals the original 2,000. The amount transferred is 12.5% of the sender's starting U balance. Nothing in those calculations creates 250 U on A or an entry in R's customer ledger.
Seeing the 250 U in an explorer does not establish that the sender can spend it. Whether anyone can move it from D on B requires evidence about destination control. Whether R will assist requires a separate policy decision. Zero account credit does not prove the tokens were burned, and an observable balance does not prove recoverability.
Switching a wallet's displayed network queries another ledger. It does not move balances between ledgers. Additional confirmations on B also cannot, by themselves, turn the transfer into an A deposit. Use the confirmations versus finality guide for settlement status after identifying the actual chain; confirmation count cannot establish receiving support.
A small test would limit the amount sent before discovering this mismatch only if the sender stops when credit fails to arrive. The test must satisfy the receiver's minimum and routing requirements. Wait for the intended account to show the expected credit, then recheck the full transfer's network, asset, address and tag. A successful test does not validate changed instructions or guarantee later credit.
Inspect the actual transfer before deciding it is missing
Start with the sending wallet or exchange's completed withdrawal record. Save the actual network, transaction hash, amount, asset identifier, receiving address and timestamp. Open an explorer for that network through a trusted source. Looking only on the chain you intended to use can conceal the transfer that actually happened.
For an ERC-20 token, distinguish the transaction's contract interaction from the token's recipient. The standard defines a token transfer recipient and a Transfer event containing sender, recipient and value. Compare the correct token contract's transfer details with the intended address, rather than reading only the transaction's top-level destination. ERC-20 transfer and event specification.
Then classify the evidence:
- No included transaction on the reported network: investigate the sender's withdrawal or broadcast status before treating it as a completed deposit.
- A completed transfer to another address: verify the address's provenance and identify whether its controller is known.
- The correct recipient on another network or in another token: investigate the actual chain and asset, then the receiver's support and recovery policy.
- The expected chain, token and recipient: check the memo, minimum, deposit availability and required credit conditions with the receiver.
Do not send a duplicate deposit to diagnose the first one. A second transaction adds another balance movement without explaining the first. Keep the original evidence intact, including the receiving instructions that were used.
Recovery depends on who controls the destination
An ordinary account whose keys you control
A display problem can be different from a loss of control. Trezor documents cases where assets sent to a holder's ordinary EVM address on another network remain controlled by their keys but do not appear in Suite. Its documented approach includes using an appropriate interface for the actual network. This is a specific self-custody case, not a rule for exchange addresses. Trezor's missing-token and wrong-network guidance.
First verify that the exact destination is your account and that the wallet supports the network and asset. Follow the wallet provider's official connection instructions; a request to disclose a recovery phrase is not a requirement to inspect a public balance. Any later transfer is a new operation with its own destination and fee checks.
An exchange or other custodian
An exchange deposit address does not give the customer its signing keys. Adding that address to a personal wallet interface cannot grant spending authority. Coinbase explicitly explains that unsupported deposits can occur without being accepted into the customer's account. Coinbase's unsupported-deposit explanation.
Its recovery service covers only certain assets and networks, and uses the actual network, transaction ID and deposit address to investigate. This documents a limited Coinbase service, not a universal recovery mechanism or commitment by another venue. Coinbase's recovery requirements.
Use the receiver's authenticated support channel and provide those identifiers, the amount and the original deposit instructions. Ask whether that exact asset and network qualify. Do not infer eligibility from a successful recovery story involving a different token or chain.
A contract account or an unknown recipient
Ethereum distinguishes accounts controlled through keys from accounts controlled by contract code. A contract address's appearance therefore cannot establish who can withdraw a token or whether the necessary logic exists on another network. Ethereum's account model.
Sending to the token contract itself is another possible address error. Trezor notes that recovery can depend on an appropriate recovery function and may be impossible without one. Trezor's token-contract recovery limits. For an unrelated destination, the sender cannot authorize a return simply by proving they made the original payment.
Keep transfer identity as explicit as an exchange instrument's identity in the symbol-mapping guide. Before the next send, retain one reconciled record: the accepted network, exact asset, complete recipient, required tag, expected net amount and dated receiving instructions. If any field remains unresolved, keep the transfer unsigned until that field is verified.