How to check confirmations, and how many you actually need

What a confirmation actually represents

When your transaction is included in a block, it has one confirmation. When another block is produced on top of that one, it has two, and so on.

The reason this matters is reversibility. On a proof-of-work chain, rewriting history means redoing the work of every block since the point you want to change, faster than the rest of the network is adding new ones. With one confirmation that is expensive. With six it is prohibitively so, and with a hundred it is fantasy.

So a confirmation count is not a status. It is a measure of how much it would cost someone to undo what you are looking at, expressed in a unit that only makes sense relative to the chain producing it.

This is why the same number means different things. Six Bitcoin confirmations represents roughly an hour of the largest proof-of-work network on earth. Six Dogecoin confirmations represents six minutes on a chain secured by merge mining. Six confirmations on a chain producing blocks every two seconds represents twelve seconds of something considerably smaller.

Quoting "six confirmations" as a universal standard is therefore not a useful rule. It is a Bitcoin convention that escaped.

What the equivalent question is on each chain

Not every chain even uses confirmation counts, which is the part most guides skip.

On Ethereum since the Merge, finality is explicit. Blocks become justified and then finalised through the consensus layer, and a finalised block cannot be reverted without an enormous economic penalty to the validators involved. That takes roughly two epochs, around thirteen minutes. Confirmation counts still get quoted, but finality is the more meaningful concept.

On Solana the language is commitment levels: processed, confirmed, and finalized. Services express their thresholds in those terms rather than as a number of blocks.

On the XRP Ledger there are no forks in the ordinary sense — a ledger either closes with agreement or does not close — so one validated ledger is generally sufficient.

On rollups such as Base there are two separate questions. The sequencer confirms in about two seconds; settlement on Ethereum happens later, and for an optimistic rollup full finality waits for a challenge window measured in days. Both states display as "confirmed" and only the L1 batch field distinguishes them.

The general lesson is to ask what the chain's own finality model is rather than counting blocks by reflex.

The only threshold that actually governs you

Here is the practical point that renders most of the above academic for everyday purposes.

When you deposit to an exchange, the number of confirmations that determines when your balance appears is the number that exchange requires. Not six, not what an explorer displays, not what a forum post says. Theirs.

Those thresholds vary considerably between services and between assets at the same service, and they are published — usually in the deposit screen or a support article. They also change: an exchange may raise its requirement during a period of concern about a particular chain.

So the correct sequence when a deposit has not arrived is: check the explorer to confirm the transaction is confirmed and count the confirmations; find the service's published requirement; compare. If you are above their threshold and the balance has not appeared, that is a support issue rather than a blockchain issue, and you now have the evidence to say so precisely.

That last part is worth emphasising. Arriving at support with "it says confirmed on the explorer and your published requirement is twelve, I have thirty" produces a considerably better conversation than "it has not arrived".

When the count is stuck at zero

A confirmation count of zero means something different from a low count, and it is worth separating.

Zero means the transaction has been broadcast and is sitting in the mempool, valid but not yet included in any block. On Bitcoin this is almost always a fee problem: your fee rate is below what is currently clearing, and you will wait until either demand falls or you take action.

The worse case is that your transaction does not appear on any explorer at all. That usually means it never propagated — often because the fee was below the network's relay minimum, in which case nodes simply decline to pass it along. The transaction exists on your device and nowhere else, which looks identical to a stuck transaction and is a completely different problem with a completely different fix.

Distinguishing them takes one check: look the transaction up on an explorer you have not used yet. If two independent explorers both show nothing, it did not propagate.

Our guide on unconfirmed transactions covers what to do in each case, including the situations where waiting is genuinely the right answer.

Practical advice, by amount

How much certainty you need depends on what is at stake, and it is reasonable to scale accordingly rather than applying one rule to everything.

For a small everyday payment, a single confirmation is fine on any established chain, and on many of them zero confirmations is fine too provided the transaction does not signal replace-by-fee. Coffee shops accepting Bitcoin over Lightning are not waiting for blocks at all.

For a meaningful sum — enough that losing it would matter — wait for whatever the receiving party requires and do not attempt to argue them down. Their threshold reflects their risk, not yours.

For a genuinely large sum, wait for more than anyone asked, and consider that on a rollup "confirmed" and "settled on Ethereum" are days apart. If irreversibility is the property you actually need, make sure you are reading the field that measures it.

And in every case, verify on an explorer rather than trusting a screenshot. A screenshot of a transaction proves nothing whatsoever, because it can be fabricated in a text editor in under a minute. Our guide on fake explorers covers how far that goes.

What confirmations are actually protecting you from

It is worth understanding the failure mode confirmations exist to guard against, because it makes the advice make sense rather than feel arbitrary.

On a proof-of-work chain, two miners can find valid blocks at nearly the same moment. Both propagate, different parts of the network see different ones first, and briefly there are two competing versions of recent history. The network resolves this by following whichever chain accumulates more work, and the losing block is orphaned.

Transactions in the orphaned block are not destroyed — they usually return to the mempool and get included in a later block. But for a few minutes, an explorer may have shown them as confirmed in a block that no longer exists.

That is the ordinary, accidental version and it is rare and shallow. The version confirmations really defend against is the deliberate one: someone with substantial mining capacity producing a competing chain in order to reverse a payment they made. Each additional confirmation multiplies the cost of that attack, which is why the number matters and why "more for larger amounts" is the right instinct rather than superstition.

It also explains why the equivalent advice differs so much by chain. A chain with a small mining ecosystem is cheaper to attack per confirmation. A proof-of-stake chain with explicit finality replaces the probability with an economic penalty. A rollup inherits Ethereum's security only once its batch has settled there. In each case the question is the same — what would it cost to undo this — and only the answer changes.

Our guide on how explorers work covers reorganisations in more detail, including why an explorer can briefly show you something that stops being true.