Transaction Confirmation Time Calculator
Estimate how long a transaction takes to reach any confirmation depth using Est. Time = Confirmations × Block Time. Enter confirmations and average block time, or solve for either input given a target wait time.
Each block adds one confirmation. The first block containing your transaction is Confirmation 1 (teal). The block that reaches your target depth is highlighted (amber). Scroll horizontally if the target exceeds the visible track.
Block times and confirmation requirements vary by chain and by venue. Exchange deposit requirements are usually stricter than wallet-to-wallet transfers.
This is a statistical expectation, not a guarantee
Block intervals are random. Bitcoin's protocol targets a 10-minute mean, but the actual time between any two blocks follows a Poisson distribution: sometimes 30 seconds, sometimes 45 minutes. The estimate Time = Confirmations × Block Time gives the expected value, not the guaranteed wait. For Bitcoin at 6 confirmations, the expected wait is 60 minutes, but the 10th percentile is about 42 minutes and the 90th percentile is about 96 minutes. For critical payments, plan the arrival window around the 90th percentile, not the mean.
More confirmations = exponentially more security
Each additional confirmation makes it exponentially harder to reverse a transaction. Reversing 1 confirmation requires only that a competing miner finds an alternative block at the same height. Reversing 6 requires six consecutive blocks on a competing chain, which for a well-distributed network is prohibitive. This is why exchanges require 6 confirmations for Bitcoin — at that depth, the cost of a double-spend attack exceeds the value of any transaction the exchange will credit. For high-value transfers, 12–30 confirmations are common; for very large ones, 100+ is sometimes required.
Smaller block times don't mean faster finality
A chain with a 12-second block time (Ethereum) sounds much faster than one with a 10-minute block time (Bitcoin), and for 1 confirmation it is — 12 seconds vs. 10 minutes. But finality depends on the depth required, not just the block time. Ethereum exchanges often require 12–64 confirmations, so the total wait is 2.4–12.8 minutes — comparable to Bitcoin's 6-confirmation wait. BNB Chain requires 15 confirmations at 3 seconds each = 45 seconds. Solana reaches finality in about 13 seconds. The right comparison is total time to finality, not block time in isolation.
Confirmations ≠ finality on all chains
Bitcoin and other proof-of-work chains use "probabilistic finality" — a transaction is never 100% irreversible, but the probability of reversal falls exponentially with depth. Proof-of-stake chains with a BFT-style consensus (Ethereum post-Merge, Cosmos, Solana) often have "economic finality" at a specific depth: once a block is finalized, reversing it would require the attacker to lose a very large amount of staked capital, making the attack economically irrational. So on Ethereum the relevant number is not "how many confirmations" but "has the block been finalized by the consensus layer", which typically happens 2 epochs (about 12.8 minutes) after inclusion.
How to Use This Calculator
The confirmation time relation links three quantities: Time, Confirmations, and Block Time. Pick which one you want the tool to solve, then fill in the other two.
1. Choose what to solve for
Pick Time, Confs, or BT from the toggle. The calculator rearranges Time = Confirmations × Block Time automatically for whichever you choose.
2. Use realistic presets
Block time presets cover the major chains: Solana (0.4s), BNB (3s), Ethereum (12s), Dogecoin (60s), Litecoin (150s), Bitcoin (600s). Confirmation presets span 1 to 100 — the standard range from "just included in a block" to "deeply confirmed".
3. Match your venue's requirement
Check what your destination exchange or custodian requires. Bitcoin exchanges typically require 2–6 confirmations for deposits. Ethereum exchanges require 12–64. Solana finality is at 32 slots but most venues credit at 1–2 slots. The confirmation count you enter should match what the receiving venue enforces, not what you feel comfortable with.
4. Read the result and verdict
The result card shows the expected confirmation time in hours/minutes/seconds plus the exact formula with substituted values. A colour-coded verdict classifies the wait from "quick" through "standard" to "extended".
5. Check the block timeline and reference card
The block timeline shows each confirmation as a block, with the target depth highlighted and the time offset for each. The reference card shows typical confirmation times across major chains at their standard deposit depths.
6. Switch to Advanced for depth
Advanced mode adds a sensitivity check showing how the wait responds to changes in each input, plus companion metrics including the 10th/50th/90th percentile wait estimates under Poisson block intervals.
What This Tool Offers
Built around the classic confirmation time relation Time = Confirmations × Block Time, the fundamental link between block depth and wall-clock wait time.
Three-way solving
Solve for expected time, required confirmations, or average block time. The calculator rearranges the formula for whichever variable you choose.
Block timeline visualiser
A horizontal timeline showing each confirmation as a numbered block, with the target depth highlighted and time offsets labelled at each milestone.
Network reference grid
Typical deposit confirmation times across major chains (Bitcoin, Ethereum, Solana, BNB, Litecoin, Dogecoin) at standard exchange thresholds, with total time from broadcast to finality.
Chain presets
One-click presets for the most common block times and confirmation requirements across major networks, spanning 0.4-second Solana to 10-minute Bitcoin.
Time vs. confirmations chart
A linear chart showing how expected wait time scales with confirmation depth at the current block time, with the current position marked.
Poisson percentile estimates
Advanced mode adds approximate 10th/50th/90th percentile wait times, because real block intervals are random and the mean is not the whole story.
Reference Tables & Conversions
A live confirmation time solver, a chain reference lookup, and typical confirmation depths by venue.
Quick confirmation time solver
Confirmation Time Lookup by Chain
Computed from Time = Confirmations × Block Time at each chain's standard exchange deposit threshold.
| Chain | Block time | Standard confs | Expected wait | Notes |
|---|
Typical Confirmation Depths by Venue
Different venues enforce different confirmation thresholds. The stricter the venue, the deeper the required wait — but the harder the transaction is to reverse.
| Chain | Wallet-to-wallet | Exchanges / custodians | High-value / institutional |
|---|---|---|---|
| Bitcoin | 1–2 confs | 3–6 confs | 12–30 confs |
| Ethereum (post-Merge) | 1 conf (~12s) | 12–32 confs | Finalized (~12.8 min) |
| Solana | 1 slot (~0.4s) | 2–32 slots | Finalized (~13s) |
| BNB Chain | 1–3 confs | 15 confs | 30 confs |
| Litecoin | 1–3 confs | 6 confs | 12+ confs |
| Dogecoin | 2 confs | 6 confs | 20+ confs |
| Polygon PoS | 1 conf (~2s) | 64 confs | Checkpoint (~30 min) |
| Arbitrum (L2) | ~15 min (soft) | ~7 days (L1 finality) | ~7 days |
| Optimism (L2) | ~15 min (soft) | ~7 days (L1 finality) | ~7 days |
Block Time Benchmarks
Average block times across major networks. Bitcoin's 10-minute target is the historical baseline; modern chains are dramatically faster.
| Chain | Target block time | Consensus | Notes |
|---|---|---|---|
| Bitcoin | 600 s (10 min) | Proof of Work | Difficulty adjusts every 2,016 blocks to maintain 10-min average |
| Litecoin | 150 s (2.5 min) | Proof of Work | Same design as Bitcoin; smaller target interval |
| Dogecoin | 60 s (1 min) | Proof of Work | Merged-mined with Litecoin |
| Ethereum | 12 s | Proof of Stake | Fixed slot time post-Merge; finality in 2 epochs |
| BNB Chain | 3 s | Proof of Staked Authority | 21 active validators; fast confirmation |
| Solana | ~0.4 s | Proof of History + PoS | Sub-second slots; finality in ~32 slots |
| Avalanche C-Chain | ~2 s | Snowman consensus | Sub-second finality on the primary network |
| Polygon PoS | ~2 s | PoS sidechain | L1 checkpoint every ~30 min |
| Arbitrum (L2) | ~0.25 s (soft) | Optimistic rollup | L1 finality ~7 days via fraud-proof window |
Variable Reference
| Symbol | Meaning | Typical range | Units |
|---|---|---|---|
| Time | Expected confirmation time | 0.4 – 1e7 | seconds |
| Conf | Required confirmations | 1 – 1000 | blocks |
| BT | Average block time | 0.2 – 1200 | seconds |
| σ | Std dev of block interval | = BT (Poisson) | seconds |
| p10 | 10th percentile wait | ~0.7× Time | seconds |
| p90 | 90th percentile wait | ~1.6× Time | seconds |
What Does Est. Time = Confirmations × Block Time Measure?
Confirmation time connects three quantities that every user of a blockchain cares about at the moment of a transaction: the number of blocks that must be mined on top of the block containing the transaction (Confirmations), the average interval between blocks on that chain (Block Time), and the resulting expected wait (Time). It is the standard way to reason about how long a transaction will take to reach any required security depth, from the moment of broadcast to the moment the receiving party releases the funds or credits the deposit.
Confirmation Time Formula
The defining relationship is:
Rearranged to solve for the other two unknowns:
Block Time = Time / Confirmations
From these, additional metrics follow directly:
Time (in hours) = Time / 3600
Time (in days) = Time / 86400
10th percentile wait ≈ Time × 0.70 (Poisson)
90th percentile wait ≈ Time × 1.60 (Poisson)
Confirmation Time Variables
| Symbol | Meaning | Notes |
|---|---|---|
| Time | Expected confirmation time | The mean of the wait-time distribution; not a guarantee |
| Conf | Required confirmations | Set by the receiving venue; varies from 1 to 100+ |
| BT | Average block time | Chain-specific; use a recent moving average not the target |
| p10, p90 | Percentile waits | Real distributions have variance around the mean |
How Each Variable Affects the Interpretation
Time scales linearly with both confirmations and block time, so the arithmetic is trivial. Doubling either doubles the expected wait. This is why Bitcoin's 10-minute block time combined with a 6-confirmation requirement gives 60 minutes, while Solana's 0.4-second slot time combined with its 32-slot finality gives about 13 seconds — a difference of nearly 300×. The formula captures the essential trade-off that every blockchain makes: faster block times mean faster confirmations, but faster block times typically mean higher orphan rates and less security per block, which is why the confirmation depth required to reach the same security level is often higher on fast chains.
The single most important caveat is that the estimate is a statistical mean, not a ceiling. Real block intervals on proof-of-work chains follow an exponential (Poisson) distribution: the wait between any two consecutive blocks is memoryless, meaning the expected wait from "now" is always exactly one block time regardless of how long it has already been since the last block. This produces a wide spread of actual wait times. For Bitcoin at 6 confirmations, the mean wait is 60 minutes, the 10th percentile is about 42 minutes, and the 90th percentile is about 96 minutes. For a payment that must arrive before a specific deadline, plan around the 90th percentile, not the mean, or accept a roughly 10% chance of missing the deadline.
The other caveat is that "confirmations" does not mean the same thing on all chains. On proof-of-work chains, confirmations provide probabilistic finality — each additional block makes reversal exponentially harder, but no depth is ever 100% final in the theoretical sense. On proof-of-stake chains with BFT-style consensus, confirmations are often paired with an explicit "finalization" step: Ethereum finalizes after two epochs (about 12.8 minutes), after which reversal would require an attacker to lose a large fraction of staked capital. For large transfers, the relevant question is not "how many confirmations" but "has the transaction been finalized by the consensus protocol", which can take considerably longer than a naive Time = Confirmations × Block Time estimate suggests.
Confirmation Time Calculation Examples
Time = 6 × 600 = 3,600 s = 1.00 hour
Time = 3 × 600 = 1,800 s = 30 minutes
Time = 12 × 12 = 144 s = 2.4 minutes
Time = 32 × 0.4 = 12.8 s
p90 ≈ 3,600 × 1.60 = 5,760 s = 96 minutes
Confirmations = 3,600 / 600 = 6 blocks
Frequently Asked Questions
It depends entirely on the value of the transaction and the trust assumptions. For small transfers between wallets you control, 1 confirmation is fine — it means the transaction is in a block, and reversing a single block would require a 51% attack that is economically irrational on any major chain. For exchange deposits, the venue sets the threshold: Bitcoin exchanges typically require 2–6 confirmations, Ethereum exchanges 12–64, Solana 2–32 slots. For high-value transfers (say $1M+), exchange thresholds rise to 12–30 confirmations on Bitcoin. The intuition is straightforward: each additional confirmation makes reversal exponentially harder, so the depth required scales with the amount at stake divided by the cost of an attack.
Because block intervals are random. Bitcoin's protocol targets a 10-minute average, but the actual time between any two blocks is drawn from an exponential distribution: sometimes 30 seconds, sometimes 45 minutes, occasionally over an hour. The formula Time = Confirmations × Block Time gives the mean of the wait distribution, not the upper bound. For Bitcoin at 6 confirmations, the mean is 60 minutes, but about 10% of the time the wait exceeds 96 minutes and about 1% of the time it exceeds 2 hours. If you are timing a payment for a deadline, plan around the 90th percentile — roughly 1.6× the mean under the Poisson assumption — rather than the mean itself.
Safe from what depends on your threat model. 1 confirmation means the transaction is included in a block that has been broadcast and accepted by the network — you can see it, and it is almost certainly going to be part of the canonical chain. The only way to reverse it is a "reorg", where a competing miner produces an alternative chain from the same block height with more accumulated work. On Bitcoin and other major chains, single-block reorgs happen naturally a few times a month (two miners solve a block at nearly the same time, and the network converges on one). For most purposes, waiting 1 confirmation is enough. But if you are receiving a payment and dispatching goods or services based on it, 2–3 confirmations is safer because it protects against the natural reorgs that occasionally occur. Major exchanges require 3–6 for this reason.
Ethereum's post-Merge consensus (Gasper) has two phases. The first is "justification", which happens when a block is voted on by two-thirds of the staked ETH and its parent has been justified. The second is "finalization", which happens when a justified block is itself voted on by two-thirds of stakers — typically two epochs (about 12.8 minutes) after the block was included. Once a block is finalized, reversing it would require the attacker to lose at least one-third of the total staked ETH, which on current numbers is tens of billions of dollars. This is called "economic finality". For most practical purposes, exchanges treat Ethereum deposits as final after the 32-slot finalization window, even though they may credit the balance earlier. The formula Time = Confirmations × Block Time still applies, but the meaningful "confirmations" number is the finalization depth, not the number of slots.
Because L2s (Arbitrum, Optimism, Base) achieve their security by posting data and state commitments to L1 (Ethereum), and L1 has its own finality window. On an optimistic rollup, transactions appear confirmed on the L2 within seconds because the sequencer is producing blocks fast. But the L2's state is only provably correct on L1 after the fraud-proof window closes — typically 7 days for optimistic rollups. Until then, the L2 state is "soft confirmed" and could in principle be challenged. Venues that handle large amounts or that need to move funds to L1 wait out the full window, so an L2-to-L1 withdrawal can take a week. Smaller venues and wallet-to-wallet transfers treat the soft confirmation as sufficient, which is why L2 user experience is fast for everyday use but slow for final settlement.
A reorg (reorganization) happens when the network switches to a different chain than the one containing a particular block. Two miners might solve a block at nearly the same time, producing a temporary fork. The network eventually converges on the longer chain, and the shorter one is discarded — along with any transactions that were only in the discarded chain. Those transactions return to the mempool and are re-included in a future block. Reorgs of 1–2 blocks happen naturally on Bitcoin every few weeks. Reorgs of 3+ blocks are rare, and reorgs of 6+ blocks essentially never happen on a major chain except in a deliberate attack. This is why confirmation depth matters: 6 confirmations means you would need a reorg of 6 blocks to reverse your transaction, and that has never happened on Bitcoin under normal conditions. For higher-value transfers, exchanges require deeper confirmations specifically to make a hypothetical attack prohibitively expensive.
For Poisson-distributed block intervals, the mean is the natural estimate because the underlying process has an exponential distribution whose mean is the block time. The expected wait for N confirmations is exactly N × block time. But the median wait for N confirmations is slightly less than the mean: because the distribution is right-skewed, half the actual waits will be shorter than the mean and half longer, with the median sitting a bit below the mean. For N large enough, the median of an Erlang-N distribution approaches the mean. For Bitcoin at 6 confirmations, the mean is 60 minutes and the median is about 56 minutes. The practical difference is small, which is why practitioners usually just use the mean and quote the 90th percentile separately when they need an upper bound.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| Est. Time | Estimated confirmation time | minutes |
| Confirmations Needed | Number of confirmations required | |
| Average Block Time | Blockchain's average block time | minutes |
What it means
Confirmation time is the time required for a transaction to be included in a certain number of blocks. It is estimated by multiplying the number of confirmations by the average block time. This is used by users to decide on transaction urgency and fees. A higher fee increases the priority of being included. Understanding this helps users avoid overpaying or underpaying fees and to plan transactions accordingly. It is a key concept in blockchain usability.
Worked example
Transaction Confirmation Time – Two Detailed Examples
Real‑World| Parameter | Value |
|---|---|
| Confirmations Needed | 6 |
| Avg Block Time | 10 minutes |
| Parameter | Value |
|---|---|
| Confirmations | 12 |
| Block Time | 2 seconds |
Common mistakes
- Confirmations needed: The number of confirmations required for finality (e.g., 6 for BTC).
- Average block time: The typical time between blocks.
- Estimate: Does not account for network congestion or variable block times.
- Assumes constant block time: Actual times can vary widely.
Applications
Transaction confirmation time estimate multiplies the required confirmations by the average block time, giving an approximate waiting time. This is used by users and merchants to estimate when a transaction will be finalised. By knowing the confirmation time, they can plan their activities and assess the risk of double‑spending. Exchanges and payment processors use this to set deposit confirmation requirements. Understanding this estimate is crucial for practical use of cryptocurrencies.
- Estimating waiting time for transaction finality
- Setting appropriate confirmation requirements for merchants
- Managing user expectations on exchanges
- Risk assessment for accepting unconfirmed transactions
- Educational understanding of blockchain confirmations
Related calculators · Mining & Blockchain
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.