An Ethereum account that shows several transactions pending at once is usually blocked by a single one. The account's transaction counter forces strict ordering, and one stalled entry holds the rest.
The counter attached to every account
Each account carries a nonce, a number that increments by one with every transaction it sends. The network will only process transaction number five after number four has been included.
The purpose is replay protection. Without a strictly increasing counter, a signed transaction could be rebroadcast repeatedly and drain the account, since the signature itself remains valid forever.
The counter is maintained by the network's own accounting rather than by the wallet. A wallet reads it, but the chain decides what the next acceptable number is.
Why one transaction blocks the queue
If a transaction priced too low sits unconfirmed, every later transaction from the same account carries a higher nonce and cannot be processed ahead of it.
The result looks like several unrelated failures. A swap, a transfer and an approval all appear stuck, when only the earliest one is actually the problem.
Nothing is lost during this. The queued transactions remain valid and will confirm in order the moment the blocking entry clears.
Replacing rather than retrying
The fix is to send a new transaction reusing the same nonce with a higher fee. Nodes treat it as a replacement, and only one version can ever be included.
A cancellation is the same trick with empty content: a transaction sending nothing to the sender's own address, using the stuck nonce and a competitive fee.
The replacement must clear the network's minimum increase over the original bid, which is why a barely higher fee is often rejected outright by nodes.
Where wallet interfaces obscure this
Many wallets hide the nonce entirely and present a speed-up button instead. That button is doing exactly the replacement described above, with the fee raised automatically.
Confusion arises when the same account is used across two interfaces, because each may compute the next nonce from a different view of pending activity.
Gaps cause a related failure. A transaction signed offline with a nonce far ahead of the current counter will sit unprocessed until every intermediate number has been used.
What this design buys the network
Strict ordering makes account state predictable. A contract can rely on the fact that an account's actions arrive in the order that account authorized them.
It also makes the fee market legible, since a sender competes for inclusion of a specific next action rather than having several of their own transactions race each other.
The cost of that guarantee is the failure mode described here, where one underpriced entry stops an account rather than being quietly skipped.