A queued transaction is a blockchain operation submitted to the network but placed in a non-executable state, so it cannot be included in the next block. It remains in a node's memory pool (mempool) until the conditions for processing are met.
When a user initiates a cryptocurrency transfer, the transaction does not reach the blockchain immediately. Instead, it is broadcast to network nodes, where it lands in the mempool, a temporary staging area holding unconfirmed operations. Each node maintains its own version of this pool, and transactions propagate across the network until a block producer, either a miner in proof-of-work systems or a validator in proof-of-stake systems, includes them in a new block.
Within the mempool, transactions have one of two statuses: pending or queued. Pending transactions have passed node validation and are eligible for immediate inclusion in the next block. Queued transactions have not yet met the conditions for execution and remain on hold until those conditions are resolved.
A transaction typically becomes queued for one of two reasons.
The first involves prior unconfirmed transactions from the same address. When a sender has an earlier transaction still awaiting confirmation, any later transaction from that address cannot leapfrog it. The later operation is held back until the earlier one clears.
The second, more technical cause involves an incorrect nonce value. On account-based blockchains like Ethereum, every transaction from an address carries a nonce, a sequential number tracking how many confirmed transactions that address has sent. The network requires nonces to be processed in strict order. If a transaction carries a nonce higher than expected, it cannot execute until the gap is filled by a transaction with the correct nonce. The out-of-order transaction remains in the queued pool until this gap is resolved.
The difference between queued and pending is not just timing but executable status. A pending transaction has been validated by nodes, confirming the sender's signature is legitimate and the account has sufficient funds. It is available for block producers to include. A queued transaction has not reached this stage and remains invisible to confirmation until the blocking condition, such as a missing earlier transaction or an out-of-sequence nonce, is resolved.
On Ethereum's Geth client, for example, a single node can store up to 1,024 non-executable (queued) transactions by default. Transactions that fail to resolve their queued state before hitting this limit or other node-imposed thresholds risk being dropped from the pool entirely.
Among pending transactions eligible for execution, transaction fees determine the order of selection. Block producers are incentivized to include transactions with the highest fees, as these compensate their validation work. On Bitcoin, miners rank transactions by fee rate in satoshis per byte. On Ethereum, after the EIP-1559 upgrade, the fee structure includes a base fee that is burned and an optional priority fee, or tip, paid directly to validators. When network traffic is heavy, users who underbid fees may see their transactions linger in the pending pool or be dropped.
This fee-driven prioritization means that during high congestion, the effective queue is not strictly first-in, first-out. A later transaction with a higher fee can be confirmed before an older, lower-fee one.
When a transaction is stuck in the queued state, especially due to a nonce gap, practical remedies exist. The simplest is to submit a new transaction from the same address using the missing nonce. Once that gap-filling transaction is confirmed, the stuck transaction can move to pending and be processed.
Another option is replacing a stuck transaction by resubmitting it with the same nonce but a higher fee. On Ethereum, this is called "speed up" or, to cancel, submitting a zero-value transaction to oneself with the same nonce and higher gas price. Once the replacement is confirmed, the original becomes invalid and is dropped from the mempool. Bitcoin has a similar mechanism called Replace-By-Fee (RBF).
Users who wait without action may eventually see their transactions confirmed once congestion eases, though this can take hours or days depending on network conditions.
Several blockchain explorers allow users to track where their transactions stand in real time. Etherscan, Ethplorer, and EthVM serve this function for Ethereum, while BTCScan and Bitcoin Explorer cover Bitcoin transactions. Tools like Mempool.space provide a live view of the Bitcoin mempool, including unconfirmed transaction counts, fee ranges, and block estimates. These resources help users decide whether to wait, speed up, or replace a stalled transaction.
The frequency and duration of queued and stuck transactions are directly tied to network throughput limitations. Blockchain networks are designed to process a finite number of transactions per second, and when demand exceeds that capacity, congestion drives more transactions into prolonged queued or pending states.
Ongoing development efforts aim to reduce these bottlenecks. Solutions such as sharding, which distribute transaction processing across multiple parallel chains, and layer-two protocols, which handle transactions off the main chain before settling results on it, are designed to increase overall throughput. As these scaling technologies mature, the conditions that drive transactions into lengthy queued states are expected to become less common.
.webp)