New requests receive the status "Waiting" and are not processed

As you know, a transaction with a higher "transaction fee" gets into the block faster. There is a price at which the transaction is guaranteed to be included in the next block. There is no point in paying more (overpaying), because there is no way to confirm faster. In addition, speed is not important to everyone. Someone is willing to wait just to save on commission.

Depending on the network load the "current actual" price can vary greatly (by a factor of 100). And there is no way to accurately calculate or find out this price. If you have not specified the transaction price in the parameters, then the service uses the average "actual" price obtained from different sources.

With a heavy load on the network, it happens that the real actual price grows very sharply and the service is late to raise it. In this case, transactions are sent with a lower price. Such transactions remain in pending status longer. But worst of all, subsequent transactions (no matter how high the price at which they were sent) cannot be confirmed until that first transaction is confirmed. A situation occurs in which one pending transaction "locked" subsequent ones. All these applications will have the status "Confirmation [0]".
In order not to create long chains of "pending" transactions, the service does not send new transactions if the queue already contains 10 pending transactions!

There are two ways out of this situation:

• Wait until the load (and price) goes down and the transaction is included in the block
• Re-send (replace) transaction with a new one, with a higher price

To determine which transaction has locked the rest, you need to view all transactions of the payer address in the blockexplorer:

And find the first (with the smallest Nonce) pending transaction. Copy and use in the future its Txn Hash (txid).