The words are not interchangeable. A confirmation says a block contains your transaction. Finality says no competing block will ever displace it. On some networks those two events are seconds apart. On others they are hours apart, and on a few they never become absolute at all — only expensive to reverse.

• Confirmation is a claim about inclusion, not permanence. A transaction can be included in a block and still be removed if a longer or heavier chain appears.
• Two finality models dominate. Proof-of-work chains use depth and cost; Byzantine-fault-tolerant chains use votes and explicit checkpoints.
• Finality time is a product decision. Exchanges, bridges and merchants each pick a threshold, and those thresholds differ for the same asset.
• Settlement risk is priced, not eliminated. Every credit you extend before finality is a loan against a chain reorganisation.

Why a confirmation is not transaction finality

A confirmation only tells you that one miner or validator found your transaction acceptable at a moment in time. It does not tell you that every other participant agrees, and it certainly does not tell you that no one is currently building a competing branch that excludes you.

Divergence is normal, not an attack

The gap exists because blockchains resolve disagreement by convergence, not by authority. Two nodes can hold different views of the tip of the chain for a short window — during network partitions, during high-latency propagation, or when a miner deliberately withholds a block. The network does not “decide” instantly. It waits for one branch to accumulate enough weight or enough votes that continuing the other branch becomes irrational.

The waiting period is the safety margin

That waiting period is the entire safety margin. A merchant who hands over goods after one confirmation is not using a weaker version of finality; they are using no finality at all, and accepting reorg risk in exchange for speed.

Two models: probabilistic and deterministic finality

Networks settle in one of two ways, and the difference changes what “safe” means in practice.

Proof-of-work: finality by accumulated cost

In proof-of-work systems, finality is probabilistic and economic. Each additional block buried on top of yours raises the cost of rewriting history, because an attacker must redo that work faster than the honest network extends the chain. There is no block height at which reversal becomes impossible — only heights at which it becomes absurdly expensive.

Under the standard model, an adversary holding a fraction q of total hashpower trying to catch up from z blocks behind succeeds with a probability that falls roughly as (q/p)^z, where p is the honest share. At q = 0.10 and z = 6, that is about (0.111)^6, or roughly two in a million. At z = 3 it is roughly 1.7 in a thousand. Same network, same attacker, very different risk — which is why “six confirmations” is a convention, not a law.

Note what the formula assumes: that the attacker cannot rent hashpower faster than the honest network grows, and that the honest majority is genuinely honest. Both assumptions have failed on small chains.

BFT chains: finality by explicit vote

Proof-of-stake networks built on Byzantine-fault-tolerant consensus typically produce deterministic finality. Validators vote on blocks in rounds, and once a supermajority — commonly two-thirds of staked weight — attests to a block, that block is final by protocol rule. Reverting it would require at least one-third of stake to be slashed, which is a measurable, attributable penalty rather than a probabilistic one.

The trade-off is that deterministic finality usually takes two rounds of communication, so it arrives in a fixed number of seconds and fails in a fixed way: if too many validators go offline, the chain stops producing finality rather than producing a wrong answer. Liveness breaks before safety does. That is a deliberate design choice, and it means “the chain is halted” is a normal failure mode on these networks, not an exotic one.

What finality costs, and where it breaks

Finality is a latency tax paid for settlement assurance, and every system that offers fast finality is buying it with something else — capital, trust assumptions, or a smaller validator set.

The last row is the one people skip. When a deposit shows as credited in seconds, that is custodial credit, not transaction finality. The venue is lending you its balance sheet until the underlying chain catches up. That is normally fine and occasionally catastrophic.

A transaction is settled when reversing it costs more than the transaction is worth — and that threshold is set by the value at stake, not by the number of blocks on screen.

How to reason about transaction finality in practice

Treat finality as a number you look up per chain and per amount, not a habit you apply uniformly.

1. Identify the settlement layer. The chain your counterparty credits is rarely the chain that settles; bridges and rollups add their own delays on top.
2. Find the venue’s stated confirmation or finality policy. Exchanges publish deposit thresholds, and they usually differ by asset.
3. Compare that threshold to the value at risk. A ten-dollar payment and a six-figure transfer should not use the same rule.
4. Check whether the chain exposes an explicit finality signal — a finalized checkpoint, a justified epoch, a BFT round number — and use that rather than raw block depth.
5. For cross-chain transfers, count the bridge’s challenge or withdrawal window as part of the wait, not as an afterthought.
6. Log the timestamp of actual finality for each large transfer, so you can price your own operational risk instead of guessing.

The arithmetic that matters is simple: expected loss equals the probability of reversal times the value exposed. If a 0.2 percent reversal probability sits on a $50,000 settlement, the expected cost is $100. Waiting twenty more minutes is almost always cheaper than that.

The post Finality: When a Transaction Is Actually Settled appeared first on FogChain.