Mempool vs confirmed

Why the radar shows pending transactions, what can change before confirmation, and how that differs from settled chain history.

When you broadcast a Bitcoin transaction, it enters the mempool (memory pool): the set of valid, unconfirmed transactions that miners and nodes can see. Once a miner includes it in a block and that block is built upon, the transaction is confirmed. bitcoinwhale.org's Radar reads the recent mempool tip via mempool.space — not confirmed history. That design choice is intentional for watching large moves as they appear, but it comes with limits.

What the mempool is

Each full node keeps its own mempool. There is no single global mempool — different nodes may see slightly different sets depending on propagation, fee filters, and policy. Explorers like mempool.space aggregate a view you can query over HTTPS. The /api/mempool/recent endpoint returns only a small slice: the most recently seen pending transactions, not every pending tx in the network.

For education, think of the mempool as a waiting room. Transactions sit there until a block has space and the attached fee is competitive enough for miners to prioritize them.

What confirmation means

A transaction with one confirmation is in the latest block (or a recent one). Each additional block buried under it adds security against reorganization — the practical risk that a chain rewrite could undo the payment. Large exchanges often wait for several confirmations before crediting deposits; that policy is off-chain business logic, not a Bitcoin rule.

After confirmation, the transaction leaves mempools and becomes part of immutable chain history (modulo extreme reorg events, which are rare on mainnet at depth). Tools like our Brief work on confirmed or unconfirmed txids alike — they fetch the tx payload from the API.

Why the radar is pre-confirmation

Large pending transfers are sometimes interesting before they settle: you see fee choices, vsize, and output structure while the tx is still competing for block space. That is useful for learning how custodians and miners behave under congestion — not for front-running markets. We refresh roughly every 25 seconds and retain sightings in memory during your visit so sparse whale activity can accumulate.

Entries marked aging have fallen off the live tip. They may have confirmed, been evicted from mempool, or replaced. The radar does not re-query each old txid; verify on an explorer.

What can change in the mempool

  • Replacement (RBF). If signaled, a higher-fee version can replace the original txid.
  • Dropping. Low-fee txs may leave mempools during congestion without ever confirming.
  • Rebroadcast. Wallets may re-announce the same tx; explorers may show duplicates differently.
  • Confirmation. The tx disappears from "pending" and gains a block height — the normal outcome.

API limits (honest)

We depend on mempool.space endpoints from your browser. We do not operate mirrors or guarantees. If the API is down, rate-limited, or returns an incomplete recent set, the radar will be empty or stale. CoinGecko USD columns are approximate and independent of confirmation status. See Methodology.

Practical workflow

  1. Spot a large pending tx on Radar.
  2. Copy txid → Brief for structure and certainty.
  3. Open mempool.space to watch confirmation progress.
  4. After confirmation, the same txid remains valid for historical study — see Examples.

Not trading signals. Not investment advice. Full disclaimer →