Stuck Transaction
Pronunciation: STUHK tran-ZAK-shuhn
Definition
A stuck transaction remains pending longer than expected without reaching confirmation, rejection, expiry, or another conclusive state. Causes can include insufficient fees, nonce conflicts, network congestion, provider queues, compliance review, or incomplete downstream processing.
Overview
Understand the idea
The diagnosis begins by locating the last authoritative stage. A transaction can be stuck before submission, accepted by a provider but not forwarded, present in a mempool, blocked behind an earlier nonce, or confirmed externally while the local system failed to observe the event.
Recovery depends on the rail and state. Options may include fee bumping, replacement, child-pays-for-parent, resubmission, provider escalation, waiting for expiry, or repairing event consumption. These actions should never be applied without checking whether the original can still complete.
Monitoring should compare elapsed time with current network or provider conditions and identify customer impact and value at risk. The system should preserve every attempt and related identifier. Resolution requires authoritative evidence and reconciliation, because a delayed transaction can complete after an operator has already begun recovery.
What actually happens
A stuck transaction is a transfer that stays pending or cannot advance as expected. In Bitcoin, an insufficient fee rate relative to competing mempool demand is a common cause. On Ethereum-like networks, fee settings, a blocked account nonce or node propagation issues can prevent inclusion. A transaction can also be included but reverted; that is an execution failure, not the same condition as remaining pending.
Diagnosis begins with the correct chain, transaction identifier, nonce or input set, broadcaster and current network rules. On Bitcoin, wallets may be able to use replace-by-fee or child-pays-for-parent mechanisms, depending on policy and transaction structure. On EVM systems, a same-nonce transaction with appropriate fee parameters can sometimes replace a pending one, but its content must be reviewed carefully. Monitoring should identify replacements and resolve which candidate, if any, ultimately became canonical.
Decisions and failure cases
Do not advise customers to send a second independent payment as the default fix. A delayed original can later confirm and create an overpayment. 'Cancel transaction' buttons may be replacements, not guaranteed reversals. Custodial exchange withdrawals add another layer where the service has not necessarily broadcast any on-chain transaction yet.
Related concepts
Network Congestion, Partial Payment, Wrong Network Payment.
Further reading
Example
A shop receives a Bitcoin transaction spending a low fee and waits several hours with zero confirmations. The buyer's wallet might offer fee bumping. The merchant must not fulfill solely because the transaction was rebroadcast at a higher rate; it should verify whether a paying output became confirmed in the accepted chain.
Comparison
A stuck transaction remains unresolved before inclusion or completion. A failed transaction has definite unsuccessful execution or rejection evidence. A late payment is a business-timing classification.
Key Takeaway
A stuck transaction remains pending longer than expected without reaching confirmation, rejection, expiry, or another conclusive state.
Sources
- Bitcoin Developer Guide: Transactions — Bitcoin.org (2026-08-02)
- Ethereum Transactions — Ethereum Foundation (2026-08-02)