// TECHNOLOGY
Blockchain finality: when is a transaction really done?
6 min readnijitech
“Confirmed” and “irreversible” are not the same thing. For a system accepting payments, that difference is what decides how many seconds you wait.
Full post
The first question asked when building a system that accepts payment on a blockchain is usually: how long does a transaction take to confirm? That is not the right question. The right question is how long it takes to become irreversible.
The gap between the two is the difference between taking payment for a coffee and taking payment for a car.
Confirmation is not finality
A transaction entering a block is a confirmation. But on some chains that block can lose validity if a longer chain appears on the network, and the transactions inside it revert. The first confirmation is therefore not a guarantee but a statement of probability.
As time passes and blocks stack on top, the chance of a reversal shrinks — but in theory it never reaches zero. This is called probabilistic finality: "wait long enough and it is safe enough".
What deterministic finality changes
In some consensus designs a block is final the moment a majority of validators approve it, and cannot be reversed. Waiting serves no purpose here: either the transaction is final or it never happened. The grey zone disappears.
Why this matters so much on the payment side
If you are handing over a physical good or unlocking a service immediately, you have accepted a payment that could reverse. In the traditional card world this is called a chargeback and businesses have managed the risk for years. On chain, the risk depends on the finality model of the network you chose.
Questions for the design
- Is finality on this network deterministic or probabilistic?
- If deterministic, what is the typical time — seconds or minutes?
- If probabilistic, how many confirmations do we wait for at which amount?
- What do we show the user while they wait?
The last item belongs to the product side and is the one most often skipped. A screen reading “processing” that does not tell the user how long they will wait is a poor experience regardless of the actual wait.
Compatibility is a separate axis
The finality model and the development environment are two independent choices. A network can offer fast, deterministic finality and be EVM-compatible at the same time, in which case existing Solidity contracts, wallets and development tools work as they are.
In practice this decouples the architectural decision from the team: you pick the finality model your infrastructure requires, and the team keeps working with the tools it knows.
In short
Three sentences
- Confirmation means "it entered a block"; finality means "it cannot be reversed"
- Under probabilistic finality, the amount decides the waiting time
- Under deterministic finality that decision disappears — the product logic simplifies
Products mentioned in this post
From the glossary: Finality · EVM compatibility