A first cryptocurrency exchange is best understood as two linked transfers: you send one asset to the service, and the service sends another asset to the destination you specified. The exchange interface coordinates the order, while the relevant blockchains independently record the incoming and outgoing transactions.
Main takeaways
- Check the asset, blockchain network and complete address as separate fields. A familiar-looking address alone does not prove that the selected network is correct.
- Read the order terms before sending: the displayed rate, calculation method, service charges, network costs, limits and compliance requirements may depend on the selected direction.
- Save the order reference, deposit address and transaction hash. Each answers a different question when you need to trace the exchange.
- A blockchain explorer can show whether a transaction exists and has been included in a block. It cannot by itself prove that the service has matched the deposit to your order or approved the exchange.
- Do not treat a submitted transfer as easily reversible. Confirmed Bitcoin payments generally require the recipient to issue a refund, while Ethereum transactions sent to the wrong wallet cannot normally be reversed. [1]
The minimum vocabulary you need
Asset and network
BTC, ETH and USDT are assets; a network is the blockchain used to move an asset. Native BTC is transferred on the Bitcoin network, and native ETH is transferred on Ethereum. USDT is different because Tether issues tokens through multiple supported blockchain protocols. The sender and receiver therefore need to agree on the exact USDT network, not merely on the ticker “USDT.” [2]
This distinction matters even when two networks display addresses in a similar format. In the broader Ethereum ecosystem, multiple chains can use visually compatible addresses, so an address by itself may not identify the intended chain. [3]
Deposit address and destination address
The deposit address is where you send the asset being exchanged. The destination address is where you expect to receive the new asset. They may belong to different networks and should be checked independently.
Copy addresses from the current order and receiving wallet rather than from an old transaction history. Address-poisoning attacks attempt to place a lookalike address in that history so that a user later copies it by mistake. Checking only the first and last few characters is not sufficient; compare the full address or use a trusted QR code while still reviewing the wallet’s confirmation screen. [4]
Transaction hash and confirmations
A transaction hash, also called a transaction ID or TXID, identifies a blockchain transaction. After an Ethereum transaction is signed and submitted, it is broadcast to the network, receives a hash, waits in a transaction pool and must be included in a validated block. [5]
A confirmation indicates that a transaction has been included in a block, with later blocks increasing confidence in the recorded result. Services can apply their own confirmation requirements according to the asset, network, amount, risk controls and current conditions. More Bitcoin confirmations generally make a chain rewrite less likely, but seeing a transaction in a wallet is not the same as knowing that the receiving service considers it sufficiently confirmed. [6]
Quote, service charge and network fee
An exchange order should show what you send and what you are expected to receive under its stated calculation rules. Review any displayed service charge separately from the blockchain network fee. On Bitcoin, the network fee is related to the transaction’s data size rather than simply to the value transferred. On Ethereum, transactions consume gas, which pays for network computation. [7]
Do not assume that a rate remains available indefinitely or that the amount shown at an early stage is necessarily the final credited amount. Follow the exact rate, fee and validity conditions displayed for the current order; no universal rate, limit or processing time applies to every direction.
Mechanism map: from order to verifiable receipt
Your action: Select the asset you will send and the asset you want to receive.
Service mechanism: The interface checks whether that direction is currently available and presents the applicable order conditions.
Network mechanism: Nothing has moved on-chain yet.
Observable result: You can see the selected assets, networks, calculation terms and any stated limits or requirements.
Verification: Confirm that the pair and both networks are explicitly listed for this order. Support for an asset does not automatically mean that every pair, network or direction is available.
Your action: Enter the destination address for the asset you want to receive.
Service mechanism: The application records the address and may perform a basic format check.
Network mechanism: No destination transaction exists yet.
Observable result: The order summary displays the address and selected receiving network.
Verification: Compare the entire address with the receiving wallet and confirm that the wallet supports the named asset on the named network. A format check cannot establish that you control the address or selected the correct chain.
Your action: Review the compliance instructions and create the order.
Service mechanism: The service generates an order reference and provides deposit instructions. Depending on the direction and compliance results, additional information or checks may be required.
Network mechanism: The deposit address exists, but creating the order does not itself transfer cryptocurrency.
Observable result: You receive a current deposit address, network label, order status and applicable conditions.
Verification: Save the order reference and recheck the deposit instructions before opening your wallet. Requirements can vary between operations and countries because virtual-asset providers may be subject to customer due diligence, record-keeping and transfer-information obligations. [8]
Your action: In your wallet, enter the deposit address, select the exact network and authorize the transfer.
Service mechanism: The service waits for a matching deposit.
Network mechanism: Your wallet signs the transaction and broadcasts it. If accepted by the network, it first appears as pending and is later included in a block.
Observable result: Your wallet provides a transaction hash. The blockchain explorer may show the sender, recipient, asset, amount and status.
Verification: Open the transaction through a reputable explorer for the selected network and compare its recipient with the order’s deposit address. Never disclose a private key or seed phrase to perform this check.
Your action: Wait without sending a duplicate payment unless support explicitly instructs you to do so.
Service mechanism: The service detects the deposit, waits for its required network status and applies relevant compliance controls.
Network mechanism: Additional blocks or finality updates increase confidence that the deposit will remain in the ledger.
Observable result: The order may progress from awaiting payment to detecting or processing the deposit. Exact labels vary by interface.
Verification: Distinguish between “visible on-chain” and “credited by the service.” If the explorer shows success but the order does not update, retain the hash and order reference for support.
Your action: Monitor the receiving wallet and order page.
Service mechanism: If the exchange is approved and completed, the service creates the outgoing transfer to your destination address.
Network mechanism: A second transaction is broadcast on the receiving asset’s selected blockchain.
Observable result: An outgoing transaction hash may appear, followed by a pending or confirmed balance in your receiving wallet.
Verification: Use the correct network explorer to check the outgoing hash, destination address, token identity and transaction status. For USDT, also confirm the network and token contract shown by the explorer rather than relying only on the ticker.
A realistic ETH-to-USDT scenario
Suppose a user holds native ETH in a self-custody wallet and wants to receive USDT in another wallet. Before creating an order, the user checks whether the ETH-to-USDT direction is currently available and which USDT networks the service offers for withdrawal. The service supports both assets, but that fact alone does not establish that every ETH/USDT route or USDT protocol is available at that moment.
The receiving wallet displays a USDT deposit address for one specific network. The user selects that same network in the exchange interface, pastes the address and compares it in full. The order then provides an ETH deposit address and explicitly identifies the required deposit network.
In the sending wallet, the user confirms that the asset is native ETH on the network named by the order. After authorization, the wallet produces an Ethereum transaction hash. The hash allows the user to verify that the deposit was broadcast, which address received it and whether a validator included it in a block. Ethereum transactions contain fields such as the sending address, receiving address, value, signature and fee parameters. [5]
The service may wait for its required network status and complete compliance checks before creating the USDT withdrawal. If it proceeds, the outgoing transaction must use the USDT network selected earlier. The user verifies the second transaction independently and checks that the destination address, network and token match the receiving wallet.
This scenario describes the mechanism, not a guaranteed completion time or outcome. Network congestion, order conditions, liquidity, wallet restrictions and compliance review can change what the user observes.
Where the model changes or stops applying
- Asset support is not route support. The service currently supports assets including BTC, ETH and USDT, but a specific pair, network or direction must be checked before every operation.
- Crypto-to-crypto and card-to-crypto are different workflows. Exchanging Russian rubles from a bank card into cryptocurrency, and the reverse direction, is planned rather than currently available. It should not be assumed to work as part of this process.
- Compliance is conditional. The information requested can depend on the direction, the transaction and the results of compliance screening. Check the current requirements before creating an order.
- Rules differ across countries. Access, identity checks, reporting obligations and tax treatment can depend on the user’s location. This guide does not determine whether a particular transaction is legally or tax-compliant for an individual.
- An explorer verifies network records, not every business decision. It cannot reveal why a service is reviewing an order, how its internal accounting matched a deposit or whether additional information will be requested.
- A completed exchange does not prove profitability. BTC and ETH can be volatile, and USDT should not be treated as eliminating all token, issuer, network, custody or counterparty risk. No exchange status predicts future market value.
Failure points and the signs you can observe
Wrong network or incompatible destination
Signs: The wallet warns that the address or network is unsupported; the order and wallet show different network names; or the transaction succeeds on one chain but never appears in the expected account on another.
Response: Stop before signing if any labels differ. If the transaction has already been sent, collect the hash, order reference and screenshots of the selected network, then contact the receiving service. Recovery may be impossible or may depend entirely on whether the recipient controls the relevant address on that chain.
Wrong or substituted address
Signs: The address changes after pasting, differs from the current order, or merely resembles a recent address in the wallet history.
Response: Do not authorize the transaction. Recopy the address from the original order or receiving wallet and compare it in full. Blockchain transfers should be treated as final once confirmed; Ethereum’s official support material states that transactions sent to the wrong wallet cannot be reversed by a central operator. [9]
Transaction remains pending
Signs: A transaction hash exists, but the explorer shows no block inclusion or a pending status. The service may still display “awaiting payment.”
Response: Confirm that the hash belongs to the correct network and inspect the explorer status. Do not send the same payment again merely because the order has not updated. On both Bitcoin and Ethereum, transaction fees affect processing incentives, while actual timing depends on network conditions and transaction parameters. [10]
Successful on-chain deposit but unchanged order
Signs: The explorer shows the correct deposit address and a confirmed or finalized transaction, yet the order has not recognized it.
Response: Check whether the amount and asset match the order instructions, whether an additional identifier was required, and whether the stated confirmation threshold has been reached. Contact support with the order reference and deposit hash rather than sending another transaction.
Compliance review or request for information
Signs: The deposit is visible, but processing pauses and the service requests information through its official interface or support channel.
Response: Verify that the communication is genuine before providing data. Requirements can vary by operation and screening result. Never send a seed phrase, private key or wallet password: those credentials are not needed to verify the source of an on-chain payment.
Phishing or fake support
Signs: An unsolicited person offers to “unlock” or “recover” funds, requests remote access, asks for a seed phrase, or pressures you to send another payment. A copied page may imitate the real service while changing the deposit address.
Response: Close the message and return to the service through the route you independently saved. Official Bitcoin safety guidance recommends verifying the full receiving address and warns that legitimate support should not ask for a seed phrase or private key. [11]
Final understanding check
Before making a first exchange, you should now be able to explain and verify:
- why choosing BTC, ETH or USDT is not enough without choosing the correct blockchain network;
- which address receives the deposit and which address receives the exchanged asset;
- why the order reference and two possible transaction hashes track different parts of the process;
- how to distinguish a pending transfer, a network-confirmed deposit and a service-completed order;
- what an explorer can prove and what remains inside the service’s processing and compliance systems;
- why an address, network mismatch or phishing substitution must be detected before signing;
- which rate, fee, limit and verification conditions still need to be read on the current order rather than assumed from a general guide.
When those checks are clear, the practical next step is to review the currently available exchange route and network, then compare every order field with the sending and receiving wallets before transferring funds.
