A crypto exchange safety check is a structured pause before money moves. Its purpose is to catch a fake website, an unsupported route, a wrong blockchain network, a replaced address, or unclear terms while you can still stop. It cannot prove that an exchange is risk-free, prevent every technical failure, or guarantee recovery after an incorrect transfer.
The safest practical approach uses two passes. First, verify the exchange and the planned operation as a whole. Then, immediately before the irreversible step, compare every critical field again against a fresh, trusted source. Cryptocurrency transfers may be difficult or impossible to reverse without the recipient’s cooperation, so prevention matters more than attempted recovery. [1]
Express check: stop signals that require attention now
Do not create or pay an exchange request until you have investigated any of these warning signs:
- The website address differs from the domain you intended to visit, contains an extra character, or was opened through an unexpected message or advertisement.
- Someone asks for your seed phrase, private key, wallet backup, screen-sharing access, or remote control of your device.
- The exchange route does not identify the asset and blockchain network clearly.
- The payment address changes after you copy it, or the address displayed in your wallet differs from the address in the active request.
- A representative promises guaranteed returns, risk-free profit, or a special rate available only if you act immediately. Guarantees of crypto profits are a recognized scam warning. [2]
- You are told to ignore a wallet warning, use a different network from the one shown in the request, or omit a required Memo or Tag.
- Fees, verification conditions, the amount expected, or the amount to be received remain hidden until after payment.
- Support contacts you unexpectedly and requests another crypto payment to “unlock,” “verify,” or “recover” the first transfer.
A suspicious message does not become trustworthy because it contains familiar branding. Phishing pages are designed to imitate legitimate services and collect credentials or financial information; urgency, unexpected requests, and incorrect links are common warning signs. [3]
How to classify the result
| Result | Meaning | Action |
|---|---|---|
| Continue checking | The information is consistent so far, but the operation has not yet passed the final comparison. | Complete both passes and keep watching for changed fields. |
| Clarification required | A condition is missing, ambiguous, outdated, or cannot be confirmed independently. | Pause. Obtain the answer through a contact channel reached from the verified domain, then refresh the request if necessary. |
| Stop | A critical mismatch, secret-recovery request, fake-domain indicator, unsupported network, replaced address, or deceptive promise has appeared. | Do not send funds or approve a wallet transaction. Close the page and investigate from a clean starting point. |
“Continue checking” is not a safety guarantee. It only means that no decisive stop signal has been found at that stage.
Two-pass pre-operation verification card
Pass one: verify the context of the operation
Complete this pass before transferring funds to the address supplied by the exchange.
| Check | What to compare | Independent confirmation | What a mismatch means |
|---|---|---|---|
| Domain and connection | Compare the complete domain with the address you intended to open. Check spelling, the top-level domain, and whether the browser reports a certificate or connection warning. | Use a previously saved bookmark or type the known domain yourself. Do not treat a search advertisement, social-media profile, email, or direct message as independent confirmation. | An altered domain, unexpected redirect, or browser warning is a stop result. Do not enter credentials or transaction information. |
| Operator identity and claims | Check whether the site clearly identifies the service, publishes usable support channels, and makes any regulatory or authorization claims that affect your decision. | If authorization is claimed, compare it with the relevant official regulator’s public register. Rules and registration systems differ between countries. | An unverifiable or contradictory claim requires clarification. A demonstrably false identity or authorization claim is a reason to stop. |
| Exchange direction | Confirm which asset you will send and which asset you expect to receive. Read both sides of the route rather than relying on asset icons. | Compare the request page with the service’s current asset and direction selector. | A reversed direction or different asset can produce an unintended transfer. Do not continue until the request is corrected. |
| Current asset availability | Verify that the chosen asset is available for the requested direction at the time of the operation. | Use the current request interface rather than an old screenshot, cached page, review, or third-party listing. | If the interface does not offer the route, do not assume support. Choose another available route or seek clarification. |
| Current service scope | Check that the specific operation is already live rather than merely announced or planned. | Confirm availability directly in the current exchange form and its terms. | A planned feature cannot be treated as operational. For example, exchanging rubles from a bank card to cryptocurrency and back is planned for this service, not presented here as an active function. |
| Blockchain network | Compare the network selected by the sender with the network required by the receiving side. The asset name alone is insufficient when an asset can exist on more than one network. | Use the active request, the receiving wallet’s deposit instructions, and official documentation for the relevant asset or network. | Different network names, unclear token standards, or conflicting instructions require a pause. Never choose a network solely because its fee appears lower. |
| Address format | Check whether the destination address has the expected format for the selected network. Do not shorten the comparison to only the first and last few characters. | Compare the entire address with the source that generated it. Official Bitcoin safety guidance likewise recommends checking the complete receiving address rather than only its edges. [4] | An invalid format is a stop signal. A valid-looking format does not prove ownership, so the full address must still match. |
| Memo, Tag, or similar identifier | Determine whether the destination requires an additional identifier and whether it must accompany the address. | Use the active request and the destination platform’s deposit instructions. Do not infer the requirement from a previous transfer. | A missing, extra, or different identifier requires clarification before payment. It may affect whether the recipient can attribute the transfer correctly. |
| Rate type and calculation basis | Check whether the displayed rate is fixed for a stated condition or recalculated, and identify which amount is an estimate rather than a final value. | Read the current request terms and calculation details. Compare the send amount, stated deductions, and estimated or final receive amount. | If the calculation cannot be reproduced from the displayed information, pause and request clarification. Do not infer an undisclosed fee or assume the best possible rate. |
| Fees and deductions | Identify the service fee, network fee, and any other deduction actually disclosed for the route. Determine which party pays each one. | Compare the request summary with the sending wallet’s confirmation screen. Network conditions can change, so an earlier quote may no longer apply. | An unexplained deduction or a material change requires clarification before approval. |
| Limits and timing conditions | Check any displayed minimum, maximum, quote-expiry condition, payment window, and confirmation requirement. | Use the active request rather than generic promotional text or third-party descriptions. | A payment outside the stated conditions may be processed differently or require manual review. Create a new request if the current one is no longer valid. |
| Verification and compliance conditions | Review which checks may apply to this direction and what happens if additional information is requested. | Use the service’s current terms and support channel reached through the verified domain. | Requirements can depend on the operation and compliance results. If the conditions are unacceptable or unclear, do not create or fund the request. Do not attempt to bypass them. |
| Source of every instruction | Record where the address, network, Memo or Tag, amount, and deadline came from. | Prefer the active request and official wallet or network documentation over copied messages, screenshots, chat posts, and search snippets. | Conflicting sources require clarification. A private message should not override the details displayed in a verified active request. |
Pass two: repeat the critical comparison immediately before approval
Perform this pass after the transfer has been prepared in the wallet but before selecting Send, Confirm, Approve, or an equivalent irreversible action. If the page refreshed, the quote expired, or any field changed, return to pass one.
| Check | What to compare | Independent confirmation | What a mismatch means |
|---|---|---|---|
| Destination address | Compare the full address shown in the wallet confirmation screen with the address in the active exchange request. | Read both values directly on trusted screens. For a hardware wallet, also verify the address on the device display where supported. | Any changed character is a stop result. Delete the prepared transaction and investigate possible clipboard replacement or page tampering. |
| Selected network | Confirm that the wallet is about to broadcast on the exact network required by the request. | Compare the network label in the wallet, the request, and the destination instructions. | Similar asset symbols do not resolve a network mismatch. Cancel the transaction and select a compatible route. |
| Memo or Tag | Compare the complete identifier and confirm whether it is mandatory. | Use the active request rather than memory, transaction history, or instructions from another account. | A missing or different identifier requires cancellation and correction before sending. |
| Amount being sent | Check the asset, decimal placement, and exact amount entered in the wallet. | Compare the wallet confirmation with the request summary. Account for any network fee deducted separately or from the balance. | A different asset, misplaced decimal, or amount outside the displayed conditions requires correction or a new request. |
| Expected amount to receive | Review the latest displayed result after disclosed fees and any stated recalculation conditions. | Use the current request summary, not an earlier browser tab or screenshot. | An unexplained change requires clarification. Crypto prices and network costs can vary, but variation does not justify hidden terms. |
| Request validity | Confirm that the request is still active and that its payment details have not expired or been replaced. | Refresh only through the verified service interface and recheck all fields after refreshing. | Do not send to an expired request merely because its address remains visible. Create a new request if instructed by the verified interface. |
| Request identifier | Confirm that the identifier on the payment page matches the request whose terms you reviewed. | Compare the request summary and any confirmation page within the same verified session. | A different identifier may indicate that you are viewing another request or a stale page. Pause and locate the correct operation. |
| Wallet authorization details | Read the wallet’s final confirmation, including the destination, asset, amount, network fee, and any contract interaction shown. | Rely on the wallet or signing-device display, not solely on the website requesting approval. | Unexpected permissions, unlimited token approvals, an unfamiliar contract, or fields unrelated to the planned exchange are stop signals. |
| Last-minute communication | Check whether anyone has sent replacement details or pressured you to act without repeating the card. | Verify changes through support reached independently from the confirmed domain. | Do not follow address changes delivered only by email, messenger, telephone, or social media. |
After completing both passes without an unresolved mismatch, one possible next step is to check the current exchange conditions. Availability should still be confirmed for the exact asset, direction, and network before creating a request. The service supports assets including USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX and is gradually expanding its selection, but this does not mean that every pair or network is available.
Control route before, during, and after the operation
Before sending
- Open the service from a trusted starting point and complete pass one.
- Create a fresh request rather than reusing details from an earlier operation.
- Prepare the transfer and complete pass two on the final wallet screen.
- If the amount is significant to you, consider whether a smaller permitted test transfer is practical. A test reduces the size of an initial mistake but does not prove that a later transfer will succeed.
- Keep enough balance for the network fee if the wallet charges it separately.
While waiting
- Keep the request identifier and transaction ID, or txid, available.
- Check the transaction through an appropriate blockchain explorer using the txid. Blockchain records may show fields such as addresses, amounts, and transaction status, although the available details differ by network. [2]
- Distinguish between a wallet broadcast, network confirmation, service recognition, compliance review, and completion of the outgoing transfer. These are separate stages.
- Do not send a duplicate payment merely because the status page has not updated.
- Reject unsolicited “recovery” messages or requests for another payment.
After confirmation
- Compare the asset and amount received with the final terms applicable to the request.
- Confirm that the funds arrived in the intended wallet or account and on the expected network.
- Record the outgoing and incoming txids when both exist.
- Remove unnecessary token approvals if the operation involved a smart-contract permission that is no longer needed.
- Close the session on a shared device and retain only the non-secret records needed for support, accounting, or lawful reporting.
If the status is delayed, the amount differs, or the details change
A delay or discrepancy does not identify the cause by itself. Diagnose the stage before taking another action.
- Confirm that the transaction was broadcast. Locate the txid in the sending wallet. If no txid exists, the wallet may not have submitted the transaction.
- Check the correct blockchain explorer. Search by txid, not by sharing your seed phrase or private key. Confirm the network, destination, amount, and current confirmation status.
- Compare the on-chain record with the request. Check whether the address, Memo or Tag, asset, network, and amount match the original instructions.
- Check the request state. Determine whether the exchange has detected the payment, is waiting for confirmations, requires clarification, or has marked the request as expired.
- Preserve evidence safely. Keep the request identifier, txid, timestamps, displayed terms, and relevant non-secret screenshots. Do not edit the original files.
- Contact support from the verified domain. Describe the discrepancy and provide only the information necessary to locate the request. Never provide wallet recovery words or private keys.
- Do not pay an unsolicited recovery service. Fraudsters may impersonate companies or authorities and demand a fee to recover crypto. The FTC warns against paying people who make unexpected recovery offers. [5]
Support may be able to diagnose some attribution, processing, or account issues, but recovery cannot be promised. The available options depend on the network, destination, transaction details, service rules, and compliance outcome.
Threats directly relevant to an exchange transaction
Phishing and impersonation
A phishing page may copy the appearance of a real exchange while using a different domain. It may also display a wallet-connect request, steal login credentials, or replace payment instructions. Avoid opening exchange pages from unexpected messages. Type the known address yourself or use a verified bookmark, enable multifactor authentication where available, and treat urgency as a warning rather than a reason to skip checks. CISA recommends recognizing phishing, using strong passwords, enabling multifactor authentication, and keeping software updated. [3]
Clipboard and address replacement
Malware can replace a copied crypto address with an attacker’s address. Compare the entire destination after pasting it and again on the wallet’s final confirmation screen. Do not rely exclusively on matching the first and last characters, because deceptive addresses can be constructed to look similar. An address copied from transaction history may also be unsafe if an attacker has created a misleading look-alike entry. [4]
Wrong blockchain network
The same asset name may appear in several network contexts. The sender and recipient must use a compatible network, and the receiving service must support that network for the specific deposit. Do not assume that an address accepted by a wallet proves the route is supported. If the network labels differ or remain ambiguous, stop and request clarification before broadcasting.
Seed phrase or private-key exposure
A seed phrase or private key controls access to wallet funds. It is not needed to identify an exchange request, check a txid, receive ordinary support, or investigate a delayed status. A website, support account, or “recovery specialist” asking for it should be treated as hostile. Official Bitcoin safety guidance similarly states that legitimate support should not request a seed phrase or private key. [4]
Guaranteed-return claims
An exchange transaction and an investment offer are different activities. If someone directs you to an exchange as part of a promise of guaranteed profit, automatic income, or a no-risk trading scheme, stop evaluating the exchange request and investigate the wider offer. Cryptocurrency values can change rapidly, and no legitimate party can guarantee an investment return. [6]
Safe record-keeping protocol
Retain only the information needed to identify and reconstruct the operation:
- exchange request identifier;
- date and approximate time of creation and payment;
- assets and exchange direction;
- selected blockchain network;
- amount sent and the applicable expected amount shown in the request;
- outgoing and incoming txids, where available;
- non-secret copies of the displayed terms and relevant status messages;
- support case identifier and the verified channel used.
Do not store seed phrases, private keys, wallet backup files, authentication codes, passwords, or unnecessary identity documents with the transaction record. Redact unrelated personal information before sharing evidence. The completed record should make the operation traceable without granting anyone control of the wallet.
