What a mempool is
Every full node on a blockchain keeps its own mempool — a working list of valid transactions that have been broadcast to the network but not yet mined or validated into a block. When you send a transaction, your wallet hands it to a node, that node checks it is well-formed and broadcasts it onward, and it spreads from node to node until most of the network is holding it in their mempools. From there it waits to be picked up by whoever produces the next block.
The mempool is a staging area, not a permanent record. Because each node maintains its own copy, mempools are not perfectly identical across the network — a transaction can be in one node's pool before it reaches another, and nodes prune or drop transactions under their own rules. Block producers generally select from the mempool by fee, taking the transactions that pay the most for the block space they consume, so a transaction offering a higher fee tends to leave the mempool sooner while a low-fee one can linger.
A transaction does not stay in the mempool forever. It leaves when it is included in a block — at which point it becomes confirmed and stops being pending — or when it is dropped: evicted because the pool is full, expired after sitting too long, or invalidated because a conflicting transaction (for example, one spending the same coins) got mined first. Until one of those things happens, the transaction is genuinely in limbo: announced to the world but not yet part of the chain's settled history.
What it means in a crypto payment
For a merchant, the mempool is the earliest sign that a customer has paid — and also the reason that sign cannot be trusted on its own. The moment a payer broadcasts their transaction it appears in the mempool, often within seconds, so a payment can be detected as pending well before it is settled. But a mempool transaction has zero confirmations: it has not been written into any block, and there is no guarantee it ever will be at the amount and terms you expect.
Several things can change between the mempool and a confirmed block. A low-fee transaction may sit unconfirmed for a long time during congestion, or be dropped entirely. On chains that allow it, a payer can replace a pending transaction with a different one — bumping the fee, or redirecting the funds — before it confirms. Treating a mempool sighting as a completed payment is what makes accepting zero-confirmation transactions risky: the safe line is to wait for the transaction to actually land in a block and accumulate the confirmations that chain requires.
The mempool on halfin
halfin uses mempool visibility to react early, not to settle early. Seeing a customer's transaction announced to the network lets an invoice move out of a plain waiting state and reflect that a payment is on its way and being confirmed — useful feedback for the payer and the merchant — but it does not mark the invoice paid. Settlement waits for the transaction to be mined into a block and to reach the per-chain confirmation threshold halfin applies to that network.
Because crediting is reorg-aware and threshold-based, a payment that is still in the mempool, or that is dropped or replaced before it confirms, never leaves a paid invoice standing. The lifecycle reflects this: an invoice can show a confirming state once a deposit is seen and being confirmed, then move to paid only once it is deep enough to rely on, with overpaid and underpaid evaluated against the amount that ultimately confirms. Webhooks follow the same sequence — for example invoice.confirming while the deposit is in flight, then invoice.paid on settlement — so an integration reacts to the mempool stage as an early signal and acts on real money only when the chain has actually settled it.
- Mempool = broadcast but unconfirmed — the transaction is visible across the network but not in any block yet.
- Zero confirmations — a mempool transaction can still be delayed, dropped, or replaced before it lands in a block.
- Early signal, not settlement — halfin uses it to show a payment is on its way, then waits for the per-chain confirmation threshold.
- Reorg-aware crediting — a deposit only sticks once it is confirmed deeply enough to rely on, so a stalled mempool transaction never marks an invoice paid.