When an ETH exchange is waiting for confirmations, three systems may show three different states: your wallet may say “sent,” a block explorer may show the transaction as successful, and the exchange order may still be processing. That is not necessarily a contradiction. Each status marks a different point in the route.
The practical goal is to connect the correct transaction to the correct exchange order, then verify that it has reached the confirmation threshold required for that specific operation. There is no universal number of confirmations that every service must use.
The operation state map
- Task: exchange ETH.
- Transition condition: the selected direction accepts ETH and is currently available.
- Check: confirm the asset, exchange direction, quoted output asset, and any compliance requirements before creating the order.
- Stop if: the required pair, direction, or payment method is unavailable, or the conditions no longer match the original task.
- Input data: order details received.
- Transition condition: the order displays a destination address, the required network, the amount or calculation rules, and any operating deadline.
- Check: read these details directly from the active order rather than from an old message, browser history, or previous transaction.
- Stop if: the address is missing, the network is unclear, the order has expired, or the amount shown in your wallet would not satisfy the order terms.
- Verification: asset, network, address, and total cost.
- Transition condition: ETH is being sent on exactly the network specified by the order.
- Check: compare the entire destination address, not only its first and last characters. Confirm that the wallet balance covers both the ETH amount and the network fee.
- Stop if: the wallet proposes another network, the address changes after pasting, the fee would reduce the sent amount below what the order requires, or an unfamiliar approval or contract interaction appears.
- Action: broadcast the ETH transaction.
- Transition condition: every irreversible field has been checked and the order is still active.
- Check: after signing, save the transaction hash generated by the wallet.
- Stop if: no transaction hash appears. Do not assume the transfer was broadcast, and do not send a duplicate payment until the wallet history and sender address have been checked.
- Waiting: inclusion and confirmations.
- Transition condition: the transaction hash is visible on an Ethereum block explorer.
- Check: confirm the sender, recipient, value, network, execution status, block number, and growing confirmation count.
- Stop if: the hash belongs to another network, the recipient or value is wrong, the transaction failed, or the transaction was replaced.
- Result: exchange order completed.
- Transition condition: the transaction reaches the service’s required confirmation threshold and the order recognizes the deposit.
- Check: verify the final order status and the receiving-side transaction or other completion record supplied for the selected exchange direction.
- Stop and diagnose if: the blockchain transfer is confirmed but the order remains unpaid, processing, expired, or otherwise incomplete.
Why one Ethereum confirmation may not complete the exchange
An Ethereum transaction becomes included when a validator places it in a block. New blocks built after that block increase its confirmation depth. Ethereum documentation describes blocks as ordered batches of transactions, with each new block referencing its parent. [1]
An exchange may wait for more than initial inclusion before crediting ETH. Its threshold can reflect operational risk controls, the selected direction, the receiving system, and compliance checks. The relevant number is therefore the threshold displayed for the active order or communicated through its support channel—not a number copied from an unrelated exchange.
Ethereum protocol finality is also different from an exchange’s confirmation counter. Under Ethereum proof of stake, checkpoint voting is used to finalize blocks, making reversal economically prohibitive under normal consensus conditions. An exchange can apply its own deposit-crediting policy before or after that protocol-level milestone. [2]
Check the asset and network before sending
“ETH” identifies the asset, but it does not by itself prove that both sides are using the same network route. Wallets and services may present ETH in different network contexts. The network specified in the order must match the network selected in the sending wallet.
A familiar-looking hexadecimal address is not sufficient evidence of compatibility. Sending through an unsupported network can produce a valid blockchain transaction that the intended exchange order cannot detect or credit. Recovery may be technically impossible or operationally unavailable, so the network check belongs before signing.
The route has changed and should be stopped if the wallet requires a bridge, token approval, contract call, or network switch that was not part of the order instructions. Do not improvise a route merely because the destination address format looks plausible.
Address and Memo or Tag checks
A standard native ETH transfer identifies the receiving address in the transaction’s to field and the amount in its value field. Ethereum transactions can also contain optional input data, but Ethereum does not use the destination Memo or Tag model commonly associated with some other blockchain deposits. [3]
Do not add a Memo or Tag copied from another asset. Conversely, do not ignore an extra identifier if the active order explicitly requires one as part of a supported deposit process. The order interface is the controlling instruction for that operation.
Before confirming the transfer, compare the full address with the active order. Clipboard-replacement malware can substitute another address after copying. If the pasted value differs by even one character, cancel the transaction and investigate rather than editing it from memory.
Amount and network fee are separate values
An Ethereum transaction requires a network fee. The fee pays for computation and block inclusion; it is not automatically part of the ETH amount delivered to the recipient. Ethereum’s fee mechanism uses parameters including a maximum fee and a priority fee, while actual conditions vary with network demand. [3]
Check whether the wallet treats the entered amount as the amount to send or as the maximum total to deduct. If “send maximum” subtracts the fee from the transfer value, the recipient may receive less ETH than the order expects. Stop before signing if the wallet’s final confirmation screen does not clearly separate the recipient amount from the estimated network fee.
The exchange’s own rate, service charges, limits, and calculation rules are separate from Ethereum gas. Review the current order terms rather than assuming that the network fee is the only cost.
The final checkpoint before broadcast
- The active order still accepts payment.
- The asset is ETH.
- The sending network exactly matches the required network.
- The full recipient address matches the active order.
- No unexplained Memo, Tag, approval, bridge, or contract action has appeared.
- The recipient amount and network fee are understood separately.
- The wallet is connected through a trusted application or bookmarked interface, not a link from an unsolicited message.
Once those checks are complete, open the exchange form and verify the currently available ETH direction. Availability of a particular pair, network, or route should still be confirmed before creating and funding the order.
What to watch after sending ETH
The transaction hash is the primary reference for diagnosis. Search for that hash in a reputable Ethereum block explorer and compare the on-chain record with the order.
Pending means the transaction has been broadcast but has not yet been included in a block. A pending state can persist when the fee conditions are unattractive to validators, when an earlier transaction from the same sender is blocking the account’s transaction sequence, or when the wallet has not propagated the transaction reliably.
Successful with confirmations means the transaction was included and its execution did not fail. It does not, by itself, prove that the exchange credited the correct order. The recipient address, amount, network, and order reference still need to match.
Failed means the intended state change did not complete. A failed transaction can still consume a network fee because validators processed the attempted execution. Do not resend automatically; first identify whether the original operation was a basic ETH transfer or an unexpected contract interaction.
Delayed or incorrect transaction: diagnosis branches
The hash is not found
Confirm that the hash was copied completely and that the explorer is showing the intended network. Then check the wallet’s sending address and activity history. If the wallet only prepared or signed the transaction locally but did not broadcast it, there may be no public on-chain record.
Do not create another transfer merely to “test” the order. A delayed broadcast could later appear, leaving two payments.
The transaction remains pending
Check for older pending transactions from the same address and review the wallet’s supported speed-up or cancellation controls. Ethereum transactions use a sequential nonce, so a transaction with an earlier nonce can affect later transactions from that account. [3]
A wallet may replace a pending transaction by broadcasting another transaction from the same account with the same nonce and revised fee parameters. If replacement occurs, the original hash may be marked as dropped or replaced while a different hash becomes authoritative. [4]
Replacement is wallet-specific and can create further problems if used incorrectly. Verify which hash is confirmed before sending any information to the exchange.
The blockchain says successful, but the order does not
Compare the confirmed transaction against four fields: network, recipient address, transferred value, and block confirmation count. If all match the active order, retain the transaction hash and order identifier and use the service’s support process. Compliance review or internal processing may still affect the order state, depending on the exchange direction and review results.
If the amount is too low, do not send the difference unless the service explicitly instructs you to do so for that same order. Some systems cannot automatically combine deposits, while an expired order may calculate them under different conditions.
The address or network is wrong
A confirmed blockchain transaction is generally irreversible. Contact the operator controlling the destination address or the relevant wallet provider, but do not assume that recovery is possible. Never share a seed phrase or private key with anyone claiming that it is required to reverse the payment.
Be cautious of “recovery agents,” copied support profiles, and direct messages asking for an additional transfer. Legitimate diagnosis can use the public transaction hash; it does not require disclosure of wallet secrets.
When the route is genuinely complete
The route ends only when two verifiable records agree: the ETH transaction has reached the confirmation condition required for the order, and the exchange operation shows a completed result with the expected receiving-side record.
Some uncertainty can remain while a transaction is pending, while confirmations accumulate, or while an order undergoes operational or compliance review. Preserve the order details and transaction hash, avoid duplicate payments, and treat any mismatch in network, address, amount, or transaction identity as a reason to stop and diagnose before taking another irreversible step.