A transaction broadcast to a blockchain does not enter a block immediately. It waits in a holding area maintained separately by each node, and the rules of that area explain most confirmation problems.
There is no single queue
Every node keeps its own list of pending transactions, populated by whatever it has heard from its peers. These lists overlap heavily but are never identical.
Propagation across the network takes time, and nodes apply their own policies about what to accept. A transaction visible in one explorer may be absent from another.
This is why pending status can look inconsistent depending on where you check. The mempool is a loose consensus about what is waiting, not an authoritative register.
Selection is an auction, not a line
Block producers choose which pending transactions to include, and they are compensated by the fees attached. Higher paying transactions are selected first.
Arrival order carries no weight. A transaction submitted an hour ago with a low fee will sit behind one submitted seconds ago with a higher one.
Users accustomed to first-come service find this counterintuitive, but the design is deliberate. Block space is scarce, and price is the mechanism that allocates it.
Congestion changes the clearing price
Fee levels are set by competition among waiting transactions rather than by any schedule. When demand for block space surges, the fee needed for prompt inclusion rises quickly.
Wallets estimate this by observing recent blocks and current mempool contents. Those estimates lag reality, which is why a transaction can be underpriced moments after being sent.
Once the surge passes, the same fee that was inadequate becomes generous. Waiting is often the cheapest response to congestion.
Transactions can be evicted entirely
Nodes cap how much pending data they hold in memory. When that limit is reached, the lowest paying transactions are dropped to make room.
A dropped transaction has not failed and has not succeeded; it has simply been forgotten by parts of the network. It may still exist elsewhere and confirm later.
This ambiguity is what makes stuck transactions frustrating. There is no cancellation to observe, only an absence that may or may not be permanent.
Visibility creates its own problems
Because pending transactions are public before confirmation, anyone can read what is about to happen and act on that knowledge. Automated systems monitor mempools continuously.
A large trade waiting for inclusion reveals its intention to observers who can submit their own transactions with higher fees. The waiting room is transparent by design.
Private submission channels that route transactions directly to block producers exist partly in response. They trade the network's openness for protection against being read in advance.