A pre-exchange security check helps you detect phishing, an unsupported network, an altered deposit address, or unclear transaction terms before you send BTC, ETH, or USDT. It cannot prove that an exchange service is completely safe or eliminate blockchain, counterparty, compliance, and volatility risks. Its practical purpose is narrower: identify inconsistencies early and stop an irreversible transfer when the evidence does not match.
Express check: stop signals before creating an order
Do not proceed to payment if any of these warning signs appears. Resolve the issue through a contact channel obtained independently from the website or choose another service.
- The domain is unfamiliar or misspelled. Avoid opening the exchange page from an unsolicited email, advertisement, direct message, or search result without checking the domain. Ethereum’s security guidance notes that convincing copies of legitimate websites may redirect users, request secrets, or provide an attacker’s address. [1]
- The requested asset or network is not shown in the order. “USDT” alone is not a complete transfer instruction because the token may operate on different networks. The sending wallet, receiving address, and order must refer to the same supported network.
- The service asks for a seed phrase or private key. Stop immediately. A recovery phrase gives control over the wallet and should never be disclosed to an exchange, support representative, verification page, or recovery specialist. [2]
- The address changes after you copy it. Do not rely on the clipboard value. Compare the complete address displayed by the exchange with the address shown on the signing device or wallet confirmation screen.
- The terms change without explanation. A different amount, asset, network, fee treatment, recipient address, Memo/Tag requirement, or expected payout requires a new review.
- Someone promises guaranteed returns. An exchange operation should not depend on claims that sending crypto will produce guaranteed profit, multiply funds, or remove all risk. The US Federal Trade Commission identifies guaranteed crypto returns and similar promises as scam indicators. [3]
Two-pass pre-operation verification card
Complete the first pass while selecting the exchange direction and reading the conditions. Complete the second pass in the final wallet or payment screen, immediately before the irreversible action. Information copied during the first pass may no longer be reliable if the order has expired, the page has changed, or clipboard contents have been replaced.
Pass 1: verify the operation context
| What to verify | Independent confirmation | What a mismatch means |
|---|---|---|
| Domain and page origin | Compare the browser address with a domain obtained from a previously saved bookmark, an independently located official profile, or earlier verified service communication. Check the entire hostname, not only the logo and page design. | A spelling variation, unexpected subdomain, unusual redirect, or certificate warning is a stop signal. A familiar interface does not authenticate a website. |
| Exchange direction | Read both sides of the order: the asset you send and the asset you receive. Confirm the direction against your own intended operation rather than a message sent by another person. | If the assets are reversed or the destination differs from your plan, do not fund the order. Recreate it with the correct direction. |
| Asset identity | Verify the ticker and, for tokens, the relevant network or contract information through official project documentation and an appropriate blockchain explorer. | A matching ticker does not necessarily identify the same token. Ethereum documentation warns that unrelated token contracts can use identical names and symbols. [1] |
| Network | Compare the network named in the order with the withdrawal network in the sending wallet or platform. Confirm current support in the exchange interface before creating the transfer. | If the networks differ, funds may not be credited and recovery may be impossible or dependent on the recipient’s technical capabilities and policies. Do not guess based on address appearance. |
| Pair and route availability | Check the live order form rather than relying on an old article, screenshot, or previous transaction. The service works with assets including BTC, ETH and USDT, but this does not imply that every pair, network, or direction is currently available. | An unavailable route means the intended operation cannot proceed in its current form. Do not substitute another network or asset without conducting a fresh review. |
| Displayed conditions | Read the current calculation, rate mechanism, fee information, limits, order validity conditions, and any possible recalculation rules shown before confirmation. | Missing, contradictory, or unexplained terms require clarification. Do not infer a fee, final amount, processing time, or fixed rate that is not explicitly displayed. |
| Verification and compliance requirements | Review the requirements presented for the specific direction and confirm unclear points through an official support channel reached independently. | Requirements may depend on the transaction route and compliance results. If you cannot or do not intend to satisfy them, do not create or fund the order. Do not attempt to bypass applicable checks or restrictions. |
| Source of every instruction | Distinguish information shown inside the authenticated order from instructions received in a messenger, email, comment, pop-up, or unsolicited support conversation. | A request to use a different address or send an additional payment outside the order is a stop signal until independently verified. |
Pass 2: verify the final transaction fields
| What to verify | Independent confirmation | What a mismatch means |
|---|---|---|
| Recipient address | Compare the full address in the order with the full address on the wallet’s final confirmation screen. If using a hardware wallet, trust the device display rather than the computer clipboard alone. | Any different character or unexplained replacement means you must cancel the transfer. Ethereum guidance recommends checking that the destination address exactly matches the intended recipient because an incorrectly sent transaction is generally irreversible. [2] |
| Memo, Tag, payment ID, or similar field | Check whether the order explicitly requires an additional identifier and compare it character by character with the final transaction screen. | A missing or incorrect identifier may prevent automatic crediting. Do not invent one or reuse a value from an older order. |
| Asset and network | Repeat the comparison even if it was completed in Pass 1. Verify the asset and selected withdrawal network in the wallet or sending platform against the active order. | A network changed by default selection, wallet update, or user error requires cancellation and correction before sending. |
| Amount sent | Compare the requested deposit amount with the actual transfer amount and account for how the sending platform displays its network fee. | If a fee is deducted from the amount rather than added separately, the recipient may receive less than required. Pause and clarify the wallet’s fee treatment. |
| Expected amount received | Recheck the latest order summary, including any stated conditions under which the estimate or final amount may change. | An unexplained difference from Pass 1 means the order should not be treated as unchanged. Obtain clarification or create a new order if instructed through a verified channel. |
| Order status and validity | Confirm that the order is still active and accepting payment before broadcasting the transaction. | An expired, cancelled, or already completed order should not receive another transfer. |
| Final signing prompt | Read the transaction data shown by the wallet. Confirm that you are authorizing a normal transfer to the intended address rather than an unrelated contract approval or unexpected signature request. | Additional permissions, unlimited token approvals, or fields not explained by the exchange flow require cancellation. Ethereum guidance recommends reading transaction messages before signing and limiting contract permissions when contracts are involved. [2] |
After completing both passes, a possible next step is to check the current exchange conditions and supported direction. Treat the live order details as operation-specific information and repeat the second pass if any field changes.
Classify the result without assuming safety
| Outcome | When it applies | Action |
|---|---|---|
| Continue verification | The domain, exchange direction, asset, network, address, amount, identifiers, and displayed conditions agree across the relevant sources. | Proceed only to the next verification stage. This classification is not a guarantee that the service or transaction is risk-free. |
| Clarification required | A condition is incomplete, the payout has changed under a stated rule, the compliance process is unclear, or the sending platform handles fees in an unexpected way. | Pause. Contact support through a channel obtained independently and preserve non-secret order details needed to explain the issue. |
| Stop | The domain is suspicious; the network or address differs; secrets are requested; the order is expired; instructions arrive from an unverified person; or guaranteed profit is promised. | Do not sign, broadcast, or send an additional payment. Secure the wallet or account if sensitive information may have been exposed. |
Control route before, during, and after the exchange
- Before sending: complete both verification passes, confirm the active order status, and capture only the non-secret information needed to identify the operation.
- Immediately after sending: record the transaction ID, or txid, from the wallet and check it in an explorer designed for the selected blockchain. A txid from one network should not be searched in an unrelated network’s explorer.
- While waiting: distinguish between “broadcast,” “pending,” “confirmed on-chain,” and “credited by the exchange.” A transaction may exist in a network mempool or block before the recipient’s system credits it. Ethereum transactions move through broadcast, block inclusion, and later finality stages; Bitcoin transactions also gain confidence through confirmations rather than becoming final merely because a wallet displays them. [4]
- After completion: compare the received asset and amount with the final order conditions. Do not use a wallet notification alone as proof; confirm the balance and transaction record through the receiving wallet and relevant explorer.
If the status is delayed, the amount differs, or data changes
A delay does not by itself identify the cause. Avoid sending a second payment until you have determined what happened to the first one.
- Check whether the transaction was broadcast. Search the correct blockchain explorer using the txid. If it is absent, confirm whether the wallet actually broadcast it.
- Check its network state. Determine whether it is pending, failed, replaced, confirmed, or finalized where the network and explorer expose those states.
- Compare the recipient address and network. Use the on-chain transaction record, not the clipboard or a newly loaded order page.
- Reconcile the amount. Compare the amount received on-chain with the order requirement and determine whether the sending service deducted its withdrawal or network fee from the entered amount.
- Check the additional identifier. If a Memo, Tag, or payment ID was required, verify whether it was included and correct.
- Preserve the original terms. Keep the order identifier, timestamps, asset, network, displayed calculation, status messages, txid, and non-sensitive screenshots. Do not alter images or omit relevant fields when contacting support.
- Use a verified support route. Describe the discrepancy without disclosing a seed phrase, private key, password, authentication code, or unnecessary personal data. No diagnostic step guarantees crediting or recovery after an incorrect transfer.
Threats directly relevant to an exchange operation
Phishing and cloned exchange pages
A copied interface may display convincing branding while changing the deposit address or collecting credentials. Type or open the verified domain independently, inspect redirects, and avoid acting on urgency created by unsolicited “support.”
Clipboard and address substitution
Malware or a malicious page can replace a copied crypto address. Comparing only the first and last few characters is a useful quick screen, but it is not equivalent to checking the entire address. The definitive comparison should happen on the final signing screen, preferably on a separate trusted device display when available.
Wrong-network transfers
The same asset label may be available across several networks, but the exchange may support only specific deposit routes. Network compatibility must be explicit on both sides. Do not assume that a visually similar address proves compatibility or that support can recover an unsupported transfer.
Seed phrase exposure
An exchange does not need a wallet’s recovery phrase to receive a transfer. If it has been entered into a website, message, form, or remote-support tool, consider the wallet compromised and seek wallet-specific security guidance from a trusted source. Never send the phrase to someone offering recovery assistance. [2]
Guaranteed-profit claims
Swapping one asset for another does not guarantee an investment result. BTC, ETH, USDT, and other crypto assets carry different market, issuer, protocol, custody, and operational risks. A promise that an exchange will certainly generate profit or return more crypto than you send is a reason to stop, not a feature of the transaction. [3]
Minimal recordkeeping protocol
Retain enough non-secret information to reconstruct the operation: the order identifier, creation time, exchange direction, asset, network, deposit address, required Memo or Tag if applicable, displayed terms, status history, txid, and relevant non-sensitive screenshots. Blockchain transaction records can be public and persistent, so store this material with appropriate privacy controls. [5]
Do not store seed phrases, private keys, passwords, one-time authentication codes, full identity documents, or unrelated personal information with the transaction record. The final decision should rest on consistency: if the active order, independent network data, and wallet signing screen do not describe the same operation, stop before funds leave your control.