A pre-transaction check cannot prove that a crypto exchange service is completely safe. It can, however, catch common and costly problems before funds are sent: a phishing domain, an unsupported network, a replaced address, unclear exchange conditions, or a request for wallet secrets. Use the following card as a decision aid rather than a guarantee. If a critical detail cannot be independently confirmed, pause instead of guessing.
Express check: stop signals to review first
Do not create, pay, or confirm an order until these immediate warning signs have been ruled out:
- The domain came from an unsolicited message, advertisement, group chat, or support account. Open the service through a previously verified bookmark or another trusted source instead of following the message.
- The site or a supposed support agent asks for a seed phrase, private key, wallet password, or remote access to your device. Stop. A seed phrase or private key controls the wallet and must never be disclosed. Ethereum’s security guidance explicitly warns users not to share recovery phrases or private keys. [1]
- The offered asset or network does not exactly match the sending and receiving wallets. Similar asset names and identical-looking address formats do not prove network compatibility.
- The deposit address changed after you copied it. Compare the complete address with the one shown in the active order. Do not rely only on its first and last characters.
- The amount, fee, rate, or expected payout changed without a clear explanation. Do not assume that an earlier screenshot, message, or calculator result still applies.
- You are promised guaranteed returns, risk-free profit, or multiplication of the crypto you send. These are scam indicators, not exchange terms. The U.S. Federal Trade Commission warns that guaranteed crypto profits and large assured returns are characteristic of fraud. [2]
- You are being rushed or told that checking details will cancel a unique opportunity. A deadline displayed by an order may be operationally relevant, but pressure from a stranger or unofficial support account is a reason to stop.
If any seed phrase, private key, or wallet password has already been disclosed, do not continue using the affected wallet as if it were secure. Use the wallet provider’s official security instructions from a clean device and avoid anyone who offers guaranteed recovery for an advance payment.
Two-pass pre-transaction verification card
The first pass checks whether the proposed exchange makes sense. The second pass repeats the fields that can cause an irreversible loss immediately before the wallet transaction, bank payment, or final confirmation. Complete both passes even when the order looks familiar.
Pass one: validate the operation and its source
| What to verify | Independent confirmation | What a discrepancy means |
|---|---|---|
| Domain and page origin Check the full domain spelling, not only the logo or page design. Confirm that redirects do not lead to an unrelated domain. |
Compare it with a previously verified bookmark, account record, or official communication obtained independently of the message that brought you to the page. Treat search advertisements and links in direct messages as unverified starting points. | A misspelling, extra word, unusual subdomain, or unexplained redirect is a stop signal. Do not log in, connect a wallet, or enter personal information. |
| Exchange direction Confirm which asset you are sending and which asset you expect to receive. |
Compare the active order page with your sending wallet balance and the destination wallet’s supported assets. Read the direction from left to right rather than relying on asset icons. | If the assets are reversed or one wallet cannot receive the selected asset, do not create or fund the order. |
| Asset availability Confirm that the specific exchange direction is currently offered. |
Use the live order interface rather than an old article, cached page, screenshot, or third-party listing. The service supports assets including USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX, but this does not mean that every pair, network, or direction is available at all times. | If the required option is absent, do not substitute a similarly named asset or assume that support will be added during processing. The service’s planned card-to-crypto and crypto-to-card exchange involving Russian rubles should not be treated as an active function. |
| Blockchain network Verify the exact network on both sides of the transfer, especially for assets issued on more than one blockchain. |
Compare the order’s network label with the withdrawal network in the sending platform and the deposit network supported by the receiving wallet. If terminology differs, consult the wallet or blockchain project’s official documentation before proceeding. | Any unresolved network mismatch means stop. An address that passes a wallet’s format check is not, by itself, proof that the receiving service supports that network. |
| Memo, Tag, payment ID, or similar field Determine whether an additional identifier is required alongside the address. |
Check the active deposit instructions and the destination platform’s official deposit screen. Confirm whether the field is mandatory, optional, or not used for this asset and destination. | A missing or different identifier can prevent automatic crediting. Do not invent a value, reuse one from an old order, or omit a required field. |
| Rate type and calculation basis Identify whether the displayed amount is fixed, estimated, or subject to recalculation. |
Read the current order conditions and compare the send amount, stated deductions, and expected receive amount within the same active session. | If the calculation cannot be reproduced from the displayed fields, or if different pages show conflicting figures, clarification is required before payment. |
| Fees and deductions Distinguish the service’s quoted result from wallet withdrawal fees, blockchain fees, and any other displayed deductions. |
Review the order summary and the final withdrawal screen in the sending wallet or platform. Use only figures shown for the actual transaction; do not rely on generic fee estimates. | An unexplained deduction or a payout below the amount you are prepared to accept means pause. Volatility and network costs can affect the practical result, depending on the stated exchange conditions. |
| Limits and payment window Check whether the amount is within the currently displayed range and whether the order has an expiry condition. |
Use the active order page. Confirm the amount again after entering it because limits and operational conditions may depend on the exchange direction. | Do not split, increase, or resend a payment merely to satisfy instructions received through an unofficial channel. If the window expires, obtain fresh order details rather than paying an old address automatically. |
| Verification and compliance conditions Check what information may be requested for the selected direction. |
Read the current conditions before creating the order. Requirements can depend on the transaction direction and the outcome of compliance checks, so they should be confirmed for the specific operation. | If the requirements are unclear, inconsistent, or unacceptable to you, do not fund the order. Do not attempt to bypass identity checks, sanctions controls, geographic restrictions, or applicable law. |
| Source of every critical value Identify where the address, rate, amount, network, and instructions came from. |
Prefer values generated inside the active order. Cross-check technical details against the sending wallet, receiving wallet, official project documentation, and the appropriate blockchain explorer. | An address or instruction supplied only through a private message, call, screenshot, or pasted document is not sufficient confirmation. |
Pass two: repeat the irreversible fields immediately before sending
Perform this pass after the wallet or payment application has populated its final confirmation screen. If you edit the order, switch networks, refresh into a new order, or change devices, repeat the pass from the beginning.
| What to verify | Independent confirmation | What a discrepancy means |
|---|---|---|
| Complete destination address Compare the entire address shown by the wallet with the address in the active order. |
Use two views that are independent of the clipboard, such as the order page and the wallet’s final confirmation screen. Check the middle characters as well as both ends. Bitcoin safety guidance recommends verifying the full receiving address rather than only its first or last characters. [3] | One different character is enough to stop. Delete the pending transaction, check the device for clipboard-altering malware, and reopen the verified order source. |
| Network shown by the sender Confirm that the selected withdrawal or transfer network is the network specified by the order. |
Compare the network name on the final wallet screen with both the order and the destination wallet’s official deposit information. | If the names differ or compatibility remains uncertain, cancel the transfer. Do not use a network merely because it has a lower fee. |
| Memo or Tag Verify the exact value and confirm that it is attached to the transaction. |
Compare the order with the dedicated Memo, Tag, or payment ID field on the final sending screen. Do not place it in a general message field unless the official instructions explicitly require that. | A missing, shortened, or changed value requires correction before sending. An identifier from a previous transaction must not be reused unless the destination’s official instructions explicitly establish that it is permanent. |
| Asset and token identity Check the ticker, network, and, where relevant, the token contract rather than relying on the ticker alone. |
Use the wallet’s asset details, official project documentation, and a suitable blockchain explorer. Tokens can share similar names or symbols. | If the asset identity cannot be established, stop. Sending a different token with a familiar ticker does not satisfy the order. |
| Amount being sent Verify the number, decimal position, and asset denomination. |
Compare the wallet’s final send amount with the active order. Check whether the wallet deducts its network fee separately or from the entered amount. | A decimal error, fee deduction that reduces the required transfer, or amount outside the current order terms requires recalculation or clarification. |
| Expected amount to receive Review the final quoted result and its status as fixed or estimated. |
Use the latest order summary from the same session, not a preliminary calculator result. Compare it with the destination asset and address. | If the result changed beyond what the stated conditions explain, pause and obtain clarification. Do not assume the difference will be corrected later. |
| Destination wallet ownership and access Confirm that you control the receiving wallet or knowingly intend to pay the stated recipient. |
Open the receiving wallet independently and verify that it displays the same address or deposit details. If another person supplied the destination, verify the request through a separate communication channel. | An unfamiliar recipient, last-minute address replacement, or request to send funds for “safe keeping” is a stop signal. |
| Order identity and current status Confirm that the order number, direction, and payment status belong to this transaction. |
Compare the active order record with the details you safely recorded when it was created. | If the page shows another order, an expired status, or an unexplained reset, do not pay the displayed address until the status is clarified. |
| Final authorization screen Read what the wallet is actually asking you to approve. |
Review the recipient, asset, amount, network fee, and any contract interaction shown by the wallet. Ethereum security guidance recommends reading transaction messages before signing. [1] | Unexpected permissions, unlimited token approvals, unfamiliar contract calls, or fields that do not match a straightforward transfer require cancellation and investigation. |
After completing both passes, a practical next step is to check the current exchange conditions for your intended asset and network. Availability and verification requirements should be reviewed again before an order is created.
How to classify the result
The outcome describes what to do next; it does not certify the service or eliminate transaction risk.
| Outcome | When it applies | Next action |
|---|---|---|
| Continue checking | The domain source is consistent, the operation is available, all networks and identifiers match, and the final wallet screen reproduces the active order details. | Proceed only if you understand the remaining risks, including price movement, processing uncertainty, and blockchain finality. Complete the second pass at the moment of authorization. |
| Clarification required | A condition is incomplete rather than clearly fraudulent: for example, the fee basis is unclear, a verification requirement is not explained, or the estimated receive amount changed under stated variable-rate conditions. | Pause the transaction. Contact support through the verified service interface and refer only to the order identifier and non-secret transaction details. Resume only after the answer is consistent with the active order. |
| Stop | The domain differs, a seed phrase is requested, the network or address does not match, the order is expired, an unofficial agent replaces payment details, or the offer includes guaranteed profit. | Do not send funds or sign the transaction. Close the page, preserve non-sensitive evidence if fraud is suspected, and secure any account or wallet information that may have been exposed. |
Control route before, during, and after the exchange
Before sending
- Open the service through a source you have independently verified.
- Create only one active order for the intended operation to reduce the risk of mixing addresses or identifiers.
- Record the order identifier, selected assets, network, amount, and displayed conditions without recording wallet secrets.
- Complete pass one, prepare the transaction, and then complete pass two on the wallet’s final screen.
- If the wallet supports address whitelisting or a confirmation delay, consider using those controls according to the wallet provider’s official instructions.
While waiting
- Keep the order page available, but do not follow replacement instructions from an unsolicited message.
- If a transaction ID is available, view it on an explorer designed for the actual blockchain used. Confirm the transaction status, destination address, asset, and amount.
- Do not treat “broadcast,” “pending,” and “confirmed” as equivalent statuses. A service may wait for network confirmations or additional review before updating the order.
- Do not send a duplicate payment merely because the interface has not updated. First establish whether the original transaction was broadcast and whether it used the correct network.
- Respond to legitimate compliance requests only through the verified channel and provide no more information than is required under the applicable process.
After confirmation
- Check the receiving wallet or platform directly rather than relying solely on an email or chat notification.
- Match the received asset and network with the order. A transaction marked successful on one blockchain does not prove that a different destination system has credited it.
- Compare the received amount with the final applicable exchange conditions, accounting only for deductions that were disclosed or visible in the transaction records.
- Retain the order identifier and transaction ID until the transaction is fully reconciled. Avoid publishing them unnecessarily because blockchain records may expose addresses and transaction relationships.
Blockchain transfers may be difficult or impossible to reverse without the recipient’s cooperation. Bitcoin documentation, for example, states that confirmed payments cannot simply be reversed by the sender. [4] This is why a mismatch should be resolved before authorization rather than treated as a support issue to fix later.
If the status is delayed, the amount differs, or details change
A delay or discrepancy is not enough to diagnose the cause. Work through the evidence in a fixed order and avoid sending additional funds until the original transaction is understood.
- Freeze further action. Do not repeat the payment, replace the transaction, switch networks, or pay a supposed recovery fee based only on a message from support.
- Confirm whether a transaction was created. Check the sending wallet’s history. If there is no transaction ID, determine whether the wallet actually broadcast the transfer or merely created a local request.
- Use the correct blockchain explorer. Search using the transaction ID on an explorer appropriate to the selected network. Verify the status, sender, complete destination address, asset or token, amount, and any Memo or Tag information that the chain records.
- Separate network status from service status. A confirmed blockchain transaction can still be under review or awaiting credit by the recipient. Conversely, a service page cannot make an unconfirmed or failed on-chain transfer complete.
- Compare the timestamp and order window. Establish whether the payment was broadcast before the order expired and whether the order conditions describe what happens after expiry. Do not assume a late payment will receive the original quote.
- Check for an amount mismatch. Compare the amount received on-chain with the amount requested by the order. Review whether the sending platform deducted a withdrawal fee from the entered amount.
- Check the network and token identity again. Confirm that the transaction occurred on the network supported by the order and, for tokens, that the contract represents the intended asset.
- Contact verified support with a concise evidence set. Provide the order identifier, transaction ID, asset, network, observed status, and a description of the discrepancy. Never provide a seed phrase, private key, wallet password, authentication code, or remote device access.
- Treat changed instructions as a new risk. If the address, amount, or requested action changes after payment, ask for an explanation through the verified interface. Do not send a second “verification” payment.
No diagnostic step guarantees a refund or recovery. Be particularly cautious if an unknown person contacts you after a problem and promises to retrieve funds for an advance fee. The FTC warns that recovery scams specifically target people who have already lost money. [5]
Threats directly relevant to an exchange transaction
Phishing and fake support
A phishing page may reproduce the branding, order form, or login screen of a real service. Fake support accounts may also appear in search results, social networks, or replies to public complaints. The objective is often to obtain credentials, redirect a payment, or persuade the user to install remote-access software.
Do not use contact details from the suspicious message itself to verify that message. Open the verified service independently. Requests to “synchronize” a wallet by entering its seed phrase are fraudulent; legitimate transaction troubleshooting can use an order identifier and transaction ID without exposing wallet control credentials. The FTC describes phishing as the use of deceptive emails or messages to steal passwords, account details, and other sensitive information. [6]
Address substitution
Malicious software can replace a copied crypto address with an attacker’s address. A visual check of only four or six characters at each end may also miss address-poisoning tactics designed to create similar-looking entries in transaction history.
Compare the complete address after pasting it and again on the wallet’s authorization screen. If the address changes between views, cancel the transaction. Do not keep testing with real transfers while the device may be compromised.
Wrong network
Some assets can be transferred through several networks, while the receiving service may accept only a specific one. The same ticker does not establish compatibility, and a wallet may allow a technically valid transaction that the intended recipient cannot automatically credit.
Network selection must match in three places: the order, the sending wallet, and the receiving wallet or platform. If one side uses an abbreviation or network name you do not recognize, consult official documentation instead of inferring equivalence from the address format or fee.
Seed phrase exposure
A seed phrase is not an order confirmation code, compliance credential, refund key, or support diagnostic. Anyone who obtains it may be able to control the associated wallet. Never enter it into an exchange page, support form, shared screen, cloud document, or chat.
If it has been exposed, stop the exchange check and follow the wallet provider’s official compromise procedure from a trusted device. Do not disclose the phrase again to a person claiming they can secure or recover the wallet.
Guaranteed-return claims
A crypto exchanger facilitates a conversion; it cannot guarantee that an asset will rise in price or produce a profit. Messages claiming that a transfer will be doubled, automatically invested at a guaranteed return, or released after an additional “profit activation” payment should be treated as fraud indicators. Crypto prices can move rapidly, and no checklist removes volatility risk. The FTC advises that promises of guaranteed crypto profits or large risk-free payouts are scam signs. [2]
Minimal record to keep after the transaction
Store only what is useful for reconciliation or a support request:
- the order identifier;
- the transaction ID or txid;
- the selected asset and blockchain network;
- the send amount and the displayed expected receive amount;
- the destination address used for that order, where retaining it is appropriate;
- the order creation and transaction times;
- a copy or screenshot of the non-sensitive order conditions that applied;
- the final order status and the amount actually received.
Do not include seed phrases, private keys, wallet passwords, authentication codes, full identity documents, or unrelated personal information in this record. Keep transaction records private where possible: public blockchains can make addresses, amounts, and transaction relationships visible, even when a person’s name is not directly shown. [2]
The practical stopping rule is simple: if the verified domain, asset, network, complete address, required identifier, amount, or final authorization screen does not agree with the active order, do not approve the transaction. Resolve the discrepancy first, then repeat both passes using current information.