An exchange withdrawal needs an asset, a network and a destination

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

An exchange withdrawal is not specified by a ticker alone. The same named asset may be offered on several networks, while the receiving wallet may support only one of them. Some address formats overlap across networks, so an interface can accept a syntactically valid address that points into an unsupported recovery problem. Treat the withdrawal as a three-part match: exact asset, exact network and destination controlled by the recipient.

Write the receiving side first

In the receiving wallet, record the asset's full name, network name, account type and address. If a token uses a host network, record both token contract and host network where the wallet exposes them. Do not begin with whichever network the exchange marks “cheap” or “recommended.” The receiving system defines compatibility.

Verify the address on the signing device where possible, using the device-display workflow. Then open the exchange's current deposit/withdrawal support page in a separate tab. Kraken's withdrawal guide, for example, instructs users to choose the same network the receiving wallet uses and warns that an incompatible network can cause permanent loss. That warning is evidence about Kraken's workflow, not proof that another exchange supports the same recovery options.

Run the compatibility matrix

• Asset: Is this the native asset, a token, or a wrapped claim? Wrapped bitcoin is not a base-layer Bitcoin withdrawal.
• Network: Do both sender and receiver name the same chain or layer? “Ethereum,” “Arbitrum One” and “Base” are different answers even if the address begins with the same characters.
• Address or invoice: Is the field expecting an on-chain address, a Lightning invoice, a tag or memo, or another identifier?
• Destination support: Does the receiving wallet explicitly support that asset on that network, not merely the network itself?
• Operational state: Are deposits and withdrawals currently enabled, and are there minimums, holds or required confirmations?

Kraken's network-and-method documentation distinguishes a blockchain network from a transfer method and notes that fees differ by network. That is useful vocabulary: a lower displayed withdrawal charge does not establish custody equivalence or recipient support.

Use a staged withdrawal

Save the withdrawal screen or transaction record without exposing account secrets. Check the final address after pasting, select the verified network, and make a first withdrawal small enough that loss is tolerable but above all stated minimums. Wait for the receiving wallet—not just the exchange status—to show the transfer under the expected network and asset. Then re-open the saved address entry and repeat the network check before the remainder. Address whitelisting reduces typing but can preserve an old network assumption, so label saved entries with both asset and network.

If the first transfer does not arrive

Do not send a second transfer as a diagnostic. Capture the transaction identifier, withdrawal network, destination, tag or memo, and exchange status. Check a block explorer for that exact network only after confirming the explorer itself. If the transaction exists on a different network from the receiver's supported account, contact the receiving provider through its official channel; recovery may be unavailable or fee-bearing. Never give support a seed phrase.

This checklist cannot make an unsupported transfer reversible. It narrows the decision before authorization and creates a record after it. Network support, holds, fees and recovery policies change, so re-check first-party documentation for every material withdrawal rather than relying on a screenshot from an earlier transfer.