# How do network confirmations work on a payment

What a confirmation is at the network level, why more confirmations mean more certainty, and how many to wait for by amount.

---


## How do network confirmations work on a payment
When a crypto payment leaves one wallet and lands in another, the moment the funds depart is not the moment the payment is final. Between broadcast and finality lies a mechanical process that every professional handling significant sums needs to understand at the technical level — not because you need to run a node, but because the number your counterparty quotes you, the one confirmations deep before they'll call it settled, is built on real physics of how blocks are produced and chained together. This article explains that mechanism from the ground up: what a confirmation actually is at the network level, why counting blocks is a meaningful proxy for certainty, how that math differs across chains, and where the thresholds for different deal sizes come from.

## From broadcast to the mempool: the first stage no one sees

When any transaction is first broadcast to the blockchain it starts with zero confirmations. That statement is simple, but it contains something worth unpacking: broadcast and confirmation are two entirely separate events. The common mistake is treating visibility as settlement. A transaction the whole network can see is not yet a settled transaction.

The mempool is the temporary holding area where unconfirmed blockchain transactions wait before they are added to a block. Think of it as a queue sitting in the short-term memory of every full node on the network. Within a few seconds, the transaction propagates across the global network and enters the mempools of thousands of nodes. It is visible, it is real, but it has no confirmation. Until a miner or validator selects it and includes it in a block, the payment can still be displaced.

The transaction sits in the mempool, competing with every other unconfirmed transaction for block space. Miners and mining pools select transactions from their mempool to construct candidate blocks. The selection process is driven primarily by one metric: fee rate. Transactions offering higher sat/vB rates are selected first because they maximize the miner's revenue per unit of block space consumed.

This is why, on a congested Bitcoin network, a low-fee transaction can sit for hours. It is not lost. The default mempool expiry time in Bitcoin is set to 2 weeks (14 days), meaning that if a transaction remains unconfirmed for 14 days, it will be automatically removed from the mempool. But in practice, most transactions either confirm quickly or become stranded and eventually dropped during congestion. The professional takeaway at this stage is straightforward: seeing a transaction in an explorer is the beginning of the confirmation process, not the end of it.

## What a confirmation actually is at the block level

A blockchain confirmation is a representation of a new block being accepted by a blockchain network. More precisely, a confirmation is a count — the count of how many blocks have been appended to the blockchain starting from (and including) the block that contains your transaction.

The sequence works like this. Validated transactions are grouped together into a block by miners or validators, and that block is then added to the blockchain, making the transaction final and immutable. At that exact moment, when a miner finds a valid block containing your transaction and broadcasts it to the network, every node adds it to their copy of the blockchain. At this point the transaction has one confirmation. Each subsequent block mined on top of it adds another confirmation.

The counting is mechanical and automatic. The blockchain confirmation may be a number of blocks added to the blockchain after the block that includes the transaction. So a transaction with six confirmations sits inside a block that has five more blocks stacked on top of it. Every additional block represents the entire network's continued agreement that the chain history — including your transaction — is the correct one.

## Why the block count maps to certainty: the chain reorg problem

The reason the confirmation count matters is not bureaucratic. It is a direct reflection of the cost required to reverse the transaction. Understanding this requires understanding what a chain reorganization is, because the entire confirmation model exists to defend against it.

A rewrite of history, known as a "reorganization" or "reorg," invalidates the transactions within the affected blocks, returning any transferred funds to their original owners. Such events pose a security risk, as an attacker could use a cryptocurrency transfer to pay for a good or service, then initiate a reorg to reverse the transfer, reclaiming their cryptocurrency while keeping the good or service.

On a proof-of-work network, a reorg happens when an alternate version of the blockchain accumulates more computational work than the canonical chain. According to the original Bitcoin whitepaper authored by Satoshi Nakamoto, the network relies on the longest chain rule. If two miners find a block simultaneously, the chain temporarily forks. The network resolves this by adopting the chain that accumulates the most proof of work. Because of this, a transaction in the most recent block is vulnerable to being reorganized.

This is not a hypothetical edge case. In 2018, Bitcoin Gold suffered a 51% attack where an attacker gained control of the majority of its mining power. The attacker used this control to create an alternate version of the blockchain, allowing them to reverse transactions and double-spend millions of dollars worth of BTG. Exchanges that accepted BTG without waiting for enough confirmations were hit the hardest, losing around $18 million.

The geometry of the attack is precise: while the public network sees the payment, the attacker privately builds another version of recent blocks that leaves that payment out. If the attacker has enough power, this private chain can catch up and overtake the honest chain. Many proof-of-work systems follow the chain with the most accumulated work. If the attacker's chain wins, the network reorganizes to that version of history.

Each additional confirmation makes this progressively more expensive to execute. Each additional block added after a transaction block increases the difficulty and as such reduces the likelihood that the original block will be invalidated. The number of blockchain confirmations associated with a transaction indicates a difficulty of overwriting or reversing the transaction. At six confirmations on Bitcoin, an attacker would need to secretly mine six blocks faster than the entire honest network — a computational mountain that, on Bitcoin's hash rate, is economically irrational. The cost of the attack would exceed any realistic profit from reversing the payment.

This is why confirmation count is the right unit of measure for settlement confidence. It is not an arbitrary threshold. It is a direct expression of work already spent on the chain.

## The block time difference: why Bitcoin and Ethereum feel nothing alike

The number of confirmations needed depends on the blockchain, the asset, transaction value, and the policy of the service receiving the funds. And the single largest variable between chains is block time — the average gap between one block and the next.

Bitcoin's blockchain creates a new block about every 10 minutes through the mining process. This block then verifies and records new transactions and appends them to the Bitcoin blockchain. Six confirmations on Bitcoin therefore takes roughly an hour. That hour is not sloppiness or lag — it is the network continuously proving, every ten minutes, that the canonical chain is the one that includes your transaction.

Ethereum blockchain average confirmation time is about 12 seconds, so one confirmation often takes seconds, and multiple confirmations arrive within minutes. But the count required for equivalently deep security on Ethereum is higher, precisely because the shorter block time means each individual block represents less accumulated work or stake.

Solana has a block time of approximately 400 milliseconds per block, making transactions near-instant. Solana has a finalized state that arrives in only a few seconds under normal conditions. On the XRP Ledger, consensus finalizes transactions in roughly 3–5 seconds in typical conditions. Tron, a frequent settlement rail for stablecoins, has an average block interval of roughly 3 seconds.

The table below gives a grounded working reference:

| Network | Block time | Standard confirmation count | Approximate time to settle |
|---|---|---|---|
| Bitcoin | ~10 min | 6 | ~60 minutes |
| Ethereum | ~12 sec | 12–64 | ~3–13 minutes |
| Litecoin | ~2.5 min | 6 | ~15 minutes |
| Solana | ~400 ms | 1–2 | seconds |
| XRP Ledger | ~3–5 sec | 1 (deterministic) | seconds |
| Tron | ~3 sec | 15–20 | ~1 minute |

These are not arbitrary rules — they reflect each network's consensus model and the practical cost of mounting a reversal attack.

## Proof of work versus proof of stake: how finality differs by consensus model

The mechanism behind confirmation security changes depending on how the network achieves consensus, and this matters when you are choosing which chain to use for a significant disbursement.

Proof of work operates on the principle of probabilistic finality, where transactions gain security incrementally as more blocks are added to the chain. There is no mathematical moment at which the transaction becomes truly irreversible — instead, in probabilistic finality systems, the probability of a transaction being reversed decreases exponentially as more blocks are added on top of it. Six Bitcoin confirmations does not mean zero chance of reversal. It means the chance of reversal is so computationally expensive that no rational actor would attempt it.

Proof-of-stake networks take a different approach. Rather than having miners compete on computational work, proof of stake requires validators to put digital assets at stake in order to contribute to the block production process. This enables a different category of finality guarantee. With Ethereum's current proof-of-stake mechanism (Gasper), the network introduced economic finality — a mathematical guarantee that a block cannot be changed unless at least one-third of the total staked ETH is slashed (destroyed). For a transaction to reach this state, it usually takes two full epochs (roughly 12.8 minutes).

That distinction is significant. On Ethereum, the question shifts from "how much computation would reversal require?" to "how much economic value would reversal require?" Reversing a block on Ethereum would require an attacker to burn billions of dollars in staked assets, making it practically impossible under normal operating conditions. On smaller proof-of-stake networks with less total stake, the denominator is lower and so is the attack cost.

Deterministic networks use Byzantine Fault Tolerant consensus to guarantee immediate settlement, preventing network forks entirely. In a BFT system, a supermajority — usually two-thirds — of validators must explicitly agree on a block before it is created. If the network cannot reach this supermajority, it halts rather than creating a fork. Networks built on BFT consensus do not require you to count confirmations in the same way. The block is finalized or it is not. There is no accumulating probability curve.

Understanding which model a given chain uses is not academic context. It determines whether "one confirmation" on that chain means roughly the same thing as "six confirmations on Bitcoin," or whether it is practically meaningless as a finality signal.

## How confirmation thresholds scale with deal size

The larger the transaction, the more blockchain confirmations are required. This is because the more confirmations there are, the harder the transaction is to reverse. This principle translates into concrete thresholds that serious platforms apply.

Bitcoin transactions typically require 1–6 confirmations to be considered secure. The typical duration of a single transaction ranges from 10 to 60 minutes, based on both network conditions and the exact transaction costs. But for large-value payments, the floor rises. For a transaction of $1 million, it's not uncommon to wait for at least 60 confirmations. At ten minutes per block, that is roughly ten hours of accumulation — because at that deal size, the economic incentive to attempt a double-spend attack justifies requiring proportionally deeper burial in the chain.

On Ethereum, the graduated thresholds reflect the PoS finality schedule. Twelve to 32 confirmations, representing approximately 3 to 7 minutes, is the standard for mid-sized transactions and most decentralized applications, providing a high level of economic security. 64 confirmations, representing approximately 13 minutes, is the point of full finality — once a transaction is 64 blocks deep, it is mathematically permanent, and this is the requirement for high-value institutional transfers.

Different platforms apply these thresholds differently based on their own risk models. Coinbase, for example, requires 35 confirmations for Ethereum, which typically takes around ten minutes. Binance requires 12 confirmations, also processed in under ten minutes, while Kraken needs 20 confirmations, which can take about five minutes. The variance between platforms is not inconsistency — it reflects each platform's balance between speed and the confirmation depth they need to feel comfortable against the specific threat model they have calibrated for.

While more confirmations increase security, they also delay transaction finality. For everyday use cases or smaller transactions, fewer confirmations may suffice, but for high-value transfers, more confirmations provide stronger assurance of validity.

The practical rule of thumb for a professional disbursing or receiving significant funds: know the chain, know the block time, know whether the consensus model is probabilistic or deterministic, and apply a confirmation count proportional to the dollar value in play. A $25,000 stablecoin transfer on Ethereum hitting finality in under two minutes is not the same level of risk exposure as a $5 million Bitcoin transfer settled after three confirmations. The mechanics are the same; the stakes are not.

## What happens if a transaction stalls before confirmation

A transaction that has been broadcast but not yet confirmed is not a settled payment. It is a pending instruction that has not yet been written to the ledger. A transaction with zero confirmations is still pending and hasn't been included in a block. While it may be visible on the network, it hasn't been validated by miners or validators and is not yet considered final.

The rate at which a transaction is confirmed can be affected by several factors: network congestion, where high transaction volume leads to longer confirmation periods as the network becomes overloaded; block size and block time, where different blockchains have varying block sizes and times to mine or validate a block; and transaction fees, where transactions with higher fees are often processed quicker by miners or validators.

If users set fees too low relative to current network conditions, miners deprioritize the transaction. This is one of the leading causes of delayed confirmations. The funds are not gone — they simply have not moved. Bitcoin cannot be lost simply by sitting in the mempool. Your funds aren't lost while a transaction is unconfirmed. But until the transaction has confirmed, neither party should treat the payment as complete.

This is a practical point for anyone routing multi-party disbursements. A payment that is visible but pending does not satisfy the obligation. The obligation is satisfied when the confirmation threshold appropriate to that amount and that chain has been reached.

## Where Shaka fits in the confirmation picture

When a deal closes and Shaka routes the payment, the split happens in a single on-chain transaction — one broadcast, one block inclusion, one confirmation count that all parties track together. The confirmation mechanics described throughout this article apply in full: the transaction enters the mempool, gets included in a block, and accumulates confirmations according to the chain it runs on. What Shaka handles is the routing and the split logic, so that the closing attorney, the broker, the advisor, and any other party receiving proceeds all land in the same confirmation event. The professional still owns the deal; the chain handles the settlement certainty.

## Probabilistic certainty versus practical finality: the right frame for real payments

The deepest point in understanding confirmation mechanics is accepting that on most major chains, finality is not binary. Historically, blockchains relied on probabilistic finality — as more blocks are added, the probability of a transaction being reversed drops toward zero, but never technically reaches it. On Bitcoin, this is still the operating model. The industry standard for Bitcoin is to wait for 6 confirmations (6 blocks). Since a new block is mined approximately every 10 minutes, probabilistic settlement on Bitcoin takes about 60 minutes. At this point, the computational power required to rewrite the blockchain makes reversal practically impossible.

On Ethereum post-merge, the model moves closer to deterministic for large values. As outlined in the Ethereum documentation, "In Ethereum, finality is the guarantee that a set of transactions cannot be reverted without burning at least 33% of the total staked ETH." That is economic finality — not mathematically perfect, but grounded in a penalty so severe that rational actors treat it as absolute.

The professional using crypto payments for real deal disbursements needs to operate in this frame: not "is this confirmed?" as a yes/no question, but "how many confirmations deep is this, on which chain, and does that depth reflect a reversal cost that exceeds any realistic attack incentive given this deal size?" At six Bitcoin confirmations on a $50,000 transfer, the answer is emphatically yes. At one confirmation on an obscure proof-of-work chain for a seven-figure payment, the answer is no, regardless of what any explorer says.

The chain does not lie. It accumulates work, or it accumulates staked economic weight, block by block. Every confirmation added is an additional fact about how much it would cost to erase what happened. At some number of confirmations, that cost is so high relative to the value being protected that the payment is, for every practical professional purpose, done. That threshold is different by chain, by amount, and by consensus model. Knowing how to read it correctly is what separates a professional who understands the infrastructure they are building on from one who takes it on faith.