The mempool: where your transaction waits before it's real
You press send, and your wallet says the transaction was broadcast. The explorer shows it — but as "pending", not confirmed. For a few seconds, minutes or occasionally hours, your transaction exists and doesn't exist at the same time.
Where it lives during that gap is called the mempool. Understanding it explains why fees change by the minute, why some transactions get stuck, and why a pending transaction is a promise rather than a payment.
What the mempool actually is
"Mempool" is short for memory pool. It's the set of valid, unconfirmed transactions a node is holding in memory, waiting for a block producer to pick them up.
The first surprise is that there isn't one mempool. Every node keeps its own. When you broadcast a transaction, your wallet hands it to a node, which checks it and passes it to its peers, which pass it on in turn. Within seconds most of the network has a copy — but each node's pool can differ slightly, depending on what reached it, its size limits and its own rules.
A transaction in the mempool has passed basic checks: the signatures are valid and the coins it spends exist. It has not been included in a block, and until it is, it can still fail to happen.
How transactions get picked
Block space is limited, and block producers — miners on proof-of-work chains, validators on proof-of-stake ones — are paid partly through fees. So, broadly, they fill blocks with the transactions that pay the most for the space they use.
On Bitcoin and similar chains, that means fee rate: satoshis per virtual byte, not the total fee. A small transaction paying a modest fee can beat a large one paying more in total. On Ethereum and other EVM chains, it means the priority tip on top of a base fee that the network itself adjusts from block to block.
This is why fees rise and fall with demand. When the mempool is quiet, almost any reasonable fee gets into the next block. When it's crowded — a popular launch, a market panic, a wave of activity — transactions bid against each other, and low-fee ones sit and wait.
Why transactions get stuck
A transaction that paid too little for current conditions doesn't fail; it waits. If demand stays high, it can sit in the mempool for a long time. Nodes don't keep transactions forever, though: when their pools fill up they drop the lowest-paying ones, and many drop anything older than a couple of weeks.
A dropped transaction was never confirmed, so the funds never moved — but until it disappears everywhere, it can still be confirmed later. That's the uncomfortable in-between: the payment is neither done nor cancelled.
The fix is usually to pay more. Replace-by-fee and similar techniques let you broadcast a new version of the same transaction with a higher fee, which replaces the old one in the mempool.
Pending is public
Everything in the mempool is visible. Anyone running a node, and any explorer, can see what you're about to do before it's final: the amounts, the addresses, and on smart-contract chains the exact function you're calling.
On most transfers that doesn't matter much. On trades, it can. Bots watch the mempool for large swaps and place their own transactions around them to profit from the price movement — front-running and sandwich attacks both depend on seeing your transaction while it's pending.
It also matters for anyone receiving funds. A pending incoming transaction can still be replaced or dropped. It isn't money you have yet.
From pending to final
Being included in a block is the first confirmation — the transaction has left the mempool and joined the chain. Each block built on top makes it harder to undo. How many confirmations are enough depends on the chain and the amount, but the rule is the same everywhere: pending means possible, confirmed means likely, and deeply confirmed means final.
How this looks in SSP
When you send from SSP, you choose how much priority to pay for. The send screen offers slow, normal and fast presets based on current network conditions, with an estimate of how long each is likely to take, and a custom option on EVM chains if you want to set the fee yourself.
Both SSP Wallet and SSP Key must approve before anything is broadcast. Once the transaction reaches the network, the mempool works the same for SSP as for anyone else: the fee you chose decides how quickly it's picked up, and until it confirms, it's pending.
The honest summary
The mempool is the waiting room between "sent" and "done". It's many rooms, not one; it's public; and it prioritises whoever pays the most for block space.
Pick a fee that fits how quickly you need confirmation, don't treat a pending transaction — yours or someone else's — as final, and remember that anything you broadcast is visible to the whole network before it's settled.
