Mempool vs confirmed

What can change while a transaction is pending, what confirmation settles, and why the radar scans full confirmed blocks instead of sampling the mempool.

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 confirmed blocks via mempool.space, not the pending mempool — a deliberate choice explained below, and one this page will help you evaluate.

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, but the public REST API exposes only a small slice of pending transactions at a time (for example, /api/mempool/recent returns roughly the ten newest). Any "live mempool whale feed" built on that endpoint is sampling, not observing — a limitation worth understanding whenever a dashboard claims real-time whale coverage.

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 scans confirmed blocks

A confirmed block is the only public data source where whale coverage can be complete: the block summary lists every transaction that made it in, so filtering it by size misses nothing. The trade-off is latency — you see a large move up to ~10 minutes after it confirms rather than while it is pending. For education (and honesty) that trade is worth it: an empty result at ≥500 BTC is a verified absence, whereas an empty mempool sample proves nothing.

Confirmed data is also stable. Pending transactions can be replaced (RBF) or evicted, which makes a "live" whale list quietly wrong minutes later. A block-scan list stays checkable: every row links to the transaction and its block on mempool.space.

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 or rate-limited, the radar will be empty or stale, and it covers only the most recent blocks — roughly the last 80 minutes, not history. CoinGecko USD columns are approximate and independent of confirmation status. See Methodology.

Practical workflow

  1. Spot a large confirmed tx on Radar.
  2. Copy txid → Brief for structure and certainty.
  3. Open mempool.space to inspect inputs, outputs, and the containing block.
  4. The txid remains valid for historical study indefinitely — see Examples.

Not trading signals. Not investment advice. Full disclaimer →