A convincing exchange page can still contain a substituted deposit address, an unsupported USDT network, or terms that change at the final step. Use this two-pass pre-transaction check before sending BTC or USDT: first validate the exchange context, then repeat the critical fields immediately before approving the irreversible transfer. This process reduces avoidable mistakes but cannot prove that a service is safe or eliminate every technical, compliance, market, or counterparty risk.
Express check: stop signals that require action
Do not open your wallet’s confirmation screen until you have cleared these signals:
- Stop: the page asks for a seed phrase, private key, wallet backup, or remote access to your device. Anyone who obtains a recovery phrase or private key may control the associated funds; legitimate wallet support should not request these secrets. [1]
- Stop: the domain differs by one character, uses an unexpected subdomain, or was reached through an unsolicited message, advertisement, QR code, or support chat. Typosquatting sites may imitate legitimate pages to steal information or deliver malware. [2]
- Stop: a representative replaces the deposit address in chat, email, or a direct message after the order was created.
- Stop: the sender promises guaranteed returns, risk-free profit, or multiplication of the BTC or USDT you transfer. The FTC identifies guaranteed crypto profits and large guaranteed payouts as scam indicators. [3]
- Clarify: the order and wallet show different assets, networks, amounts, Memo/Tag requirements, or receiving addresses.
- Clarify: the displayed rate, fee, amount due, or amount to receive changes without an understandable explanation before payment.
- Clarify: support claims that an expired or cancelled order remains payable, but the order page does not confirm this.
A padlock icon and encrypted connection are useful transport protections, but they do not establish who operates a website. Treat the exact domain, order data, and independently obtained support channel as separate checks.
Two-pass pre-transaction verification card
Pass one: verify the operation context
| What to compare | Independent confirmation | What a mismatch means |
|---|---|---|
| Exact domain | Open the address from a previously saved bookmark or type the known domain manually. Compare every character, including the top-level domain and any subdomain. Do not rely on the name displayed in an advertisement or message. | A character substitution, extra word, unusual subdomain, or redirect may indicate phishing. Stop and locate the service through a source you already trust. |
| Exchange direction | Confirm which asset you send and which asset you receive on the order summary. Compare this with the balances and asset labels in your sending and receiving wallets. | If the direction is reversed or an asset changed, do not pay the order. Recreate or clarify it rather than interpreting the fields yourself. |
| Asset and network | Check the network name on the exchange order, the withdrawal screen, and the receiving platform’s deposit instructions. USDT exists on multiple blockchain protocols, and Tether advises users to select the correct transport protocol for the destination. [4] | The same “USDT” label does not make different networks interchangeable at the transfer interface. If the network names do not match exactly, stop. Sending to an unsupported destination can cause loss and does not create a right to recovery. [5] |
| Current availability | Verify that the required asset, network, pair, and direction are offered on the live order page before creating the transaction. The service supports assets including BTC and USDT, but this does not imply that every pair, network, or direction is currently available. | If the required configuration is absent, do not substitute a similar network or select another asset merely because its address format looks familiar. |
| Rate, fees, and amounts | Read the order summary and applicable terms shown for that specific operation. Record which value is fixed, estimated, or subject to recalculation, if the interface makes that distinction. | An unexplained difference between the amount due and the amount you prepared requires clarification. Do not assume that an extra transfer will correct it. |
| Verification conditions | Check the requirements displayed for the chosen direction before creating the order. Requirements may depend on the operation and the results of compliance checks. | A request that conflicts with the published order flow, especially one delivered only through a private message, should be verified through an independently reached official channel. Do not attempt to bypass identity, sanctions, geographic, or legal restrictions. |
| Source of every instruction | Separate information shown inside the authenticated order from instructions in email, social media, messengers, search advertisements, or unsolicited calls. | If an external message introduces a new address, payment amount, deadline, or “verification deposit,” stop. Do not let urgency override the order data. |
Pass two: repeat critical fields immediately before sending
Perform this pass after entering the transaction in your wallet but before pressing the final Send, Withdraw, or Confirm button. Read from the original order again; do not verify one clipboard copy against another copy of the same potentially substituted value.
| What to compare | Independent confirmation | What a mismatch means |
|---|---|---|
| Full destination address | Compare the entire address in the wallet confirmation with the address on the active order. Inspect the middle characters as well as the beginning and end. Avoid taking the address from wallet history: address-poisoning attacks use look-alike addresses to exploit abbreviated displays and hurried copying. [6] | Any different character means a different destination. Cancel the transaction, clear the clipboard, and investigate possible clipboard malware, a stale order, or address substitution. |
| Selected network | Read the network label in the wallet’s final confirmation and compare it with the order. For BTC, distinguish the requested transfer method from any unrelated network option. For USDT, confirm the specific blockchain requested by the order. | Different network labels are a stop condition even when the wallet accepts the address or the address appears structurally compatible. |
| Memo, Tag, or other identifier | If the order or receiving platform displays an additional identifier, confirm whether it is required and copy it into the corresponding wallet field. If no identifier is displayed, do not invent one. | A required but missing or altered identifier may prevent automated crediting. Pause and obtain clarification before sending. |
| Amount sent | Compare the wallet’s transfer amount with the order’s required amount and asset denomination. Check whether the wallet deducts its network fee separately or from the amount being sent. | If fee handling would make the recipient receive less than required, cancel and correct the transaction. Never send an additional amount merely because an unsolicited contact tells you to “complete verification.” |
| Expected amount received | Reopen the current order summary and review the displayed outcome and any stated recalculation conditions. Account for crypto-asset volatility where the exchange terms make the result variable. | If the outcome changed, decide whether the current terms remain acceptable before sending. A changed value is not permission to rely on an earlier screenshot. |
| Order status | Confirm that the order is active and ready for payment in the service interface itself. | An expired, cancelled, duplicated, or already-paid order should not receive another transfer without explicit clarification through an independently verified channel. |
| Wallet confirmation details | On a hardware wallet, compare the address and amount on the device screen rather than relying only on the computer or phone. On any wallet, stop if the confirmation presents an unfamiliar contract interaction or requests broader permissions than the intended transfer. | Unexpected transaction content can indicate the wrong operation or a compromised interface. Reject it instead of signing to see what happens. |
After completing both passes without unresolved discrepancies, one possible next step is to check the current exchange conditions. Availability and verification requirements still need to be confirmed for the specific operation.
Classify the result without treating it as a safety guarantee
- Continue checking: the independently opened domain, active order, asset, network, full address, required identifier, amount, and final wallet screen agree. This means the reviewed fields are internally consistent, not that the operator or transaction is risk-free.
- Clarification required: a fee treatment is unclear, the expected amount changed, an order appears expired, a Memo/Tag rule is ambiguous, or current compliance requirements are not shown clearly. Do not broadcast the transaction until the discrepancy is resolved through a channel reached independently of the suspicious message.
- Stop: the address or network differs, the site requests a seed phrase or private key, instructions come only from an unsolicited contact, the order demands an additional “unlock” payment, or anyone guarantees profit. Close the page and preserve non-secret evidence for reporting.
Control route before, during, and after the exchange
Before the transfer
- Secure the device and update the wallet, browser, and operating system through their official distribution channels.
- Open the exchange independently and create only the required order.
- Complete pass one before copying an address.
- Copy the deposit address from the active order, then compare it after pasting.
- Complete pass two on the wallet’s final confirmation screen.
- If the wallet and service support a small test transfer and the order terms permit it, consider whether it is appropriate. Do not split an order when partial payments are not supported or when doing so would change the terms.
While waiting
Keep the order page available, but do not repeatedly send funds because the balance has not updated. Use the transaction ID in the correct blockchain explorer to check whether the transaction exists, whether it is pending or confirmed, and whether the destination and amount match. Block explorers can expose fields such as transaction hash, status, block, timestamp, sender, and recipient, depending on the network. [7]
A delay alone does not establish fraud. Network confirmation, service processing, and compliance review are separate stages. Bitcoin confirmation time is probabilistic rather than guaranteed, and confirmed Bitcoin payments generally cannot be reversed by a central authority. [8]
After confirmation
Compare the explorer record with the order one final time. Then check whether the exchange has acknowledged the incoming transaction and whether the delivered asset, network, and amount agree with the finalized order terms. Do not follow “recovery agents” who contact you first or ask for another crypto payment, wallet secret, or remote device access.
If the status is delayed, the amount differs, or data changes
- Do not send a second payment. First determine whether the original transaction was actually broadcast.
- Check the correct explorer. Search using the txid, not a screenshot or an address supplied by a third party. Confirm the network, status, amount, and destination.
- Compare the order history. Record whether the address, amount, rate conditions, or status displayed by the service changed after payment.
- Rule out wallet display issues. Confirm the transaction through an independent explorer suitable for the selected blockchain.
- Contact support independently. Open the support route from the verified service domain. Provide the order identifier and txid, plus a concise description of the discrepancy. Never provide a seed phrase, private key, wallet backup, authentication code, or unnecessary identity documents.
- Preserve evidence. Keep timestamps and screenshots of the relevant order fields and messages, while redacting unrelated balances and personal data.
- Report suspected phishing. If a look-alike domain, fake representative, or substituted address was involved, report the account or domain to the platform through which it reached you and to the appropriate authority in your country.
These steps may help identify where the transaction stopped or which data differed. They do not guarantee crediting or recovery. Recovery feasibility depends on the blockchain, destination, control of the receiving address, service policies, and applicable compliance and legal requirements.
Threats directly relevant to a BTC or USDT exchange
- Phishing exchange: a cloned page can reproduce branding and order forms while directing deposits to an attacker. Verify the exact domain independently and distrust instructions introduced through urgent messages.
- Address substitution: clipboard malware or a compromised page may replace the copied destination. Compare every character after pasting. A look-alike entry in transaction history may also be an address-poisoning attempt. [6]
- Wrong network: USDT is issued across multiple blockchain protocols. The sending wallet and receiving service must support the same selected network; a familiar asset ticker is insufficient confirmation. [4]
- Seed-phrase theft: an exchange transaction requires a public receiving address and a wallet signature or withdrawal approval—not disclosure of the recovery phrase. If a page asks for the phrase, stop interacting with it. [9]
- Guaranteed-profit lure: an exchanger should not need to promise that sending BTC or USDT will produce guaranteed investment returns. Such claims are a scam signal, not an exchange condition. [3]
Minimal record to keep after the operation
Retain only the data needed to trace and discuss the transaction: the order identifier, txid, date and time, asset, selected network, sent amount, final credited amount, and relevant non-secret correspondence. A txid is intended to identify an on-chain transaction; it is not a private key.
Do not store the seed phrase, private key, wallet backup, one-time authentication codes, or passwords with the order record. Avoid collecting unnecessary personal information or publishing wallet details and balances. The final record should help reconstruct what happened without creating a second security risk.