Before creating an exchange order, connecting a wallet, or approving a crypto transfer, pause long enough to verify the operation twice. The first pass establishes that the service, asset, network, and terms make sense. The second repeats the critical checks immediately before the irreversible action. This process can expose common phishing tactics and input errors, but it cannot eliminate every technical, counterparty, compliance, or market risk.

Express check: stop signals that require attention now

Do not proceed merely because a page looks polished or a wallet displays a familiar logo. Treat any of the following as a reason to close the page or suspend the operation:

• A request for a seed phrase, private key, or wallet backup. Anyone who obtains a recovery phrase may be able to control the associated wallet. A legitimate transfer does not require disclosing it to an exchange form, “support agent,” verification bot, or website. ^[1]
• A domain reached through an unsolicited message, advertisement, search result, or support reply. Phishing pages often imitate real services. Open the service through a previously verified bookmark or independently typed address instead of trusting the supplied link.
• An address that changes after being pasted. Clipboard malware can replace a copied recipient address with an attacker’s address. Stop using the device for crypto activity until it has been checked for malware. ^[2]
• A deposit address copied from transaction history. Address-poisoning attacks place look-alike addresses in wallet histories, sometimes matching only the visible beginning and ending characters. Obtain a fresh address from the intended recipient or verified order page. ^[3]
• Pressure to act immediately. A countdown, threat of account closure, unexpected compliance warning, or claim that funds must be moved to a “safe wallet” is not a reason to bypass verification.
• A promise of guaranteed returns, risk-free profit, or multiplication of deposited crypto. Cryptocurrency returns cannot be guaranteed; such promises are a recognized scam signal. ^[4]
• A network, asset, or exchange direction that is not shown in the verified service interface. Similar ticker symbols do not prove network compatibility.
• An unexpected request for additional payment. Do not send a second transfer merely because a message claims that a tax, unlock fee, insurance payment, or recovery deposit is required.

If none of these stop signals appears, continue with the full card. Their absence is not proof that the operation is safe.

Two-pass pre-operation verification card

Pass one: verify the operation’s context

Complete this pass before transferring funds to a deposit address or approving a wallet request.

Context and service verification

What to verify	Independent confirmation	What a mismatch means
Service domain Check the complete hostname, spelling, domain ending, and browser security warnings. Look for extra words, substituted characters, unexpected subdomains, and redirects.	Compare it with a bookmark created during a previously verified visit or with the address published through a known official channel. Do not use the link from the message that prompted the transaction as its own confirmation.	A spelling difference, unrelated redirect, certificate warning, or domain reached only through an unsolicited message is a stop condition.
Exchange direction Confirm which asset you are sending and which asset you expect to receive. Read the direction from left to right rather than relying on icons.	Compare the order page with your original intention and with the withdrawal screen of the sending wallet or platform.	Reversed assets or an unexpected payment method mean the order is not the one you intended. Recreate it only through the verified service interface.
Asset availability Confirm that the selected asset is currently offered for the intended operation.	Use the live order interface. The exchange supports assets including USDT, BTC, ETH, DAI, LTC, BNB, XMR, and TRX, but that list does not establish that every pair, network, or direction is available at a given moment.	If an asset or direction appears only in an advertisement, message, or third-party page, clarify availability before creating an order.
Payment method claims Check whether the page describes a currently available method rather than a proposed feature.	Use the verified service interface and its current conditions. Ruble exchange from a bank card to cryptocurrency and back is planned, not an active function with a stated launch date.	A page claiming that this planned card feature is already operational may be outdated, inaccurate, or fraudulent. Stop and verify the domain.
Blockchain network Identify the exact sending and receiving network. Do not infer it from the asset ticker alone.	Compare the network named on the order with the withdrawal network in the sending platform and the deposit instructions from the recipient. Both sides must explicitly support the same network.	A network mismatch creates a material risk of non-crediting or loss. Some services cannot recover assets sent over an unsupported network. [5]
Address source Establish where the recipient or deposit address came from.	Obtain it directly from the verified order page or intended recipient. Do not rely on wallet history, comments, screenshots, public chat messages, or an address sent by an unsolicited “support” account.	An address from an unverified channel must be treated as untrusted, even if its first and last characters look familiar.
Memo, Tag, or payment identifier requirement Determine whether the receiving platform requires an additional routing value.	Read the deposit instructions generated for the specific asset and account. Requirements are set by the receiving platform and may differ between custodial accounts and self-custody wallets.	A missing or incorrect Memo or Tag can prevent automatic crediting, delay the deposit, or lead to loss. [6]
Displayed terms Read the amount to send, estimated or stated amount to receive, fees shown for the order, rate treatment, limits, and expiry conditions without assuming unstated values.	Compare the order summary with the amount and asset selected in your wallet. Preserve a non-sensitive record of the conditions displayed when the order is created.	An unexplained change, hidden field, different asset, or materially different result requires clarification before payment.
Verification and compliance conditions Check what information or review may be required for this direction.	Use the current conditions displayed before creating the order. Requirements can depend on the transaction direction and the outcome of compliance checks.	If the process differs from the published conditions, pause and contact support through the verified domain. Do not attempt to bypass identity, sanctions, geographic, or legal restrictions.
Information source Identify whether each instruction came from the order page, wallet, blockchain explorer, email, direct message, or third party.	Give priority to the verified service interface, official wallet documentation, and the relevant blockchain explorer. Verify unexpected communications through a separate channel.	If all instructions trace back to one unsolicited message, there is no independent confirmation. Stop until the operation can be reconstructed from trusted sources.

Pass two: repeat the critical fields immediately before sending

Run this pass after all data has been entered but before selecting Send, Confirm, Withdraw, Approve, or Sign. Do not approve the operation while distracted, screen-sharing with an unknown person, or following instructions from an unsolicited caller.

Final transaction verification

What to verify	Independent confirmation	What a mismatch means
Recipient address Compare the entire pasted address, including middle characters. Where a hardware wallet displays the destination, compare that display as well.	Match it against the fresh address shown on the verified order page or by the intended recipient. Avoid using a shortened wallet-history entry as the reference.	Any changed character is a stop condition. Delete the value, obtain the address again, and investigate possible clipboard compromise.
Selected network Read the final network label in the withdrawal or wallet confirmation screen.	Match it with the network stated in the receiving instructions. The fact that an address format is accepted by the interface does not prove that the receiving service supports that network.	If the labels do not match exactly, cancel the transfer. Do not send a test transaction across a known network mismatch.
Memo, Tag, or identifier Confirm whether it is required and compare every character.	Use only the value generated by the receiving platform for this deposit or order.	A blank, truncated, reformatted, or different value requires correction before sending.
Amount and asset Check the asset ticker, number of decimal places, amount to send, and wallet-displayed network fee.	Compare them with the order summary and your intended maximum outlay. Account for volatility where the quoted result is not fixed.	A different asset, misplaced decimal point, or unplanned fee means the transaction should be cancelled and reviewed.
Expected result Recheck the amount or calculation currently displayed as receivable and any conditions attached to it.	Use the latest order summary, not a screenshot or quote from an earlier session.	If the result changed beyond what the order terms explain, request clarification or recreate the order. Do not assume an old quote remains valid.
Order status and validity Confirm that the order is active and that its deposit details have not been replaced.	Refresh only through the verified service interface. If refreshing changes the address or other critical value, verify the reason through official support before paying.	An expired order, unexplained address change, or conflicting instruction means stop.
Wallet request Read what the wallet is asking you to sign or approve. Distinguish a transfer from a token approval, contract interaction, login signature, or network switch.	Compare the wallet prompt with the action you initiated. If the interface does not explain the request in understandable terms, reject it.	An unrelated approval, unlimited spending request, different contract, or unexpected network switch may expose assets beyond the intended operation.
Test transfer decision For a new address or unfamiliar flow, consider whether a small test transfer is operationally possible and useful.	Confirm that the order permits split payments and that a test will not invalidate its terms. A test can confirm routing but cannot prove that later addresses, terms, or devices remain uncompromised.	If split payments are not permitted or the order may expire, do not improvise. Clarify the process first.

Classify the result without treating it as a guarantee

Decision outcomes

Outcome	When it applies	Next action
Continue checking	The domain and data sources are independently verified, the operation is supported, and both passes show matching critical fields.	You may proceed to the final wallet confirmation while remaining alert to last-second changes. This outcome does not certify the service or remove transaction risk.
Needs clarification	A condition is incomplete, availability is uncertain, compliance requirements are unclear, or a non-critical displayed value has changed with a plausible explanation.	Do not transfer funds yet. Contact support through the verified domain and retain the order identifier and non-sensitive evidence needed to describe the discrepancy.
Stop	The domain is suspicious, the address or network differs, a seed phrase is requested, pasted data changes, instructions conflict, or guaranteed profit is promised.	Close the page, reject the wallet request, preserve safe evidence, and secure the device or wallet as appropriate. Do not send an additional payment to “unlock” or recover funds.

After completing both passes, one possible next step is to check the currently available exchange conditions.

Control route before, during, and after the operation

Before sending

1. Open the service independently and verify its full domain.
2. Create or review the order only in that verified session.
3. Confirm the exchange direction, asset, network, address source, and Memo or Tag requirement.
4. Read the current terms and applicable verification conditions before committing funds.
5. Close unrelated messaging apps and do not accept remote-access or screen-sharing requests.
6. Complete the second pass against the wallet’s final confirmation screen.

While waiting

1. Keep the order page available, but do not follow replacement instructions received through unsolicited messages.
2. Use the txid in the correct blockchain explorer to distinguish an unbroadcast transaction from one that is pending or confirmed on-chain.
3. Compare the explorer’s destination address, transferred asset, amount, network, and confirmation state with the order record.
4. Check the service status through the verified session. Network confirmation and crediting by a receiving service are separate stages.
5. Do not send the transaction again merely because the balance has not updated. First determine whether the original transfer exists on-chain.

After confirmation

1. Verify that the credited asset and amount correspond to the completed order, allowing only for deductions or rate treatment that were disclosed in its terms.
2. Record the completion state, order identifier, and txid without storing wallet secrets.
3. Disconnect wallet access that is no longer needed and review token approvals if the operation involved a contract rather than a straightforward transfer.
4. If the interaction began through a suspicious page, review the wallet and device even if no immediate loss is visible.

Threats directly relevant to an exchange operation

Phishing and fake crypto services

A fake exchange may reproduce branding, order forms, support chat, and fabricated balances. Visual similarity is weak evidence: the domain, source of the visit, wallet request, and deposit details matter more. Never treat a padlock icon alone as proof of legitimacy, and do not let an unsolicited “support agent” define the verification process.

If a message reports an urgent account problem, open the service separately rather than selecting the embedded button. Legitimate-looking direct messages can impersonate businesses and direct users to fraudulent crypto payment flows. ^[4]

Address substitution

Address substitution may occur through clipboard malware, a compromised web page, a fake QR code, or address poisoning. Checking only the first and last few characters is insufficient against an address deliberately designed to look familiar. Compare the whole value when practical, especially the middle section, and confirm the destination shown by a hardware wallet before signing. ^[3]

Wrong network

An asset can exist on several networks while the receiving service supports only selected routes. Matching symbols or compatible-looking address formats do not establish deposit compatibility. Both the sender and recipient must identify the same network. Never select a cheaper network solely to reduce fees unless the receiving instructions explicitly support it.

Seed-phrase exposure

A seed phrase is not an account number, verification code, or support credential. Do not type it into an exchange page, cloud document, chat, or recovery form reached through a message. If it has been disclosed, assume the wallet may be compromised; stop using the affected wallet for new deposits and follow the wallet provider’s official compromise procedure from a clean device. Never share the phrase with anyone offering recovery assistance. ^[1]

Guaranteed-return claims

An exchange operation transfers one asset for another; it does not create guaranteed profit. Claims that a deposit will be doubled, automatically earn a fixed return, or unlock a risk-free trading program indicate a different and potentially fraudulent proposition. Volatility remains relevant even when the intended task is conversion rather than investment. Regulators specifically identify guaranteed crypto returns and pressure to act quickly as scam indicators. ^[4]

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

Do not respond to uncertainty by sending more crypto. Diagnose the stage of the operation first:

1. Check whether the transaction was broadcast. Obtain the txid from the sending wallet or platform. If no txid exists, the transfer may not have reached the blockchain.
2. Open the correct blockchain explorer. Confirm the network, status, destination, asset, amount, and confirmations. A txid from one network should not be searched as though it belonged to another.
3. Compare on-chain data with the order. If the blockchain destination differs from the verified deposit address, preserve the evidence and stop using the device until address substitution has been investigated.
4. Separate network delay from service crediting. A pending transaction has a different diagnosis from a confirmed transfer that has not yet been credited.
5. Review Memo or Tag data. If a required value was omitted or entered incorrectly, contact the receiving platform through its verified support channel and provide the txid and order identifier. Assistance may be possible in some circumstances, but recovery cannot be assumed. ^[6]
6. Investigate amount differences. Compare the transferred amount, network fee, order terms, rate treatment, and credited asset. Do not invent an explanation for an undisclosed deduction.
7. Treat changed deposit details as a new risk event. Do not pay an address that arrives by email or chat after the order was created. Verify any change within the authenticated service session and through official support.
8. Secure remaining assets if compromise is suspected. Reject outstanding requests, disconnect suspicious applications, review approvals, scan the device, and use the wallet provider’s official security guidance. Do not expose the seed phrase while seeking help.

Confirmed blockchain transfers are generally not reversible by a central administrator. For example, Ethereum transactions sent to the wrong wallet cannot be reversed by the network; a receiving service may sometimes investigate a deposit under its own procedures, but this is not a promise of recovery. ^[7]

Safe transaction record protocol

Keep only the information needed to reconstruct and discuss the operation without creating a new security or privacy risk:

• order identifier;
• txid or transaction hash;
• asset and blockchain network;
• public sending and receiving addresses, when necessary for support;
• Memo or Tag used, if it is not treated as sensitive by the relevant service;
• amount sent and displayed result;
• timestamps and transaction status;
• screenshots of the order terms, error message, or suspicious domain, with unrelated personal data redacted;
• a short description of where the domain and deposit details were obtained.

Never include a seed phrase, private key, wallet password, two-factor authentication code, card details, identity-document image, remote-access credential, or unnecessary personal correspondence in this record. Store the record according to its sensitivity and share it only through the verified support process. The practical objective is not to prove that an operation was risk-free, but to catch discrepancies before authorization and preserve enough non-secret evidence to diagnose a problem afterward.