Before sending cryptocurrency to an exchange, confirm that the asset, blockchain network, deposit address, and any required Memo or Tag describe the same operation. A transfer can appear technically valid while still going to an unsupported network or the wrong recipient. This check reduces avoidable errors, but it cannot eliminate every risk or guarantee that funds will be credited or recoverable.

Express check: stop signals before you proceed

Pause before creating or paying for an exchange request if any of these conditions applies:

• The exchange page was opened from an advertisement, unsolicited message, shortened link, or copied support reply rather than a verified bookmark or independently checked domain.
• The asset symbol matches, but the sending wallet and receiving service show different network names.
• The deposit address, QR code, Memo, or Tag changed after you created the request.
• The wallet displays an unfamiliar recipient after you paste the address.
• The requested asset or network is not explicitly available for the selected exchange direction.
• The amount to receive, fee information, or other material conditions changed and the interface does not clearly explain why.
• Someone claiming to be support asks for a seed phrase, private key, password, remote device access, or an additional transfer to “unlock” the first one.
• The operation is tied to a promise of guaranteed returns, risk-free profit, or automatic multiplication of funds. Such promises are recognized fraud indicators, not normal exchange conditions. ^[1]

If one of these signals appears, do not treat urgency, a countdown, or a favorable-looking rate as a reason to continue. Save the non-secret request details, close the page if its authenticity is uncertain, and restart verification through an independently located official channel.

Two-pass pre-transfer verification card

The first pass checks whether the operation has been set up correctly. The second pass repeats the fields that can cause an irreversible error immediately before approval. Each line answers three questions: what to compare, where to obtain independent confirmation, and what a mismatch means.

Pass one: verify the operation context

Context check before preparing the transfer

What to verify	Independent confirmation	Meaning of a mismatch
Website domain. Check the complete domain name, spelling, connection warnings, and whether unexpected redirects occurred.	Use a previously saved bookmark or find the official address through a separately verified service channel. Do not rely on the same message or advertisement that supplied the original link.	A different or misspelled domain may indicate phishing. Stop and do not connect a wallet, sign anything, or enter account information.
Exchange direction. Confirm which asset you are sending and which asset you expect to receive.	Compare the request summary with the balances and asset names shown in your own wallet. Check the service’s current list of available directions before creating the request.	Reversed assets or an unavailable direction means the request does not represent the intended exchange. Cancel or clarify it rather than improvising another transfer.
Exact cryptocurrency. Read the full asset name and ticker, not only a logo or color.	Compare the request with the official asset information in the sending wallet and, for a token, its official contract details where applicable.	A matching ticker alone does not prove that two tokens are the same. An incorrect asset may not be recognized or credited.
Selected network. The withdrawal network in the sending wallet must match the deposit network stated in the request.	Confirm the network separately in both interfaces and consult the project’s official documentation when a token exists on several blockchains. For example, USDt is issued on multiple networks, so “USDT” by itself does not identify the transfer route. [2]	Different network names are a stop condition. Similar address formats do not establish compatibility, and recovery after a wrong-network transfer may be impossible or dependent on the recipient’s technical control. [3]
Current availability. Verify that the selected asset, network, and direction are accepted now.	Use the live request form and current service conditions rather than an old screenshot, article, message, or previous transaction.	Past availability does not confirm present support. The exchanger works with assets including USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX and may add others, but that does not mean every pair or network is available. Ruble-to-crypto and crypto-to-ruble bank-card exchange is planned rather than an active function.
Conditions and verification requirements. Review the displayed amount, relevant fees, request validity conditions, and any checks required for this direction.	Read the current request summary and applicable service terms before sending. Requirements may depend on the exchange direction and the outcome of compliance checks.	Missing, unexplained, or materially changed conditions require clarification. Do not assume that requirements from an earlier request apply to a new one.
Source of the deposit details. Confirm that the address and any additional field were generated inside the verified request.	Compare the request page with the official account or request record opened independently. Treat addresses sent only through direct messages or informal support chats as unverified.	If the details come from an unconfirmed source, stop. A convincing message does not prove control of the destination.

Pass two: verify immediately before the irreversible action

Final comparison before pressing Send or Confirm

What to verify	Independent confirmation	Meaning of a mismatch
Recipient address. Compare the entire address shown by the wallet with the address in the active request. Do not check only the first and last few characters.	Return to the verified request page and compare it with the wallet’s final confirmation screen. If a QR code was used, still inspect the decoded address before approval.	Any changed character means the destination is different. Delete the pasted value, investigate possible clipboard replacement, and do not send until the source is trusted.
Network shown at confirmation. Check the network again after selecting the address and amount.	Compare the wallet’s final network label with the active request. Do not infer the network from the address format alone.	If the wallet switched networks or the labels differ, stop. Choosing another network because it appears cheaper or faster can make the deposit incompatible.
Memo, Tag, payment ID, or similar field. Determine whether the receiving service requires an additional identifier and copy it exactly when provided.	Use the active deposit instructions from the receiving service. Platforms may use a shared address and an additional identifier to assign a deposit to the correct account. [4]	A missing or incorrect required identifier can prevent automatic crediting, delay the deposit, or lead to loss. Do not invent a value or reuse one from an old request.
Amount and denomination. Confirm the digits, decimal position, asset unit, and whether the wallet will deduct a network fee separately or from the entered amount.	Compare the wallet’s final summary with the request’s required send amount and expected result.	A difference may cause an underpayment, overpayment, or an unintended balance transfer. Return to the amount entry screen instead of approving and correcting later.
Expected amount to receive. Review the latest displayed result and any clearly stated reason it may change.	Use the active request summary immediately before payment, not a search result, promotional message, or earlier calculation.	If the result changed beyond what you are prepared to accept, pause and clarify or create a new request. Do not assume a previous quote remains applicable.
Final wallet prompt. Read the recipient, network, asset, amount, fee, and action type presented for authorization.	Compare the prompt with the request rather than approving from habit. Ethereum guidance notes that transaction interfaces may summarize the intended recipient and amount before signing; those displayed values still need to be read. [5]	An unfamiliar approval, contract interaction, unlimited token permission, or different recipient is not the intended simple transfer. Reject the prompt and investigate.
Request state. Make sure the request has not expired, been cancelled, or been replaced while you were preparing the transfer.	Refresh or reopen the verified request record as permitted by the interface and check its current status before authorization.	If the state or payment details changed, do not use saved data from the earlier version. Obtain current instructions first.

After both passes are complete, one possible next step is to check the current exchange conditions for the intended asset and network. Completion of the card means only that no identified mismatch remains; it is not a guarantee against technical failure, fraud, compliance review, market movement, or user error.

How to classify the result

Continue the verification

You may continue toward the final wallet review when the domain was independently verified, the exchange direction is available, the asset and network match in both interfaces, the address is unchanged, required additional fields are present, and the displayed conditions remain acceptable. Keep checking until the wallet actually requests authorization.

Clarification required

Pause when a field is ambiguous rather than clearly wrong: the network uses unfamiliar naming, a Memo requirement is unclear, the expected amount changed, compliance requirements are not understood, or the request status is uncertain. Ask through an official channel without sending secret credentials. Continue only after the active request itself shows consistent information.

Stop

Stop when the domain is suspicious, the asset or network differs, the address changes, a required identifier is missing, the request is no longer active, or anyone asks for a seed phrase or private key. Also stop if you are pressured to send another payment for guaranteed recovery or profit. A seed phrase or private key gives control over wallet assets and must not be shared with support or entered into an exchange request. ^[6]

Control route before, during, and after the operation

1. Before the transfer: verify the domain independently, create a current request, complete pass one, and confirm that the sending wallet holds the correct asset on the required network. Avoid switching between several copied addresses or old request tabs.
2. At authorization: complete pass two using the wallet’s final confirmation screen. If the interface supports a small test transfer and the request conditions allow it, consider whether that is appropriate before sending the remaining amount. A test can reveal some address or Memo errors, but it does not prove that a later transfer is risk-free.
3. While waiting: keep the request page or request identifier available, but do not repeatedly send the same payment. Find the transaction ID in the sending wallet and check it in the correct network’s recognized blockchain explorer.
4. After network confirmation: compare the explorer record with the request: network, txid, destination, transferred asset, amount, and confirmation state. A successful on-chain transaction shows what the network processed; it does not by itself prove that an unsupported deposit will be credited.
5. After crediting: verify the received asset and amount in the completed request record. Do not rely only on a notification email or message.

If the status is delayed, the amount differs, or details changed

Start diagnosis without creating a second payment:

• Check whether the wallet produced a txid. If no txid exists, the transaction may not have been broadcast, but the wallet’s status and official support documentation should be checked before trying again.
• Open the txid in an explorer for the network actually used. Confirm whether the transaction is pending, failed, replaced, or confirmed.
• Compare the on-chain destination and amount with the active request. For tokens, also check the token contract recorded by the explorer rather than relying only on the ticker.
• Confirm whether a required Memo, Tag, or payment identifier was included. If it was omitted or incorrect, contact the receiving service through its official channel and provide the request identifier and txid. Assistance may be possible in some cases, but recovery must not be assumed. ^[4]
• If the transaction is confirmed but the balance is not displayed, verify that the wallet or platform is viewing the correct network and token. Some wallets may require a supported token to be displayed manually; do not import an unverified contract supplied by a stranger. ^[3]
• If the request amount or destination changed before payment, do not send to either version until the official request record is clarified. If it changed after payment, preserve both versions and report the discrepancy through official support.

Never give a recovery helper your seed phrase, private key, password, or remote access. Do not pay an unsolicited person who claims that a second transfer will reverse the first. Blockchain transfers to an incorrect address or incompatible destination may have no practical recovery path.

Threats directly related to a wrong asset or network transfer

Phishing and address replacement

A fake exchange page can reproduce asset names and request screens while replacing the recipient address. Clipboard malware can also substitute another address after copying. Independently verify the domain, compare the complete address on the final wallet screen, and reject any last-minute change.

Wrong network

Some assets exist on more than one blockchain, but versions on different networks are not interchangeable merely because they share a name. The sending and receiving sides must explicitly support the same network. Do not choose a network based only on its fee or speed.

Seed-phrase theft disguised as support

A legitimate transfer check needs public transaction information such as a txid, not the secret that controls the wallet. Anyone with the seed phrase or private key may be able to move the wallet’s assets. If a phrase has already been exposed, stop interacting with the requester and follow the wallet provider’s official compromise procedure from a trusted device.

Guaranteed-return pressure

An exchange instruction attached to guaranteed income, doubled funds, or “risk-free” profit should be treated as a fraud warning. The FTC states that guaranteed crypto returns are a common scam signal. ^[1] Do not let an investment claim override address and network verification.

Safe operation record

Keep only the information needed to identify and diagnose the operation:

• the exchange request identifier;
• the selected asset and network;
• the creation and payment times shown by the service or wallet;
• the txid and public confirmation status;
• the displayed send amount and expected receive amount;
• non-sensitive screenshots of the request status or error message, with unnecessary personal information removed;
• official support case numbers and the dates of communication.

Do not store seed phrases, private keys, wallet passwords, authentication backup codes, identity documents, or unrelated personal data in the same record. Public transaction details help trace what happened; wallet secrets are never required to prove that a transfer occurred.