What to Check Before Exchanging BTC, ETH, USDT, LTC, BNB, TRX or XMR

A safe crypto exchange begins before a transaction is signed. The practical goal is to prove that the selected asset, blockchain network, destination details, amount and expected result all describe the same operation. If one element differs, the route should stop before funds leave the wallet.

This guide follows one route: exchanging an asset you already hold for another supported asset. It applies to BTC, ETH, USDT, LTC, BNB, TRX and XMR, but the required checks are not identical. Native coins use their own blockchains, while tokens such as USDT may exist on several networks. Deposit identifiers, fee mechanisms and confirmation requirements can also vary by direction and receiving platform.

Operation State Map

1. State 1: Define the task
   1. Transition condition: You can name the asset you are sending, the asset you want to receive and the wallets or accounts involved.
   2. Check: Confirm that the task is an exchange rather than a bridge transfer, ordinary wallet transfer, token swap or fiat purchase.
   3. Observable success signal: The send asset, receive asset and intended destination are written down without relying on ticker symbols alone.
   4. If it does not match, stop: A bridge or wallet transfer follows different rules and may not produce the asset or balance expected from an exchange.
2. State 2: Establish the source data
   1. Transition condition: Your wallet shows a spendable balance on a known blockchain network.
   2. Check: Identify the full asset name, network, token contract where relevant, available balance and asset needed to pay the network fee.
   3. Observable success signal: The wallet can display the asset and network separately, and the amount is available rather than pending, locked or staked.
   4. If it does not match, stop: A familiar ticker does not establish that the token is on the network accepted by the recipient.
3. State 3: Verify the exchange direction
   1. Transition condition: The desired pair and direction are currently available.
   2. Check: Review the sending network, receiving network, limits, quoted amount, quote conditions and current verification requirements before creating the order.
   3. Observable success signal: The order page explicitly identifies both assets and every network involved.
   4. If it does not match, stop: Do not substitute a similarly named network or reverse the pair merely because the intended route is unavailable. Availability can change, and not every possible pair, network or direction is necessarily supported.
4. State 4: Validate destination data
   1. Transition condition: The receiving address was copied from the wallet or account that should receive the result.
   2. Check: Compare the complete address, selected network and any Memo, Tag or other identifier displayed by the recipient.
   3. Observable success signal: The destination wallet supports the exact asset on the exact receiving network, and copied details still match after pasting.
   4. If it does not match, stop: Blockchain transactions are generally not reversible merely because the sender selected the wrong address or route. Ethereum’s official support material, for example, warns that transactions sent to an incorrect address cannot ordinarily be reversed. ^[1]
5. State 5: Review the economic result
   1. Transition condition: The displayed terms still satisfy the original task.
   2. Check: Separate the amount sent, wallet network fee, service deductions if shown, amount expected at the destination and any quote-expiry or recalculation condition.
   3. Observable success signal: You understand which amount leaves the wallet and which amount is expected to arrive.
   4. If it does not match, stop: Stop if the expected result has changed materially, the destination amount is unclear or a volatile market move has made the route unsuitable for the original purpose.
6. State 6: Create and recheck the order
   1. Transition condition: All previous checks agree and any applicable compliance requirements are understood.
   2. Check: Read the generated deposit instructions as new transaction data rather than relying on an address saved from an earlier order.
   3. Observable success signal: The active order shows the same asset, network and destination result previously reviewed.
   4. If it does not match, stop: Do not send to an expired, archived or unrelated deposit address without explicit confirmation that it remains valid for this operation.
7. State 7: Authorize the irreversible action
   1. Transition condition: The wallet confirmation screen reproduces the required destination, asset, network and amount.
   2. Check: Perform a final character-by-character or segmented address comparison and inspect the network fee before signing.
   3. Observable success signal: The signed transaction produces a transaction identifier, commonly called a transaction hash or TXID.
   4. If it does not match, stop: Reject the wallet prompt if the recipient, network, token or amount differs. Never approve unexpected contract permissions or disclose a seed phrase to “confirm” an exchange.
8. State 8: Wait for network and service processing
   1. Transition condition: The transaction appears on the correct blockchain explorer.
   2. Check: Verify its status, recipient, asset or token contract, transferred amount and confirmation progress.
   3. Observable success signal: The explorer shows successful inclusion on the intended network, followed by the order interface acknowledging the deposit.
   4. If it does not match, stop: Do not send a second payment simply because the first has not yet been credited. Diagnose the existing TXID first.
9. State 9: Confirm the result or enter recovery
   1. Transition condition: The receiving wallet or account shows the expected asset on the intended network.
   2. Check: Compare the final transaction with the order result rather than relying only on an email, browser notification or support message.
   3. Observable success signal: The output transaction is successful on-chain and the destination wallet controls or credits the resulting funds.
   4. If it does not match, stop: Preserve the order identifier, input and output TXIDs, addresses, asset names, networks and timestamps, then follow the relevant diagnostic branch below. Do not promise or assume recovery.

Asset and Network Checks That Cannot Be Replaced by the Ticker

The asset symbol answers only part of the question. Before sending, determine whether the asset is a native coin or a token issued on a particular blockchain. BTC and LTC are native assets of their respective networks. ETH is native to Ethereum, while BNB may be encountered in more than one BNB ecosystem context. BNB Smart Chain is EVM-compatible, and other BNB-related environments also exist, so an address beginning with the same characters is not proof that the selected route is correct. ^[2]

USDT requires an additional check because Tether tokens are issued on multiple blockchains. The sending wallet’s network must exactly match the network specified in the exchange order. A token displayed as “USDT” on one chain is not automatically transferable to a USDT deposit address generated for another chain. ^[3]

Do not “correct” an unsupported network yourself. If the required route is unavailable, the safe options are to wait, select another explicitly supported direction or use a separate bridge or conversion process that you understand. A bridge is a new operation with its own fees, contracts and risks; it is not a hidden step within the original exchange.

Address, Memo, Tag and Payment Identifier

Copy the deposit address from the active order and compare it after pasting. Malware can replace clipboard contents, while phishing pages can imitate a legitimate order screen. Check the domain and session before copying, and never use a deposit address received through an unsolicited direct message.

A Memo or Tag is not universally required by a particular ticker. Its necessity depends on the network and the recipient’s accounting method. If the active order presents both an address and an additional identifier, treat them as a single destination instruction. Omitting the identifier may leave an on-chain transfer successful but prevent automatic assignment to the correct order or account.

Monero requires particular care because its address system differs from transparent blockchains. Integrated Monero addresses can contain a compact payment identifier, while old-style long payment IDs have been removed from current transaction practice. Follow the exact address or identifier supplied for the order instead of constructing or reusing one manually. ^[4]

Final address checkpoint

• Confirm the address source: active order, not search results, email replies or chat messages.
• Compare more than the first and last characters; inspect the address in several segments.
• Verify that the wallet has not silently changed the network.
• Check whether a Memo, Tag or other identifier is displayed.
• Make sure the destination belongs to a wallet or account that supports the output asset and network.
• If using a test transfer is permitted, confirm that it will not invalidate the quote or order and account for the second network fee.

Amount, Quote and Fee Review

“Fee” may refer to several different deductions. Treating them as one number makes it difficult to predict the actual result. Review each layer that the wallet or order displays without assuming an undisclosed rate or fixed processing time.

Stop if the amount expected at the deposit address differs from what the wallet will actually deliver. This can happen when a custodial platform subtracts its withdrawal fee from the entered amount. Also stop if the quote has expired, the order requests a different amount after creation or volatility has changed the result beyond what the original task allows.

Compliance conditions may depend on the exchange direction and the outcome of transaction screening. Check current requirements before creating an order. Do not split transfers, change wallets or modify the route to avoid applicable checks; doing so can create additional operational and compliance problems.

The Last Check Before Sending

At this point, the route should satisfy all of the following conditions:

• The input and output assets match the original task.
• The pair and direction are currently available.
• The source wallet holds the asset on the required sending network.
• The destination supports the output asset on the selected receiving network.
• The deposit address and any additional identifier came from the active order.
• The amount, network fee and expected result are understood.
• The quote or order remains active under its displayed conditions.
• Current verification requirements are acceptable and can be completed if requested.
• No browser warning, unexpected wallet permission or unsolicited support contact is present.

If every checkpoint agrees, the next practical step is to check the current exchange direction and create an order. The service supports several assets relevant to this route, including BTC, ETH, USDT, LTC, BNB, TRX and XMR, but a particular pair, network or direction should be confirmed at the time of the operation.

Waiting for Confirmations Without Losing Track of the Route

A broadcast transaction is not the same as a completed exchange. First, the network must accept and include the transfer. Then the receiving service must detect it, wait for its required confirmation threshold, apply any necessary checks and process the output.

Bitcoin’s technical documentation distinguishes an unconfirmed transaction from one included in a block and explains that confidence increases as additional blocks confirm it. The receiving service decides how many confirmations it requires for a particular operation; a number used by one service or asset should not be assumed for another. ^[5]

TRON data similarly distinguishes confirmed and unconfirmed transactions, allowing the transaction state to be checked rather than inferred from a wallet notification. ^[6]

Delayed or Incorrect Transaction: Diagnostic Branches

No TXID was created

The transfer may not have been signed, broadcast or accepted by the sending wallet. Check the wallet’s activity history and spendable balance. Do not create a replacement order or send again until it is clear that no valid transaction exists. If a custodial sender shows an internal withdrawal reference but no blockchain TXID, the issue remains with that platform’s withdrawal process rather than the blockchain.

The TXID is not found

Confirm that the explorer belongs to the network actually used. Searching an Ethereum transaction hash on a different EVM explorer, or checking token activity only under a native-coin tab, can produce a false “not found” conclusion. If the hash is absent from the correct network after the wallet claims broadcast, preserve the wallet record and contact the sending provider.

The transaction is pending

A pending transaction has not yet achieved the network state required by the recipient. On Ethereum, an insufficient fee can leave a transaction pending; official guidance notes that supported wallets may offer speed-up or cancellation mechanisms. Those actions should be taken only through a trusted wallet and with an understanding of nonce handling. Do not send a duplicate exchange payment to the same order as a workaround. ^[1]

The transaction failed

A failed on-chain transaction did not complete the intended state change, although a network fee may still have been consumed. Check the explorer’s failure status and the wallet balance before trying again. If the order is time-sensitive, generate fresh instructions rather than assuming the failed attempt preserved the original quote.

The transaction succeeded on the wrong network or address

This is not a delay. It is a route mismatch. Record the actual network, recipient, token contract, amount and TXID. If the recipient address belongs to a known service, submit those details through its official support channel. Recovery may be technically impossible, unsupported or subject to additional conditions, and no return should be assumed. On irreversible networks, a successful transfer to the wrong address cannot be cancelled by changing the order afterward. ^[1]

The deposit is confirmed but the order is not credited

Compare the on-chain recipient and amount with the active order. Then check whether a required Memo, Tag or identifier was omitted, whether the service’s confirmation threshold has been reached and whether the order shows a verification or review status. Provide support with factual records, not seed phrases, private keys or remote access to the wallet.

The output TXID exists but the result is not visible

Open the output TXID on the correct explorer and verify the status, asset, token contract and destination. A token may require manual display in a self-custody wallet, while a custodial destination may wait for its own confirmation threshold before crediting the account. If the on-chain destination differs from the address entered in the order, preserve the order data and raise the discrepancy through the service’s official channel.

When the Route No Longer Matches the Original Task

Pause the operation if any of these conditions appears before signing:

• The interface changes the input or output network without a clear selection.
• The output is a wrapped or bridged asset when the task requires the native asset.
• A third party asks you to send to an address outside the active order.
• The wallet requests an unrelated token approval instead of a straightforward transfer.
• The expected receive amount is no longer acceptable or cannot be determined.
• The order has expired, but its old deposit address is still visible in browser history.
• The transaction would violate limits or verification conditions displayed for the current direction.
• The destination wallet cannot confirm support for the selected asset and network.
• Someone asks for a seed phrase, private key, wallet backup or screen-sharing session.

Rules governing crypto transactions and service availability differ between countries and can change. A technically valid blockchain transfer does not by itself establish that an operation meets local legal, tax or platform requirements. Where those questions matter, use current official guidance applicable to the relevant jurisdiction rather than assumptions based on another country.

What Counts as a Completed Exchange

The route is complete only when the output transaction is successful on the intended blockchain and the specified destination recognizes the expected asset on the correct network. An order marked “sent,” an input transaction with confirmations or an output TXID alone is an intermediate signal, not the full result.

Some uncertainty can remain even after the on-chain transfer succeeds: a custodial recipient may apply its own confirmation threshold, account review or availability hold. If the destination has not credited the result, retain both transaction identifiers and the order data until the discrepancy is resolved. The decisive evidence is a consistent chain of records from the original order to the spendable output balance, with no unexplained change of asset, network, address or amount.