Confirmations, finality and verifying a payment

What a confirmation is

When a transaction is included in a block, an explorer shows it as having 1 confirmation. Each further block added on top adds one more. A transaction in block 900,000, viewed when the latest block is 900,005, has 6 confirmations: its own block plus five on top.

Confirmations measure how deeply a transaction is buried in the chain, and therefore how hard it would be to undo.

Why the most recent blocks can change

Occasionally two block producers create a valid block at the same height at almost the same time. For a short while, different parts of the network follow different versions of the latest block. The tie is broken when the next block is built on one of them; the network then follows that version, and the other block becomes stale (often called orphaned). Transactions that were only in the stale block go back to the mempool and normally confirm in a later block.

This short-lived switch is called a reorganization, or reorg. On Bitcoin, reorgs of one block happen from time to time; deeper ones are very rare, because each extra block on top would have to be outdone by an attacker controlling a huge share of the network's mining power. That is why Bitcoin's finality is described as probabilistic: a transaction never becomes impossible to reverse, but after a few blocks reversing it becomes extremely expensive and unlikely.

How many confirmations are enough?

There is no single correct number. It depends on the network and on how much is at stake. Common practice on Bitcoin:

Exchanges and payment processors publish their own thresholds for each network, and they can be higher for networks with less security.

An unconfirmed transaction (zero confirmations) is a promise, not a payment. Until it is in a block it can be dropped from the mempool or replaced, for example with RBF, by a version that pays somewhere else. Never treat a pending transaction as received for anything that matters.

Finality on Ethereum

Ethereum's proof of stake adds an explicit step called finality. Time is grouped into epochs of 32 slots (6.4 minutes). Validators vote on checkpoints, and when a checkpoint gets enough votes in two consecutive epochs, it and every block before it become finalized. That takes at least two epochs, so a transaction is usually finalized 13 to 19 minutes after inclusion, often quoted as about 15 minutes.

Reverting a finalized block would require validators controlling at least one third of all staked ETH to break the rules, and the protocol would destroy (slash) their stake. Many explorers show a label such as "Finalized" or "Safe" on blocks and transactions, or a count of confirmations next to a finality marker. For high-value payments on Ethereum, waiting for finality is a sound rule.

Other networks reach finality in their own ways, some in seconds. Check what the explorer shows for that network rather than applying Bitcoin's numbers everywhere.

A checklist for verifying a payment you received

Put together everything from this course and you have a reliable routine. Ask the sender for the transaction ID, then check on a trusted explorer:

1. Right network, right explorer. Use the explorer for the network the payment was sent on, opened from a bookmark or typed address, not from a link the sender gave you.
2. The transaction exists. The TXID opens a real transaction page.
3. Status is success. On Ethereum-style networks, a failed transaction moved nothing.
4. The recipient is exactly your address. Compare the full address, not just the ends. For tokens, look at the Transfer event, not the To field.
5. The asset is the right one. For tokens, the contract address must be the official one for that token on that network.
6. The amount is correct, with decimals applied, and on Bitcoin it is in an output to your address, not in the change.
7. Enough confirmations or finality for the amount involved.
8. Cross-check. For important payments, confirm on a second explorer or in your own wallet or node.

Common tricks, and why the checklist stops them

• Screenshots of a "successful" transaction prove nothing. They can be edited in seconds. A TXID can be checked by anyone, so always ask for it.
• Fake explorer sites imitate real ones and show whatever the scammer wants. Step 1 stops this.
• Fake tokens with the right name land in your wallet. Step 5 stops this.
• Unconfirmed payments that are later replaced. Step 7 stops this.
• Testnet payments that look real but have no value. Check the address prefix and the network.

Recording what you found

Sometimes you need to show others what the chain says, for an accountant, a dispute or a report. Good habits:

• Save the link to the transaction page and note the date and time you checked, with the time zone.
• Record the TXID, the block height, the confirmations at the time and the explorer you used.
• Remember that explorer pages show live data: confirmations will have increased, and labels may change. Your record should say what you saw and when.

Formal evidence handling, chain of custody and expert reporting go further, and they are part of the IDFE Certified Crypto Forensics Specialist program.

Where to go next

You can now read blocks, transactions, fees, addresses, tokens and confirmations on any major explorer and verify a payment on your own. The next step is IDFE-DF, Digital Assets Foundations, which builds on these skills with keys and custody, tokens and DeFi, and the regulatory landscape.

Exam focus: how confirmations are counted (inclusion = 1), stale blocks and reorgs, probabilistic finality on Bitcoin and the common 1/3/6 practice, why zero-confirmation payments are risky, Ethereum finality (epochs of 32 slots, at least two epochs, about 15 minutes, at least one third of staked ETH at stake), the payment-verification checklist, and why screenshots and links from the sender are not proof.