An ETH exchange can appear stuck at several different stages: before the transaction reaches Ethereum, while it is pending in the network, after it enters a block, or during the exchange service’s internal processing. The transaction hash is the dividing line. If a valid hash exists, on-chain evidence can show what happened. If no hash has been issued, a block explorer cannot diagnose the delay, and the exchange service must clarify whether the transfer was broadcast.
How the claims were checked
Protocol-level claims were matched against Ethereum’s transaction, gas, JSON-RPC, and finality documentation. Pending-transaction behavior was also checked against documentation from the Geth execution client and Etherscan’s transaction guidance. Source update dates are shown in the claim register where freshness could affect the conclusion.
These sources can verify blockchain state and explain Ethereum’s mechanisms. They cannot reveal an unnamed exchange’s confirmation threshold, wallet queue, maintenance status, liquidity process, or compliance decision. Those details remain conditional until the service publishes them or responds with case-specific information.
What a delayed status actually means
Submitting an Ethereum transaction does not immediately settle it. The signed transaction is broadcast to the network and enters transaction pools; a validator must then select it for inclusion in a block. Its block may subsequently progress through stronger consensus states, including finalization. [1]
An exchange interface may use the word “pending” for a different process. It can mean that the service has created an order but has not broadcast its outgoing transaction, that an incoming deposit has not met the service’s confirmation policy, or that an on-chain transfer is complete but the order is still undergoing internal review. Only the middle part of this sequence is directly observable through an Ethereum block explorer.
First identify which transaction is delayed
- You sent ETH to the exchange: inspect the transaction hash supplied by your wallet. A pending deposit transaction may still be waiting for block inclusion.
- The exchange is sending ETH to you: use the withdrawal hash supplied by the exchange. If no hash exists, there is no public proof yet that the withdrawal was broadcast.
- The ETH transfer succeeded, but the swap is unfinished: the delay is probably outside Ethereum’s transaction pool. Confirmation rules, order processing, destination-chain activity, or compliance checks may still apply.
Do not use an order number as if it were a transaction hash. An Ethereum transaction hash is an on-chain identifier, while an exchange order ID normally identifies a record in the service’s own system.
The main on-chain causes
The fee is no longer competitive
Ethereum fees contain a protocol-set base fee and a user-selected priority fee. A transaction’s maximum fee must be sufficient for the applicable base fee and tip. When network demand changes, a transaction submitted with conservative fee settings may remain pending because validators have stronger economic reasons to include other transactions first. [2]
This does not prove that every delayed exchange transaction has a low fee. An exchange may control the sending wallet and fee settings, leaving the customer unable to modify them. Current fee conditions must be checked at the time of diagnosis rather than inferred from conditions when the order was created.
An earlier transaction is blocking the nonce sequence
Transactions sent from one Ethereum account use sequential nonces. Client transaction pools distinguish transactions ready for processing from those queued for future processing, and they may contain several candidate transactions associated with the same account and nonce. [3]
If a wallet has an unresolved lower-nonce transaction, a later transaction can remain queued even when the later one offers an adequate fee. This cause is most relevant when several transfers were initiated from the same address in quick succession. It cannot be confirmed from the delayed order status alone; the sending address’s transaction history and nonce sequence must be examined.
The original transaction was replaced or dropped
A still-pending transaction may be replaced by another transaction from the same account using the same nonce and a more competitive fee. Once a transaction has already been included in a block, it cannot be replaced through this mechanism. [4]
A replacement receives a different transaction hash. An exchange interface that continues monitoring only the original hash may therefore display stale information until its systems detect the replacement. A “dropped” or “replaced” label should prompt a search for another transaction from the same sender with the same nonce, not an immediate second payment to the exchange.
Inclusion and exchange acceptance are different milestones
A transaction receipt is available after execution and includes a status indicating success or failure. The Ethereum JSON-RPC documentation states that a receipt is not available for a pending transaction; a receipt query returns no receipt when one has not been found. [5]
Successful execution proves that Ethereum processed the transaction. It does not prove that the exchange has credited the intended order. The service may still need to match the sender, asset, amount, destination address, network, and order conditions. Its required number of confirmations or finality standard is a platform policy, not a universal Ethereum constant.
Claim register
| Claim | Verification status | Primary source type and name | Published or updated | Limitation | What could change the conclusion |
|---|---|---|---|---|---|
| A transaction may remain pending when its offered fee is too low for current network conditions. | Confirmed mechanism; transaction-specific cause remains conditional | Ethereum protocol education documentation, “Ethereum gas and fees: technical overview” [2] | Updated June 24, 2026 | The source explains fee selection but does not diagnose a particular hash. | A falling base fee, reduced demand, rebroadcasting, or a valid replacement transaction may allow inclusion. |
| A transaction without a receipt has not been demonstrated as executed through the receipt method. | Confirmed | Ethereum client interface documentation, “JSON-RPC API” [5] | Updated June 28, 2026 | A temporary explorer or RPC display problem can also prevent a user interface from showing available data. | Checking the hash through another reputable Ethereum explorer or RPC endpoint may reveal a newly issued receipt. |
| A lower-nonce transaction can be relevant when a later transaction from the same address is queued. | Dependent on the sending address’s nonce sequence | Official Geth client documentation, “txpool Namespace” [3] | Edited August 16, 2023 | Transaction-pool contents differ between nodes, and an exchange may not expose its wallet’s complete queue. | Confirmation or replacement of the earlier nonce, rebroadcasting, or new information from the sender can change the diagnosis. |
| Ethereum block inclusion does not necessarily satisfy an exchange’s acceptance policy. | Confirmed distinction; platform requirement unknown | Ethereum transaction lifecycle and finality documentation [1] | Transaction page updated March 12, 2026; finality page updated July 23, 2026 | Ethereum documents consensus states, not the unnamed exchange’s required confirmations or processing rules. | The exchange’s current deposit or withdrawal policy, an order update, or a case-specific support response. |
| The exchange may delay an order for an internal compliance review even after an on-chain transfer succeeds. | Unknown for the specific order; conditions can depend on the transaction direction and compliance results | No case-specific primary record supplied | Not available | A blockchain explorer cannot display private account reviews or requests for additional information. | A status message, current service terms, or a direct request from the service identifying the review stage. |
| The exact confirmation threshold and expected processing time for this exchange operation are known. | Not established | No current service policy or order record supplied | Not available | Thresholds and processing rules may vary by asset, network, direction, operational conditions, and compliance outcome. | Current terms shown before order creation or transaction-specific information from support. |
A step-by-step diagnosis
- Copy the transaction hash from the wallet or exchange order. Obtain it from the authenticated app or website, not from an unsolicited support message. If no hash exists, ask whether the transaction has actually been broadcast.
- Confirm the network. Check that the sender used the exact network and deposit route specified for the order. “ETH” is an asset label, not sufficient proof that both sides selected the same chain.
- Verify the addresses and amount. Compare the full recipient address with the address assigned to the order. Do not rely only on the first and last few characters or copy an address from transaction history without rechecking it.
- Read the on-chain status. “Pending” means there is no confirmed execution receipt yet. “Success” means the transaction executed. “Failed” means it entered a block but execution did not complete successfully; a failed transaction is not the same as an unbroadcast withdrawal. [5]
- If it is pending, inspect the fee and nonce. Compare the transaction’s fee parameters with current conditions and look for an earlier unresolved transaction from the same sending address.
- Check for a replacement. If the original hash is marked dropped or replaced, search the sender’s history for a transaction using the same nonce. Give the exchange the replacement hash if it delivered the required funds.
- If it succeeded, compare timestamps. Record the order creation time, block inclusion time, and latest order update. This separates network waiting from the exchange’s post-confirmation processing.
- Contact support with evidence, not secrets. Provide the order ID, transaction hash, selected asset and network, sending and receiving addresses, and screenshots of the status. Never provide a seed phrase, private key, wallet password, or remote access to the device.
Actions that require caution
A wallet’s “speed up” function normally attempts to replace a pending transaction with another transaction using the same nonce and a higher fee. Ethereum’s support documentation lists speeding up and nonce-based cancellation as possible responses to a stuck transaction. [6]
Use such controls only when the transaction is still pending, the sending wallet supports them, and you understand which nonce is being replaced. If the exchange controls the sending address, only the exchange can manage that outgoing transaction. Creating an unrelated second transfer does not speed up the first one and may result in paying twice.
Cancellation is also not guaranteed. It is a competing transaction, not a reversal command. If the original transaction enters a block first, its transfer takes effect. Once an Ethereum transfer is confirmed, the network cannot reverse it merely because the wrong address or network route was used. [6]
Security and operational risks
- Wrong address or network: a successful on-chain transfer can still fail to match the exchange order. Recovery may be impossible or may depend entirely on the recipient service’s technical capabilities.
- Irreversibility: confirmed Ethereum transfers cannot be recalled through a bank-style chargeback. Verify the complete address, network, and order state before signing. [6]
- Phishing: scammers often impersonate support during a delay. Legitimate troubleshooting does not require disclosure of a seed phrase or private key.
- Volatility: the asset’s market value can move while the order is pending. Whether a quote is fixed, recalculated, or cancelled depends on the terms accepted for that specific operation.
- Compliance differences: verification requirements can depend on the exchange direction, transaction characteristics, compliance results, and applicable national rules. Current requirements should be checked before creating an order.
How to repeat the check with current data
Network fees, transaction-pool visibility, confirmation counts, exchange routes, and compliance requirements are dynamic. Repeat the check whenever the order status changes: reopen the transaction by its hash, confirm whether a receipt now exists, note the latest block and confirmation state, search for a same-nonce replacement, and compare the result with the service’s current order page.
Do not assume that a route or Ethereum network option remains available because it appeared in an earlier order. Before sending funds, check the currently available exchange directions and network details. This link is a practical service check, not evidence for any technical claim above.
The decisive next step depends on one observable boundary: no transaction hash means the sender or exchange must explain the pre-broadcast delay; a pending hash requires fee, nonce, and replacement checks; a successful hash shifts the investigation to address matching, confirmation policy, order processing, and any applicable compliance review.