A safe crypto exchange begins before funds leave your wallet. The goal is not to prove that a service can never fail; that is impossible from a website alone. The practical goal is to verify the operator’s instructions, make sure the proposed route matches your intended asset and network, and preserve enough evidence to diagnose the transaction if processing stops.
The operation state map
Use this map as both a checklist and a decision tree. Do not advance merely because the interface allows it. Each state has its own transition condition, observable sign of success and reason to stop.
- Task: define the intended outcome.
- Transition condition: You can state what you are sending, what you expect to receive and which wallet should receive it.
- Check: Record the two assets, the direction of exchange and the destination wallet under your control or belonging to the intended recipient.
- Success sign: The task can be described without relying on a rate, address or instruction supplied through an unsolicited message.
- If it does not match, stop: Do not continue when someone is pressuring you to “protect” funds, pay an unexpected debt or move cryptocurrency to a supposedly secure account. Requests of this kind are a recognized impersonation-scam pattern. [1]
- Input data: identify the exact asset and network.
- Transition condition: The sending wallet, exchange request and receiving wallet all support the same blockchain.
- Check: Distinguish native BTC from tokenized versions of bitcoin, native ETH from versions offered on other networks, and USDT on one blockchain from USDT on another. Tether issues USDT on multiple protocols, so the ticker alone does not identify the transfer route. [2]
- Success sign: The network name shown by the sender is identical to the network selected in the request and accepted at the destination.
- If it does not match, stop: Similar address formats, low fees or a familiar ticker are not evidence of compatibility. Do not assume that a service supports every pair, network or direction; check current availability before creating the request.
- Service verification: inspect the exchanger before opening an order.
- Transition condition: You have reached the intended domain independently and can find coherent terms, contact details and transaction rules.
- Check: Examine the domain spelling, connection security, operator information, support channel, privacy terms, exchange procedure, compliance conditions and explanation of charges. If the service makes a registration or authorization claim, verify that claim in the relevant official register rather than trusting a badge or logo.
- Success sign: The same operator identity, domain and support details appear consistently across the order interface and legal pages.
- If it does not match, stop: Leave if the site redirects to a look-alike domain, support moves the conversation to an unrelated account, or anyone requests a seed phrase, private key, wallet export or remote access. Legitimate support does not need secret wallet credentials to locate a blockchain transaction. Bitcoin’s official scam guidance specifically warns users never to disclose a seed phrase or private key. [3]
- Quote verification: calculate what will leave and arrive.
- Transition condition: The live request displays the send amount, expected receive amount, relevant charges, limits and any quote-expiry condition.
- Check: Determine whether the service charge is included in the displayed rate or deducted separately, and whether the sender’s network fee is additional. Confirm which party bears each charge.
- Success sign: The amount expected at the receiving wallet still satisfies the original task after all visible deductions.
- If it does not match, stop: Do not infer a missing fee, minimum or final amount. If the quote changes materially, the route no longer corresponds to the calculation you approved.
- Order verification: validate the deposit instructions.
- Transition condition: An active request shows the selected assets, exact network, deposit address, amount and any required Memo, Tag or other identifier.
- Check: Compare these details with the information reviewed in the previous states. Copy the deposit address from the active request, not from transaction history, a search result, chat message or old order.
- Success sign: The active order and wallet confirmation screen show the same asset, network, full destination address and amount.
- If it does not match, stop: A changed address, unexplained extra payment, unsupported network or newly introduced intermediary invalidates the checked route.
- Action: authorize the transaction.
- Transition condition: Every irreversible field has been checked on the wallet’s final confirmation screen.
- Check: Read the full address, not merely its first and last characters. Address-poisoning attacks are designed to place a similar-looking address in transaction history, which makes abbreviated comparisons unsafe. [3]
- Success sign: The wallet displays the intended recipient, asset, network, amount and network fee, with no unexplained contract approval or blind-signing request.
- If it does not match, stop: Reject the transaction rather than editing it under pressure. Once all checks pass, you can open the exchange request and verify its live route details.
- Waiting: monitor the blockchain and the order separately.
- Transition condition: The wallet has produced a transaction hash or transaction ID.
- Check: Use an appropriate blockchain explorer to confirm the network, sender, destination, amount, token contract where relevant, status and number of confirmations. Ethereum explorers can show whether a transaction is pending, failed or successful, as well as its addresses and block data. [4]
- Success sign: The transaction appears on the intended blockchain and accumulates the number of confirmations required for that route.
- If it does not match, stop: Do not send a duplicate simply because the exchanger has not yet credited the order. First determine whether the original transaction was broadcast, pending, failed or confirmed.
- Confirmed result or recovery path.
- Transition condition: The blockchain transfer satisfies the service’s confirmation requirement and the output transaction is identifiable.
- Check: Verify the output asset, network, destination, amount and transaction hash independently of the order’s “completed” label.
- Success sign: The expected asset is visible at the intended receiving address on the correct blockchain.
- If it does not match, stop: Preserve the order ID, transaction hashes and displayed instructions, then follow the diagnostic branches below. Never give support a seed phrase or private key.
Check the service before comparing rates
An attractive quote is irrelevant if the payment instructions cannot be trusted. Begin with the route by which you reached the service. Search advertisements, social-media replies and unsolicited messages can point to cloned pages. If you already know the genuine domain, enter it directly or use a saved bookmark rather than following an unexpected link. The FTC advises contacting a company through contact information you independently know to be genuine instead of using links or phone numbers in suspicious messages. [5]
Next, look for operational clarity. A usable exchange interface should explain what must be sent, what is expected in return, when a quote can change and how an unresolved order is handled. It should also provide a way to contact support without requiring secret wallet data. Missing documentation does not automatically prove fraud, but it removes information needed to evaluate the transaction and is a sound reason not to proceed.
Treat reviews as supporting evidence, not proof of safety. Review pages can contain outdated experiences, complaints about unrelated services or manipulated ratings. More useful signals are consistent operator details, a domain with no suspicious substitutions, understandable transaction rules and support that answers specific questions without creating urgency.
Compliance requirements may depend on the exchange direction and the result of screening checks. Confirm the current requirements before creating an order. If identity or source-of-funds information may be requested, decide whether you can provide it through the service’s documented process before sending cryptocurrency. Rules and available remedies also differ by country, so a service operating somewhere else may not offer the protections you expect locally.
Make the asset and network explicit
“Send USDT” is incomplete. USDT exists on multiple blockchains, and a receiving address intended for one protocol must not be assumed to accept another. Tether’s official documentation lists separate supported protocols and asks integrators to state clearly which ones they support. [2]
The same discipline applies to BTC and ETH. A wallet may label a token with a familiar asset name even when it operates on a different blockchain. The route is valid only if all three components agree:
- the network from which the funds will be sent;
- the network named in the exchanger’s deposit instructions;
- the network accepted by the final receiving wallet.
Do not choose a network solely because its displayed fee is lower. A cheaper incompatible route can result in funds not being credited and may leave no practical recovery method. If network terminology differs between interfaces, ask support for clarification before creating or funding the request. Do not ask support to choose based only on speed or price; ask it to confirm the exact protocol accepted for that order.
When a Memo or Tag appears
Some custodial destinations use one blockchain address for many customers and distinguish deposits with a Memo, Tag, message or similar identifier. BTC, ETH and USDT transfers do not universally require such a field, so never invent one. Use it only when the active deposit instructions explicitly provide it.
If an identifier is required, treat the address and identifier as a single destination. A correct address with an omitted or incorrect Memo or Tag may reach the receiving platform on-chain without being assigned automatically to the intended account. Stop if the sending wallet has no place to enter a required value; do not send and hope that support can recover it later.
Verify the address at the irreversible checkpoint
The last wallet screen is the decisive checkpoint because it shows what you are actually authorizing, not what an earlier web page promised. Compare the complete destination address against the active order. Malware can replace clipboard contents, and address poisoning can make an attacker’s address appear familiar by imitating visible characters. Bitcoin’s safety guidance recommends checking the entire receiving address rather than only its beginning or ending. [3]
If you scan a QR code, verify the decoded address on the wallet screen. The QR image is only an input method; it is not independent evidence that the destination is correct. Recheck the network and amount after scanning because a payment code can contain more than an address.
A test transaction can reduce address risk in some wallet-to-wallet transfers, but it is not automatically suitable for an exchange order. An exchanger may expect one exact deposit, apply a minimum, associate only one transaction with the request or create a new address for each order. Split the amount only when the service’s current instructions explicitly allow it. Otherwise, a “test” can create a separate processing problem rather than making the original order safer.
Separate the quote, service charge and network fee
Three figures can affect the result:
- The quoted exchange result is the amount the service says it will deliver under the displayed conditions.
- The service charge may be shown separately, included in the rate or deducted from one side of the exchange.
- The network fee pays for broadcasting and processing the blockchain transaction and is usually displayed by the sending wallet.
Do not assume that increasing the amount sent will automatically preserve the expected output. Some requests require an exact deposit, while others recalculate the result from the amount received. The active order must state how deviations are treated.
For Bitcoin, the network fee is related to transaction data size rather than simply to the monetary value being transferred. A higher fee can encourage faster inclusion, but it does not guarantee a specific processing time. [6] Ethereum transactions also require a fee, and the transaction data includes fee parameters that limit what the sender is willing to pay. [7]
Pause if the final wallet screen shows a materially different network fee from the one used in your calculation. Volatile crypto prices and expiring quotes can also change the economic result while a transaction is waiting. That does not necessarily mean the service is unsafe, but it may mean the current route no longer meets the original task.
Confirm the transaction without relying on the order label
After sending, save the transaction hash immediately. It is the primary reference for distinguishing a blockchain delay from an internal order-processing issue.
On Bitcoin, a broadcast transaction must be included in a block before it receives its first confirmation. Additional confirmations reduce the risk that the transaction will later be displaced by a chain reorganization, although each recipient decides how many confirmations it requires. [8]
On Ethereum, a transaction is broadcast to the network, enters a transaction pool, and must be selected by a validator for inclusion in a block. The transaction hash allows its lifecycle to be tracked, while later consensus stages increase confidence that the result will not change. [7]
Check more than the word “success.” Confirm that the explorer is displaying the intended blockchain and that the destination, asset and amount correspond to the order. For token transfers such as USDT, also verify the token identity or contract shown by the explorer. A successful transfer of the wrong token or on the wrong supported-looking network is not successful completion of the intended exchange.
Diagnose a delayed or incorrect transaction
No transaction hash was created
The wallet may not have broadcast the transfer. Check its activity log, network connection and signing status. Do not create a second payment until the wallet clearly shows that the first attempt was cancelled, rejected or never submitted. If the exchange quote has expired in the meantime, obtain new instructions rather than sending to an old address automatically.
The transaction is visible but pending
A pending transaction has been broadcast but has not yet been included in a block. Compare its fee status and network with current information shown by the wallet or explorer. Some wallets offer protocol-specific replacement or fee-adjustment functions, but these should be used only when the wallet explains their effect. Sending an ordinary second transaction can produce two payments instead of accelerating the first.
Keep the order open if possible and contact support with the order ID and transaction hash if its rules require notification. Avoid claims that a payment is “confirmed” when the explorer still marks it as pending.
The transaction failed
For an Ethereum-family transaction, inspect the explorer’s status and destination rather than assuming that every signed attempt transferred the token. Ethereum explorers distinguish pending, failed and successful transactions. [4] A failed attempt may still affect the sender through network fees, so calculate the remaining wallet balance before retrying.
Do not resend using the old quote until the exchanger confirms that the order remains valid and supplies consistent instructions.
The blockchain shows success, but the exchanger does not
Compare the confirmed transaction against the order one field at a time:
- blockchain and token;
- deposit address;
- Memo, Tag or other identifier, if required;
- amount received at the address;
- number of confirmations;
- order status and quote conditions.
If all fields match, give support the order ID and transaction hash. Screenshots may help explain what the interface displayed, but the on-chain record is the stronger reference for the transfer itself. Never disclose private keys, recovery words or wallet backup files.
The wrong address, network or identifier was used
Stop creating further transactions. Record the transaction hash, order instructions, destination and selected network. Contact the receiving platform through its verified support channel and describe the mismatch precisely.
Recovery is not guaranteed. It may depend on who controls the destination address, whether the receiving system supports the blockchain, the asset’s technical design and the provider’s policies. Tether, for example, states that it may attempt certain token recoveries only in specific cases and at its own discretion; that is not a general promise that incorrectly routed USDT can be returned. [9]
Ignore anyone who promises recovery in exchange for a seed phrase, private key or advance crypto payment. Fake support and recovery offers are themselves established scam types. [3]
What counts as a completed route
The exchange is complete only when the expected output asset is visible at the intended destination on the correct network and its transaction can be independently identified. A “paid,” “processing” or “completed” label on the exchanger’s page is useful operational information, but it is not a substitute for checking the receiving address and blockchain record.
Some uncertainty can remain: market movement may change the fiat-equivalent value, confirmation requirements can vary by direction, and compliance review may delay internal processing. Those factors should be distinguished from the verifiable core result: the correct asset, delivered to the correct address through the agreed network, with a traceable transaction hash.