An ETH exchange can appear stuck for several different reasons. The transaction may not yet have been broadcast, it may be waiting for inclusion in an Ethereum block, or it may already be confirmed on-chain while the exchange is still matching the deposit, waiting for its required confirmation threshold, or performing an applicable compliance check. The transaction hash and block-explorer status are the fastest way to identify which stage is causing the delay.
How the claims were checked
Technical claims below are tied primarily to Ethereum’s transaction, gas, JSON-RPC, and consensus documentation. Geth documentation is used for transaction-pool and nonce behavior, while Etherscan guidance is used only to explain statuses displayed by a widely used Ethereum block explorer. Source update dates are shown in the claim register so that older operational guidance is not presented as if it were a recent protocol announcement.
No universal exchange processing time, confirmation requirement, fee, or limit can be established from Ethereum documentation. Those conditions belong to the individual service and may also depend on the exchange direction and the outcome of compliance checks.
What happens between sending ETH and completing an exchange
An Ethereum transaction has to be signed, broadcast to the network, placed among pending transactions, and selected by a validator for inclusion in a block. A transaction hash is generated as part of this lifecycle. Inclusion in a validated block changes the transaction from pending to confirmed, while later consensus stages provide stronger assurance that the block will not be altered. [1]
This creates an important distinction: an exchange order and an Ethereum transaction are not the same record. The order may exist before an on-chain transfer is broadcast, and it may remain open after that transfer is included in a block. Therefore, an order status alone cannot show whether Ethereum itself is delayed.
If the explorer says “Pending”
A pending transaction has been broadcast but has not yet been included in a block. Ethereum’s JSON-RPC documentation states that a transaction receipt is unavailable while the transaction remains pending. Once a receipt exists, it identifies the block, gas used, effective gas price, and whether execution succeeded or failed. [2]
Fee settings can affect how quickly a valid transaction is selected. Ethereum transactions use a protocol-defined base fee and a priority fee. When demand for block space rises, transactions offering a more competitive priority fee can be more attractive for inclusion. This does not provide a guaranteed waiting time: network demand and competing transactions can change after submission. [3]
If the explorer says “Success”
“Success” means the transaction was executed and included in a block. It does not by itself prove that the exchange has finished processing the order. A service may still need to detect the payment, verify that the destination address, asset, network, and amount match the order, wait for its own confirmation requirement, or complete an applicable review. Ethereum documentation cannot reveal an exchange’s internal status or processing policy.
If there is no usable transaction hash
Without a transaction hash, there is no direct identifier with which to verify the transfer on a block explorer. That does not establish a single cause. The wallet or sending service may still be preparing the withdrawal, the broadcast may have failed, or an interface may not yet have displayed the hash. The appropriate evidence is the hash supplied by the sender, followed by its status on an explorer for the network selected in the exchange order.
Claim register
| Claim | Status | Primary source type and name | Publication or update date | Limitation | What could change the conclusion |
|---|---|---|---|---|---|
| A transaction must be broadcast and included in a validated block before it is successful on Ethereum. | Confirmed | Protocol education documentation: Ethereum.org, “Transactions” | Updated July 25, 2026 | This describes Ethereum’s lifecycle, not an exchange’s internal order processing. | A future protocol change could alter transaction types or lifecycle details. [1] |
| A pending transaction has no transaction receipt yet. | Confirmed | Execution API documentation: Ethereum.org, “JSON-RPC API” | Updated June 28, 2026 | An explorer may use additional interface labels, but the absence of a receipt remains the decisive on-chain distinction. | Changes to execution API semantics or transaction handling could require reassessment. [2] |
| Fee competitiveness can contribute to a transaction remaining pending when demand is high. | Dependent on conditions | Protocol documentation: Ethereum.org, “Ethereum Gas and Fees” | Updated June 24, 2026 | A low-looking fee is not proof of the cause; nonce order, transaction validity, node propagation, and replacement behavior may also matter. | Current network demand, the transaction’s fee fields, and protocol fee-market changes. [3] |
| A later transaction from the same account can be queued behind an earlier nonce. | Confirmed, but diagnosis requires account data | Execution-client documentation: Go Ethereum, “txpool Namespace” | Edited August 16, 2023 | Transaction pools differ between nodes, so one node’s view is not a complete view of every pending transaction. | Confirmation or replacement of the earlier transaction, rebroadcast behavior, or client policy changes. [4] |
| A transaction can be shown as dropped and replaced when another transaction using the same sender nonce is accepted. | Supported by explorer guidance | Block-explorer guidance: Etherscan Information Center, “Transaction Dropped & Replaced” | Published December 5, 2019 | The source is older and explains Etherscan’s status presentation; it is not a promise that every explorer will use identical wording. | A replacement transaction, rebroadcast, explorer indexing, or updated client transaction-pool policies. [5] |
| The exchange’s required number of confirmations and internal processing time caused a particular delay. | Unknown without order-specific evidence | Service order record, current terms, or official support response | Not provided | Ethereum data can confirm an on-chain event but cannot identify an unpublished exchange workflow or compliance decision. | The order status, current requirements for the selected direction, and results of any applicable review. |
What the evidence means for a user
- Find the transaction hash. Obtain it from the wallet or sending service. Do not confuse it with an exchange order number.
- Check the correct network. The network selected by the sender must match the network and deposit details shown for the order. Do not assume that every ETH-related network or exchange direction is available.
- Read the on-chain status. “Pending” points to the network-submission stage. “Success” moves the investigation to exchange matching and processing. “Failed” means the recorded execution did not complete successfully. A dropped or replaced label requires locating the replacement hash.
- Compare the addresses and amount. Check the full sending and receiving addresses rather than a shortened preview. If a memo, tag, or other identifier was required for the chosen direction, verify that as well.
- Contact the responsible party with evidence. For a pending withdrawal created by a custodial service, ask that sender for the hash or current broadcast status. For a successful deposit that has not been credited, provide the exchange with the order identifier and transaction hash through its official support channel.
After completing the on-chain checks, you can check the currently available exchange directions and network requirements. Availability should be confirmed before creating an order; this link is a practical next step, not evidence for any technical claim above.
Risks and repeat-check procedure
Do not resend ETH merely because the order page has not updated. A second transfer would be a separate transaction and could result in sending twice. If a wallet offers a speed-up or cancellation function, first confirm which account created the pending transaction and whether it is still pending. Transactions with the same sender nonce can replace one another, so an old hash may stop being the relevant reference. [4]
Check the asset, network, and complete recipient address before approving any new transaction. Ethereum transactions are irreversible after they are recorded, and sending to the wrong address can make recovery impossible without the recipient’s cooperation. Never give a recovery phrase or private key to someone claiming they can “unstick” the transfer, and use only the service’s official support channel to reduce phishing risk. [6]
Dynamic conditions should be checked again rather than inferred from an earlier screenshot. Reopen the transaction by hash, note whether it is pending, successful, failed, dropped, or replaced, and compare the latest block information with the order status. Then verify the exchange’s current network availability, confirmation policy, and compliance requirements for that specific direction. Requirements can differ between operations and countries, and no general article can determine the legal, tax, or compliance treatment of an individual transaction.