An on-chain Bitcoin transfer usually gets its first confirmation within about 10 minutes, if the fee rate is high enough for the next block. Bitcoin's difficulty rule targets 2,016 blocks every two weeks, which works out to roughly one block every 10 minutes on average. When the receiver counts the money as arrived depends on how many confirmations it requires. One confirmation takes about 10 minutes. Three take about 30 minutes, and six take about an hour. If the fee rate is too low while demand for block space is high, the transaction can wait in the queue for hours or days before the first confirmation.
Network conditions on 25 October 2026
Data from mempool.space, taken on 25 October 2026:
- Recommended fee rates: 1 sat/vB at every priority level ("fastest", "half hour", "hour" and "economy").
- Unconfirmed transactions waiting: 39,677, totalling about 22.0 million virtual bytes.
- Average block interval in the current difficulty period: about 9.5 minutes (571,758 ms), slightly faster than the 10-minute target. The next retarget is due at block 973,728.
These figures change every block. Check them again right before you send.
What happens after you press send
- Broadcast. Your wallet signs the transaction and sends it to the peer-to-peer network. Nodes check it and keep it in their mempool, the pool of unconfirmed transactions. The transaction now has zero confirmations.
- Selection by miners. Miners build blocks from mempool transactions. Space is limited because BIP 141 caps each block at 4,000,000 weight units, which is 1,000,000 virtual bytes. Miners favour the transactions that pay the highest fee rate in satoshis per virtual byte (sat/vB).
- First confirmation. Once a block containing your transaction is mined, the transaction has one confirmation.
- More confirmations. Each later block adds one more. Each extra block also makes the transaction harder to reverse, because an attacker would have to rebuild every one of those blocks faster than the rest of the network.
The 10-minute figure is an average set by the difficulty adjustment, not a timetable. The network compares how long each 2,016-block period actually took against the two-week target. It then raises or lowers the difficulty: up by as much as 300%, or down by as much as 75%. Individual gaps between blocks can be much shorter or much longer than 10 minutes.
How many confirmations you need
| Confirmations | Approximate time | What it means |
|---|---|---|
| 0 | Seconds after broadcast | Seen by the network but not in a block. The Bitcoin Wiki notes that unconfirmed payments can be reversed cheaply through race and Finney attacks. |
| 1 | ~10 minutes | Included in one block. |
| 3 | ~30 minutes | Three blocks deep. |
| 6 | ~60 minutes | The long-standing convention. The original Bitcoin client showed a transaction as unconfirmed until it was six blocks deep. |
| 100 | ~16–17 hours | Required before a miner can spend the reward from a generation transaction. This rule applies to miners only, not to ordinary transfers. |
The Bitcoin Wiki notes that six has no special status. The number was chosen on the assumption that an attacker rarely controls more than about 10% of the hashrate. Whoever receives the bitcoin sets their own threshold, so for a deposit to a service, check that service's deposit page for the number it uses.
How long until your bitcoin counts as arrived?
Enter how many confirmations the receiver requires and the average block interval to estimate the wait after your transaction enters its first block.
| Confirmations the receiver requires | Average time between blocks | Estimated wait for the required confirmations |
|---|---|---|
| 6 blocks | 10 minutes | 60 minutes |
| 1 blocks | 10 minutes | 10 minutes |
| 3 blocks | 10 minutes | 30 minutes |
| 6 blocks | 9.5 minutes | 57 minutes |
- The estimate assumes your fee rate is high enough for the next block; a low fee rate during high demand can delay the first confirmation by hours or days.
- Block intervals are an average, not a timetable, so real waits can be shorter or longer than the result.
This multiplies an average block time by a confirmation count only: it does not predict when a low-fee transaction leaves the mempool, and it does not cover Lightning payments.
What decides how fast your transfer confirms
Fee rate
Miners rank transactions by fee per virtual byte, not by the amount sent. A transfer of 0.001 BTC and a transfer of 100 BTC that are the same size and pay the same fee rate compete equally.
Transaction size
Total fee = size in virtual bytes × fee rate. BIP 141 defines virtual size as transaction weight divided by four. Weight counts non-witness data four times and witness (signature) data once. As a result, SegWit inputs cost less block space than legacy inputs.
Using the component sizes in the Bitcoin Optech size calculator:
- one SegWit (P2WPKH) input with two outputs comes to about 141 vB;
- the same transaction in legacy (P2PKH) format comes to about 226 vB.
Each additional input adds size, so a wallet holding many small coins pays more to spend them in one transaction.
Demand for block space
If more transactions are waiting than fit into the next few blocks, low fee rates wait longest. Your node also drops transactions it has held for a long time. By default, Bitcoin Core removes a transaction after 336 hours (14 days) in its mempool. Other nodes and wallets can use different settings. If the transaction expires everywhere, the coins never left your wallet.
Recent change to the fee floor
Bitcoin Core 30.0, released on 10 October 2025, lowered the default minimum relay and incremental fee rates from 1 to 0.1 sat/vB. The release notes warn that transactions paying below 1 sat/vB "are not guaranteed to propagate or confirm" unless enough nodes and miners adopt the new defaults. The wallet's own minimum fee setting did not change.
How to speed up a stuck transaction
1. Look it up. Paste the transaction ID into a block explorer such as mempool.space. It shows whether the transaction is in the mempool, its fee rate, and how that rate compares with current blocks.
2. Replace-by-fee (RBF), if you sent it. RBF lets you broadcast a new version of the transaction that spends at least one of the same inputs and pays a higher fee. Under BIP 125, the replacement must pay at least the absolute fee of the original plus enough to cover its own relay. BIP 125 originally required the transaction to signal that it could be replaced. Since Bitcoin Core 28.0 (2 October 2024), nodes accept replacements by default even when the original did not signal. Your wallet still has to offer a fee-bump option.
3. Child-pays-for-parent (CPFP), if you can spend an output. You create a new transaction that spends an output of the stuck one and pays a high fee rate. Miners consider the two transactions as a package. If the package fee rate is attractive, they confirm the parent and the child together. Either party can do this: the receiver, or the sender through the change output. Bitcoin Core 28.0 also added limited relay of one-parent-one-child packages, which helps a child carry a parent whose fee rate is below a node's minimum. The release notes say this is not yet reliable under adversarial conditions.
4. Wait. If demand drops, low-fee transactions confirm later. If one is never mined, nodes eventually drop it (see the 14-day default above).
On-chain payments cannot be reversed once confirmed. Check the receiving address before you send. A fee bump changes only the fee, never the destination.
Lightning: faster, but a different system
The Lightning Network sends bitcoin through payment channels anchored to the Bitcoin blockchain. Lightning Labs' documentation describes it as "near instant and low-cost settlement of bitcoin." Opening and closing a channel are on-chain transactions, so those steps follow the same confirmation times described above. Payments also depend on liquidity: the documentation says nodes and channels "are constrained by the capital they hold." Both sender and receiver need Lightning support.
Before you send: a checklist
- Check current fee rates and the mempool size on a block explorer.
- Use your wallet's fee estimate rather than a fixed low setting.
- Prefer SegWit (bc1q) or Taproot (bc1p) addresses to keep the transaction small.
- Make sure your wallet can bump the fee (RBF) in case conditions change.
- Find out how many confirmations the receiver requires, then estimate about 10 minutes per confirmation after the first block.
Limitations: the network figures are a single snapshot from one block explorer on 25 October 2026, and confirmation policies vary between receivers.
