What to Check Before Exchanging BTC, ETH, USDT, LTC, BNB, TRX, or XMR

What to Check Before Exchanging BTC, ETH, USDT, LTC, BNB, TRX, or XMR

A cryptocurrency exchange should be checked twice: once while preparing the request and again immediately before sending funds or approving a withdrawal. The first pass establishes whether the operation itself is coherent. The second catches fields that may have changed, been copied incorrectly, or been replaced since the request was created. This process reduces avoidable errors, but it cannot eliminate volatility, counterparty risk, network disruption, compliance delays, or every form of fraud.

Express check: stop signals before you proceed

Pause before creating or funding a request if any of the following conditions applies:

• The website domain differs from the address you intended to visit, the connection produces a certificate warning, or the page was opened through an unexpected message or advertisement.
• The sending wallet, receiving service, and exchange request do not name the same asset and network.
• The destination address changed after you copied it, or only its first and last characters were compared. Malware and address-poisoning attacks can exploit superficial comparisons, so the complete address should be verified through a trusted display. ^[1]
• A required Memo, Tag, payment identifier, or similar field is missing or differs between the request and the wallet.
• The displayed amount, fee, rate, limit, or estimated amount to receive is unclear or has changed without an explanation.
• Someone asks for a seed phrase, private key, wallet password, or remote access to the device. These secrets are not needed to identify an ordinary blockchain transaction.
• The operation is linked to a promise of guaranteed returns, risk-free income, or automatic multiplication of funds. Regulators identify guaranteed cryptocurrency profits and similar claims as characteristic scam signals. ^[2]

If one of these signals appears, do not rely on urgency, screenshots, chat messages, or a familiar logo as confirmation. Return to independently obtained information and rebuild the verification chain.

Two-pass Pre-Operation Verification Card

For every item below, compare the exchange request with a source that did not originate from the same message, browser tab, or copied text. Independent confirmation is useful because one compromised source can reproduce the same incorrect information in several places.

Pass 1: verify the operation context

What to verify	Independent confirmation	What a discrepancy means
Domain and session origin	Open the service from a trusted bookmark or manually verified domain record rather than a link received in email, social media, search advertising, or private messages.	A different spelling, added word, unusual subdomain, redirect, or certificate warning is a reason to stop. It may indicate phishing rather than a harmless design variation.
Exchange direction	Read both sides of the request: the asset you send and the asset you expect to receive. Compare them with the balances and withdrawal screen in your wallet or source platform.	Reversed assets or an unintended direction means the request does not represent the planned operation. Do not try to compensate by changing only the amount.
Asset availability	Confirm the selected direction on the current request interface before transferring anything. The service works with USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX and may add assets gradually, but this does not imply that every pair, network, or direction is available.	If an asset appears in a general list but not in the intended exchange direction, the operation needs clarification. A ruble bank-card exchange to or from cryptocurrency is planned and should not be treated as an active option.
Network on both sides	Compare the exact network stated by the exchange request with the network selected in the sending wallet and supported by the receiving wallet. For tokens such as USDT, the ticker alone is insufficient because tokens can exist through different blockchain transaction systems. [3]	Matching address formats do not prove network compatibility. Ethereum-compatible accounts can exist across independent networks while balances and transaction histories remain separate. [4] If the network names differ or one side does not identify the network clearly, do not send.
Memo, Tag, payment ID, or other identifier	Use the identifier shown specifically for the current request and compare it with the destination platform’s deposit instructions. Treat the field as required whenever either interface marks it as required.	A missing or different identifier may prevent automated attribution even if funds reach an address. Do not reuse an identifier from an older request. For XMR, follow the current address and payment instructions exactly; Monero integrated addresses can embed compact payment identifiers. [5]
Rate, fees, limits, and amount to receive	Read the values displayed for the current request and compare the send amount, service deductions, network costs where shown, and estimated or fixed output under the stated conditions.	An unexplained change may result from rate movement, request expiration, a different amount, or revised conditions. It requires clarification rather than an assumption that the earlier calculation still applies.
Compliance requirements	Review the requirements displayed for the chosen exchange direction before creating the request. Conditions may depend on the operation and the outcome of compliance checks.	If required information, permitted sources of funds, or verification steps are unclear, clarification is needed before payment. Do not use instructions that claim to bypass KYC, sanctions, territorial restrictions, or applicable law.
Source of every critical value	Identify where the address, network, amount, identifier, and request terms came from. Prefer values generated inside the active request and confirm them against the destination wallet or platform.	If a critical field exists only in a chat message, screenshot, forwarded email, or third-party note, its authenticity has not been established.

Pass 2: repeat critical checks immediately before the irreversible action

What to verify again	Independent confirmation	What a discrepancy means
Full destination address	Compare the entire address shown by the sending wallet with the address in the active request. When possible, use a trusted hardware-wallet display or a second uncompromised device.	Any changed character means stop. Do not approve an address merely because its beginning and ending look familiar.
Selected asset and network	Read the final confirmation screen rather than relying on the earlier selection. Confirm both the asset ticker and the full network name.	If either differs from Pass 1, cancel the action and determine why. Sending through an unsupported network can leave the receiving system unable to credit the transfer.
Memo, Tag, or equivalent field	Compare the final wallet field character by character with the current request. Check whether the wallet removed spaces, truncated data, or left the field blank.	A mismatch requires cancellation before broadcast. The correct address does not neutralize an incorrect required identifier.
Amount being sent	Check the asset unit, decimal position, network fee, and actual amount leaving the wallet. Compare these with the request’s accepted amount or range, if displayed.	A misplaced decimal, changed fee treatment, or different asset unit can alter the result. Recalculate instead of editing under time pressure.
Expected amount to receive	Reopen or refresh the active request as instructed and read whether the output is estimated, fixed for stated conditions, or subject to recalculation.	If the result no longer matches the value you accepted, continue only after understanding the applicable terms. Cryptocurrency values can change, and no checklist can guarantee a particular market outcome.
Request status and validity	Confirm that the request is still active and that its deposit details have not expired or been replaced.	Do not send to an address from an expired, cancelled, completed, or superseded request without explicit confirmation in the current interface.
Final authorization screen	Read the wallet’s own confirmation display after pasting or scanning all details. Treat this screen as a new data source, not a routine button to dismiss.	If it shows an unexpected contract interaction, recipient, network, permission, or amount, reject the transaction.

After completing both passes, one practical next step is to check the current exchange direction and its conditions. Availability and requirements should be confirmed for the specific operation rather than inferred from a general asset list.

How to classify the result

Continue the verification

This outcome applies when the domain was independently opened, the direction is available, the asset and network match on every interface, all required identifiers agree, and the current terms are understandable. It means the internal checks are consistent; it is not a guarantee against market movement, service disruption, or later compliance review.

Clarification required

Use this category when information is incomplete rather than demonstrably false: the network label is ambiguous, a requirement is not explained, the output changed, the request status is uncertain, or the destination platform does not clearly state whether a Memo or Tag is required. Do not fund the request until the uncertainty has been resolved through the official interface or authenticated support channel.

Stop

Stop when the domain is suspicious, a secret phrase or private key is requested, the address changes unexpectedly, the networks differ, the request has expired, or someone links the exchange to guaranteed profit. Confirmed Bitcoin and Monero transfers are explicitly described in their project documentation as irreversible; recovery generally depends on the recipient’s cooperation rather than a network-level undo function. ^[6]

Control route before, during, and after the exchange

1. Before sending: complete both passes, close unrelated messaging windows, verify the destination on a trusted display, and make sure no seed phrase, key, or unnecessary personal information has been requested.
2. Immediately after broadcast: record the request identifier and txid from the wallet or source platform. A txid identifies the blockchain transaction and is the main reference for checking whether it was broadcast and confirmed. Monero also uses a transaction ID, although its private blockchain design does not publicly expose the same payment details as transparent chains. ^[7]
3. While waiting: distinguish blockchain status from service status. A transaction may be absent, pending, confirmed, or confirmed but not yet credited. Check the txid in the appropriate official project explorer or wallet; for privacy-preserving XMR diagnostics, use the wallet’s transaction tools and avoid disclosing private view information unnecessarily. ^[8]
4. After completion: compare the received asset, network, and amount with the completed request. Keep the operational references described below, then remove temporary screenshots or copied addresses if they are no longer needed.

If the status is delayed, the amount differs, or the data changes

If no txid exists, the wallet or source platform may not have broadcast the transaction. Check its local history and status before attempting another transfer; repeating the payment without diagnosis can create two valid transactions.

If a txid exists but has no confirmation, verify that it appears on the intended blockchain and compare its status with the sending wallet. Confirmation time is probabilistic rather than guaranteed, so a delay alone does not prove loss or fraud. ^[6]

If the blockchain shows confirmation but the request remains pending, verify the destination address, network, amount, and required Memo or Tag against the original request. Provide authenticated support with the request identifier and txid, plus a factual description of the discrepancy. Do not send a second payment unless the first transaction has been conclusively accounted for.

If the received amount differs, compare the completed request with the accepted rate conditions, network fee, service deductions, and actual amount sent. Record the values as displayed rather than estimating them from memory. A difference may require investigation, but it does not by itself identify the cause or guarantee reimbursement.

If the address or conditions changed before broadcast, cancel the action and recreate the verification chain. If they changed after broadcast, preserve the original request details and txid, then contact authenticated support. Never pay an additional “recovery” charge to an unsolicited person who claims to control or reverse the blockchain transaction.

Threats directly relevant to an exchange

• Phishing: a copied design can display a convincing request while substituting the domain and recipient address. Open the service independently and distrust urgency delivered through messages.
• Address replacement: malicious software can modify clipboard contents. Compare the complete address after pasting and again on the final signing device.
• Wrong network: the same ticker may be represented on more than one blockchain. Agreement on “USDT” or another asset name does not establish agreement on the transfer network.
• Seed-phrase exposure: a seed phrase or private spend key can grant control over a wallet. Never enter one into an exchange request, support chat, verification form, or transaction explorer. Bitcoin guidance states that legitimate support should not ask for a recovery phrase or private key. ^[9]
• Guaranteed-return claims: an exchange transfers one asset into another; it cannot make future profit certain. Treat claims of guaranteed gains, doubled funds, or risk-free cryptocurrency income as stop signals. ^[2]

Minimal recordkeeping protocol

Store only the information needed to reconstruct the operation: the request identifier, creation time, exchange direction, asset and network, displayed send and receive amounts, status history, txid, and relevant non-secret support correspondence. Keep records in a location protected against unauthorized access.

Do not include a seed phrase, private key, wallet password, authentication code, full identity document, or unrelated personal data in an operational note. For XMR, do not routinely attach a private view key or transaction secret key: Monero documentation explains that such information can reveal transaction details that are not public on the blockchain. ^[8] Preserve the minimum evidence necessary to identify the request and transaction without creating a second security problem.