Como escolher uma rede de saque cripto: taxas, suporte e recuperação

What this guide can and cannot tell you

This guide builds a reusable decision process from first-party help material published by Binance, OKX, Coinbase, Kraken, Bybit, and Bitget. Their documentation agrees on a critical operational principle: the sending and receiving sides must support the same network for the asset being moved. They also show why a transaction can pass through several different states—accepted by the sender, broadcast to a network, confirmed onchain, and credited by the recipient.

The guide does not publish a permanent table of supported networks, fees, withdrawal minimums, or confirmation thresholds. Those values can change by asset, jurisdiction, account, platform, time, and network conditions. It also cannot confirm whether a recovery tool will accept a particular mistake. Only the relevant platform or wallet can make that determination after reviewing the actual transaction.

The five-gate decision model

Use five gates in order. Do not advance because an earlier screen looks familiar.

This sequence is intentionally conservative. It separates a decision you can make before sending from evidence you can collect after sending. That separation matters because an irreversible network transfer leaves fewer options than a request still waiting inside the sending platform.

Gate 1: begin with the receiving side

The receiving side determines what can be credited. If you are sending USDT, USDC, ETH, or another asset that exists on multiple networks, the ticker alone does not define the route. A token with the same market symbol can have different contract addresses, bridge histories, and deposit support on different networks.

Open the receiving exchange or wallet. Select the asset and its deposit or receive function. Record the exact network label shown there. Then move to the sender and find the matching label. OKX's network-selection guidance explicitly says the withdrawal network and deposit network should be consistent. Binance likewise tells users to select the network compatible with the withdrawal address and warns against selecting the cheapest option without checking compatibility.

Do not infer support from an address that begins with 0x. Multiple EVM-compatible networks can use visually similar addresses. The address may be syntactically valid on several chains while the custodian credits deposits on only one of them. Kraken's address-format documentation makes the broader point that address formats and supported networks are product-specific. Valid-looking is not the same as supported.

Do not infer support from a transfer completed months ago. Platforms can add, remove, or suspend asset-network combinations. A wallet can change its routing, and a deposit address can be rotated. Re-open the destination screen for the current transaction rather than copying an old address from a spreadsheet or chat.

A useful verbal confirmation

Before pressing continue, say the route as one complete sentence: “I am sending this asset, from this platform or wallet, over this named network, to a destination that currently accepts the same asset on the same named network.” If any part of the sentence is based on assumption, stop.

Gate 2: address, tag, memo, and contract identity

A blockchain address is necessary, but it may not be sufficient. Some custodial platforms use a shared deposit address and a destination tag, memo, or comment to route the deposit to an individual account. Coinbase and OKX both explain this shared-address function in their help material. If the destination shows a tag or memo, copy both fields exactly. Do not invent a placeholder, reuse another account's value, or assume the field is optional because the blockchain itself accepted the transaction.

For a self-custody destination, a tag is often unnecessary because the user controls a unique address, but “often” is not a transaction rule. Follow the destination's current instructions. Where the receiving interface does not clearly say whether the field is required, ask its support channel before sending.

Check the address with more than a glance. Compare the beginning, middle, and end, preferably using the platform's full-address display. Clipboard malware and address-book mistakes can preserve a plausible prefix or suffix. If the asset is a token, distinguish the recipient's wallet address from the token contract address. The contract identifies the asset; it is not normally the destination for a user transfer.

Network labels also deserve attention. “Ethereum,” “ERC-20,” “Arbitrum,” “Base,” “Optimism,” “BNB Smart Chain,” and “BEP-20” are not interchangeable simply because some use EVM-style addresses. Similarly, native Bitcoin, wrapped Bitcoin, Lightning, and exchange-internal transfers are different routes. The screen must show the same route on both ends.

When an address validator is not enough

Sending platforms may automatically recognize an address format or suggest a network. Automation can catch some syntax errors, but it cannot necessarily know which network the recipient intends to credit. Binance instructs users to double-check an automatically matched network. Treat an automatic suggestion as a prompt to verify, not as proof.

Gate 3: compare the live economic result

Only after compatibility and identity are settled should you compare cost. Look at four numbers:

1. the amount deducted from the sending balance; 2. the withdrawal or network fee displayed by the sender; 3. the net amount expected to leave the platform; and 4. the recipient's minimum deposit or crediting threshold, if one applies.

Binance describes withdrawal fees as estimates affected by network conditions and says minimums and fees can change. Bybit also displays chain-specific fees and minimum withdrawal amounts in its flow. This is why a static blog table that calls one chain “the cheapest” is unsafe. The live screen at the moment of transfer is the relevant evidence.

Cost includes more than the sender's line-item fee. A bridge or swap may introduce price impact, protocol fees, gas on another chain, or a second transfer. A destination may not credit an amount below its minimum even when the chain transfer succeeds. A recovery process, if eligible, may charge a fee that makes a small mistaken deposit uneconomic to recover.

The fee should therefore be compared within the set of compatible routes, not across every route the sender offers. If the recipient accepts two networks, both address and tag fields are verified, and both are operational, then fee and expected time can break the tie. If only one route is supported, there is no valid cost comparison.

Gate 4: understand the three clocks

Users often ask, “How long will the transfer take?” There is no single clock. At least three operational clocks can matter.

Platform processing clock. The sending platform may run account, risk, address, security, or compliance checks before broadcasting. Kraken's withdrawal-status guide distinguishes initiated and pending states from sending, success, on hold, and failed. Bybit notes that processing can take longer during congestion. Account changes may also trigger holds that are unrelated to block production.

Blockchain confirmation clock. After broadcast, validators or miners include the transaction and the network accumulates confirmations or finality. Binance's transaction-status guide directs users to a block explorer and notes that required confirmations can vary. A transaction ID is the key evidence that a broadcast occurred.

Receiving credit clock. A custodial platform can wait for its own confirmation threshold, screening, token recognition, memo routing, or ledger reconciliation before showing a balance. Coinbase's troubleshooting material tells users to confirm the address and expected network even when a send appears completed. A confirmed chain transaction can therefore remain uncredited at the destination.

These clocks explain why “success” has different meanings. A sender may use success for one onchain confirmation, while a recipient may require more. A block explorer may show finality while a deposit system is under maintenance. Never diagnose the problem from one status word alone.

A practical pre-send workflow

Follow this workflow for a new route or material transfer.

1. Open the destination first

Navigate directly to the destination's deposit or receive function. Select the asset. Note the precise network name, address, and any tag or memo. Check whether deposits are available rather than merely whether the webpage loads.

2. Cross-check the sending screen

On the sender, select the same asset and locate the same network. Confirm that withdrawals are active. Compare the network name character by character where labels are similar.

3. Verify ownership and purpose

Confirm who controls the destination. For another exchange, confirm you are signed into the intended account. For self-custody, verify that the wallet supports the network and that you control its recovery method. Do not send merely because an address was supplied in a message.

4. Copy every destination-provided field

Copy the address and, when shown, the destination tag or memo. Review the full values. If an address book is used, confirm that its saved network and account label still describe the current destination.

5. Review the live amount and constraints

Check the fee, minimum withdrawal, net receipt, destination minimum, daily or account limit, and any warning about holds. A test amount must be large enough to be withdrawn and credited after fees.

6. Use a small test where practical

Coinbase's tag-and-memo guidance recommends considering a small test amount. The test can prove that one exact combination of asset, network, address, tag, and current destination credited successfully. It does not prove the next transaction will have the same fee, speed, limits, or status.

7. Preserve evidence

Save the sending withdrawal record, asset, network, address, tag or memo, amount, timestamp, and transaction ID. Do not publish this evidence. Keep it privately for reconciliation or support.

8. Verify the destination before sending the remainder

Do not rely only on a sender's completed badge. Confirm that the destination balance or deposit history shows the test. Re-open the destination instructions before a later transfer if time has passed.

What to do after a delay

First identify the stage rather than repeatedly submitting withdrawals.

If there is no transaction ID, the request may still be inside the sender's processing system. Review the withdrawal status and any account messages. If a transaction ID exists, open the correct network's block explorer. Verify the sender, recipient, asset or token contract, amount, success state, and confirmations. Be cautious with privacy: a public explorer exposes addresses and transaction relationships.

If the explorer does not show success, wait according to the network and platform guidance or contact the sender with the transaction ID. If the explorer shows success but the destination is not credited, compare the destination's supported network, address, tag or memo, and confirmation requirements. Contact the receiving platform because it controls its internal crediting ledger.

Kraken's status taxonomy is helpful here: an initiated or pending withdrawal is not the same as a broadcast; sending means the transaction has been broadcast and is waiting for confirmation; a hold or failure requires a platform-specific response. Other platforms use different labels, so interpret the underlying state, not the color of the badge.

Wrong network, wrong address, or missing memo

These are different incidents with different recovery owners.

Wrong address. If the destination is controlled by an unknown person, the sender generally cannot reverse an irreversible blockchain transfer. If the address belongs to a known exchange or wallet provider, contact that recipient with the transaction evidence. Do not trust unsolicited “recovery agents” asking for a seed phrase or remote access.

Wrong network. The same-looking address may be controlled on another EVM-compatible chain, but control does not equal platform support. A self-custody user who controls the corresponding keys may sometimes access assets with a compatible wallet, while a custodian may need a special recovery process. Coinbase states that it cannot recover ordinary sends made on the wrong network, while its separate asset-recovery tool covers only eligible assets and networks. OKX and Bitget likewise describe conditional, receiving-side review paths. None of this is a guarantee.

Missing or wrong tag or memo. The blockchain transfer may reach a shared custodial address without enough information to allocate the balance to an account. Contact the receiving platform with the transaction ID, address, amount, asset, network, correct tag or memo, and proof it requests. Recovery may be unavailable, delayed, or fee-bearing.

Never enter a seed phrase, private key, authentication code, or password into a recovery form sent through social media. Official support can investigate a transaction without taking control of your wallet credentials.

Common shortcuts that fail

“The address looks valid, so the network must be right”

False. Several networks share address formats. Syntax does not prove that a custodian supports or monitors the chain.

“I used this route before”

Historical success is useful context but not current availability evidence. Re-check the destination and sender for every material transfer.

“The cheapest option is best”

Only compatible options belong in the cost comparison. Binance explicitly warns users not to select solely by the cheapest fee.

“One confirmation means the money is available”

The sending platform, network, and recipient can use different completion thresholds. Confirm destination credit.

“Support can reverse it”

Once broadcast and finalized, a transaction may be irreversible. Support may help only when the receiving system controls the relevant address and has a supported recovery procedure.

“A test transfer makes the remainder risk-free”

A test reduces uncertainty about the exact path at that time. It cannot freeze fees, availability, limits, security holds, or network conditions.

Decision examples

Example A: two supported networks. The destination shows that it accepts a stablecoin on Network A and Network B. The sender offers both. The user verifies the address and no tag is required. Now it is reasonable to compare live fees, net receipt, expected processing, and the user's ability to pay gas later. Either route still needs a current status check.

Example B: cheapest route absent at destination. The sender offers a very low-fee Network C, but the destination's deposit screen does not list it. Network C is not a candidate. The user should not rely on the shared address format or a third-party article.

Example C: shared deposit address. The destination shows an address and a numeric tag. The sending form accepts both. A small test without the tag would not test the intended route; it would create the very incident the test was meant to prevent.

Example D: onchain success, no credit. The transaction ID shows success on the correct network, but the exchange balance is unchanged. The user should verify the tag, destination deposit status, and confirmation threshold, then contact the recipient with the transaction evidence. Submitting another identical transfer does not diagnose the first one.

Known unknowns at publication time

NexuAlpha did not log into any reader's account and did not execute a transfer. We did not verify current network availability for a specific asset, jurisdictional eligibility, security holds, account limits, withdrawal fees, minimums, destination crediting thresholds, or recovery eligibility. Official pages can also vary by country and can be updated after this evidence snapshot.

The absence of a warning in this article is not proof that a route is safe. The transaction screens and official status or help material for the two endpoints remain the controlling operational references.

FAQ

How do I know whether to choose ERC-20, TRC-20, BEP-20, Base, Arbitrum, or another network?

Open the receiving destination for the exact asset and use only a network it currently lists. Then choose the identical network on the sender. Do not select based on address appearance, fee, or a generic chain comparison.

Is the cheapest withdrawal network usually the best?

No. Compatibility is the first requirement. Among two genuinely supported routes, compare the live fee, minimum, net receipt, status, expected confirmations, and what you need to do with the asset after arrival.

Why does a crypto transfer need a tag or memo?

Some custodial platforms use one blockchain address for many customer deposits. The tag or memo tells the platform which internal account should receive the credit. Copy the value provided by the recipient exactly.

Can an exchange recover a wrong-network transfer?

Sometimes a recipient offers a limited recovery tool or manual review, but eligibility depends on the asset, network, address control, transaction status, system support, and policy. Recovery is never a safe assumption and may carry a fee.

What does a transaction ID prove?

It lets you locate the transaction on the relevant blockchain and inspect its address, asset or contract, amount, state, and confirmations. It does not by itself prove that a custodian credited the correct user account.

Should I always make a test transfer?

A small test is useful for a new or material route when minimums and fees make it practical. Verify the destination credit before the remainder. Remember that conditions can change between the test and the next transfer.

What information should I keep for support?

Keep the transaction ID, asset, network, amount, time, sender record, destination address, and tag or memo. Share only what the official support process requires. Never provide a seed phrase, private key, password, or one-time authentication code.

Official sources

• Binance: Crypto Withdrawal Fees
• Binance: Deposit and Withdrawal Guide
• Binance: Checking Transaction Status
• OKX: Selecting the Correct Network
• OKX: Withdrawal Mistakes
• OKX: Tags and Memos
• Coinbase: Send and Receive Troubleshooting
• Coinbase: Destination Tags and Memos
• Kraken: Cryptocurrency Withdrawal Statuses
• Kraken: Supported Address Formats
• Bybit: On-Chain Withdrawal Request
• Bitget: Uncredited Deposit Review

NexuAlpha has no commercial link in this guide. The purpose is to make the decision process auditable before funds move.