How to Check a Crypto Exchange Service Before Swapping BTC, ETH, or USDT

A safe crypto exchange starts before any coins leave your wallet. Your goal is to confirm that the website is genuine, the requested route is actually available, the order terms are clear, and the receiving address matches the correct asset and network. If one of these checks fails, do not try to “see what happens” with a live transfer: blockchain transactions are generally difficult or impossible to reverse without the recipient’s cooperation. ^[1]

Define the exact exchange you need

Write down the route in one line: the asset you will send, the network used to send it, the asset you expect to receive, the receiving network, and the wallet that should receive the result. “Exchange USDT” is not precise enough because USDT exists on multiple networks. An address that looks valid in a wallet may still be unsuitable for the route selected in the exchange form.

Check current availability before creating an order. Support for a coin does not guarantee that every pair, network, amount, or direction is open. If the available route differs from your plan—for example, the form offers another USDT network—stop and decide whether your sending and receiving wallets support that exact network. Do not select a different network merely because its displayed fee is lower.

You should also know who controls the destination wallet. If you are receiving funds at another platform rather than a self-custody wallet, open that platform’s deposit screen and generate fresh deposit details for the intended asset and network. Do not reuse instructions from an old screenshot, message, or previous order without checking them again.

Operation state map

1. Task: define the intended result.
   1. Transition condition: you can name the sending asset, receiving asset, both networks, and destination wallet.
   2. Check: compare your written route with the options currently displayed by the exchange service.
   3. Success sign: every asset and network matches, without assumptions about unavailable pairs.
   4. If it does not match, stop: do not substitute another network or asset unless you deliberately redefine the task and repeat all checks.
2. Input data: inspect the service before creating an order.
   1. Transition condition: you reached the website independently rather than through an unexpected message, advertisement, or support account.
   2. Check: inspect the domain spelling, certificate warning status, published terms, contact method, order process, and explanations of rates, fees, compliance requirements, and problem handling.
   3. Success sign: the domain is consistent across pages, the browser shows no security warning, and the service explains what information will be required before funds are sent.
   4. If it does not match, stop: leave if the page imitates another brand, redirects unexpectedly, hides material order terms, or asks for a wallet recovery phrase or private key.
3. Verification: review reputation and order conditions.
   1. Transition condition: the website itself has passed the basic identity and phishing checks.
   2. Check: look for independent reports about unresolved transfers, changed deposit addresses, inaccessible support, or demands for additional payments. Read recent and older reports rather than relying on a single score.
   3. Success sign: you find a consistent operating history and can distinguish documented complaints from unsupported promotional claims.
   4. If it does not match, stop: do not proceed when the only visible feedback is copied, anonymous, uniformly promotional, or contradicted by repeated reports with verifiable transaction details.
4. Action preparation: create and inspect the order.
   1. Transition condition: the route is available and you understand the service’s stated requirements for that direction.
   2. Check: verify the assets, networks, recipient address, quoted output, applicable fees, amount limits, rate type, and any displayed validity period. Confirm current verification requirements before creating or funding the order, because they may depend on the route and compliance review.
   3. Success sign: the order summary still describes the task you wrote down at the beginning.
   4. If it does not match, stop: cancel if the output asset changes, the expected amount becomes unclear, a new requirement appears that you cannot satisfy, or the deposit instructions conflict with the order summary.
5. Irreversible action: prepare the transfer.
   1. Transition condition: the order is active, and its deposit instructions are visible directly inside the verified website session.
   2. Check: copy the address from the active order, compare the complete address after pasting, select the specified network, and add a Memo or Tag only when the receiving instructions require one.
   3. Success sign: your wallet’s final confirmation screen shows the expected asset, network, address, amount, and network fee.
   4. If it does not match, stop: reject the wallet confirmation if any character, network name, amount, or required Memo/Tag differs.
6. Waiting: monitor the blockchain and order separately.
   1. Transition condition: your wallet has broadcast the transfer and produced a transaction hash.
   2. Check: use a suitable blockchain explorer to verify the sender, recipient, amount, network status, and confirmations. Then compare the transaction with the status shown in the order.
   3. Success sign: the explorer recognizes the transaction, confirmations increase, and the service associates the deposit with the correct order.
   4. If it does not match, stop: do not send a duplicate payment or an additional “unlock” fee. Move to the diagnostic steps below.
7. Result: confirm receipt or begin recovery diagnostics.
   1. Transition condition: the service marks the exchange as completed or reports a specific problem.
   2. Check: confirm the incoming transaction in the correct wallet and network, then compare the received asset and amount with the final order record.
   3. Success sign: the receiving wallet or platform shows the correct asset as credited, with an independently verifiable transaction hash where the network provides one.
   4. If it does not match, stop: preserve the order ID, transaction hashes, addresses, timestamps, screenshots, and support correspondence. Do not create another transfer to compensate for the missing one.

How to check the exchange service itself

A padlock icon and an encrypted connection protect data in transit, but they do not prove that the operator is trustworthy. Check the exact spelling of the domain and avoid opening an exchange through links in unsolicited emails, private messages, search advertisements, or “support” replies on social media. Phishing pages often reproduce the appearance of a real service while replacing its deposit address.

Review the information available before payment. You should be able to understand how an order is created, when its terms are fixed or recalculated, which fees may apply, what happens if the sent amount differs, and how to contact support. If a service claims registration, licensing, or a legal entity, verify that statement in the relevant official database rather than treating a logo or registration number on the website as proof. Rules and consumer protections differ between countries, so registration in one place should not be interpreted as universal protection.

Be cautious if anyone pressures you to act quickly, promises guaranteed returns, asks for remote access to your device, or demands your recovery phrase. A legitimate exchange operation requires a public receiving address; it does not require the secret words or private key that control your wallet. The FTC also warns that cryptocurrency payments usually lack the dispute protections associated with card payments and are typically not reversible. ^[2]

Check the asset, network, address, and Memo or Tag

Asset and network

BTC should be sent only according to the Bitcoin deposit instructions supplied for the active order. ETH and tokens such as USDT require an additional network check because similar address formats can appear across different networks. Match the network name in three places: the exchange order, the sending wallet, and the receiving wallet’s deposit instructions.

If your wallet does not offer the network named by the order, the route is not compatible with your current setup. Do not guess based on address appearance. Cancel the order or choose a route that all involved services explicitly support, then repeat the checks from the beginning.

Recipient address

Copy the deposit address from the active order and compare it after pasting into your wallet. Clipboard malware can replace copied crypto addresses, so checking only the first and last few characters is weaker than checking the full value. Bitcoin.org specifically advises verifying the complete receiving address because confirmed Bitcoin transfers cannot be unilaterally undone. ^[1]

Stop if the address changes unexpectedly while the order remains active. Do not accept a replacement address sent through a private message unless you can independently confirm it through the service’s authenticated order interface and official support process.

Memo or Tag

A Memo or destination Tag is an extra identifier used by some receiving platforms to assign a deposit made to a shared address. It is separate from the wallet address. When the receiving instructions display a required Memo or Tag, copy and verify both fields. An omitted or incorrect identifier may prevent automatic crediting and can require manual investigation, without any guarantee of recovery. ^[3]

Do not invent a Memo or add one merely because your wallet offers an optional field. Follow the current instructions for the exact receiving asset, network, and platform.

Review the amount, fees, and final confirmation screen

Separate three figures that are easy to confuse: the amount you send, the network fee charged by your wallet, and the amount expected at the destination. The order may also describe an exchange fee or show a rate that can change under stated conditions. Read the current summary instead of calculating the result from an earlier page or advertisement.

For Ethereum transactions, the network fee pays for the computation needed to process the transaction and is distinct from the transferred value. A submitted transaction includes fields such as the receiving address, value, and fee settings, and it must be included in a validated block before it succeeds. ^[4]

Immediately before approving the transfer, pause at the wallet confirmation screen. Check the asset, network, full address, amount, required Memo or Tag, and network fee. This is the last reliable control point before broadcast. If the amount shown by the wallet would leave the order below a stated minimum because the fee is deducted from the transfer itself, cancel and correct the setup rather than sending an uncertain amount.

After the domain, route, order terms, address, network, and wallet confirmation screen have all been checked, you can open the exchange form and verify the currently available route. Treat the information displayed for the new order as the applicable information; availability and requirements may change between operations.

What to do when a transaction is delayed or incorrect

Begin with the transaction hash, not with the wallet’s balance display. A blockchain explorer can show whether the transfer was broadcast, whether it is still pending, whether it failed, and whether it reached the address supplied by the order. Ethereum documentation describes the transaction hash as the identifier generated when a transaction is submitted; the transaction then waits for a validator to include it in a block. ^[4]

• No transaction hash exists: the wallet may not have broadcast the transfer. Check the wallet’s activity and network connection. Do not tell support that payment was completed until a transaction can be identified.
• The explorer cannot find the hash: confirm that you are using an explorer for the actual sending network. Also check whether the wallet reports the transfer as queued, rejected, or replaced.
• The transaction is pending: network congestion or fee settings may delay inclusion. For Bitcoin, a lower-priority fee can make the first confirmation take longer, and confirmation time has no guaranteed minimum or maximum. ^[1]
• The transaction failed: a failed transaction is not the same as a successful deposit. Compare the explorer’s status, transferred value, and fee information before considering another attempt.
• The transaction is confirmed but the order shows no deposit: compare the recipient address, asset, network, amount, and Memo or Tag with the active order. Send support the order ID and transaction hash, but never your recovery phrase or private key.
• The service completed the order but the output is missing: request the outgoing transaction hash and inspect it on the correct network. Check whether the receiving platform requires additional confirmations before crediting the deposit.
• The wrong network or address was used: stop sending further funds. Contact the operator that controls the destination address and provide accurate transaction details. Recovery may be technically impossible, unsupported, subject to additional checks, or dependent on the recipient’s cooperation.

Keep the original order page, status messages, transaction hashes, and correspondence. Do not pay an unexpected “recovery,” “verification,” or “release” charge solely because someone contacts you after the problem appears. Verify any support request through the same independently checked website.

When the route is complete

The route is complete only when the intended asset appears in the intended wallet on the intended network and the result can be matched to the exchange order and blockchain record. An order marked “completed” is useful evidence, but it should be checked against the receiving wallet rather than treated as the only proof.

Some uncertainty may remain: a receiving platform may wait for more confirmations, compliance review may depend on the operation and its results, and the final amount may reflect terms disclosed for the particular order. If the verifiable result does not match your original task, preserve the records and use the diagnostic branch instead of repeating the payment.