When a transaction appears in a block, it has been included. Whether it has been settled is a separate question, and the answer differs by chain in ways that matter for anyone moving value.
Probabilistic settlement
On chains that use proof of work, no single block is final in an absolute sense. It is possible in principle for a competing chain to emerge and displace recent blocks. What makes this impractical is cost: each additional block built on top increases the work an attacker would have to redo.
So finality here is economic rather than mathematical. A transaction becomes safe not because the protocol declares it so, but because reversing it would cost more than it could plausibly be worth. This is why services wait for several confirmations, and why the appropriate number depends on the value at stake rather than being a universal constant.
Explicit finality
Other designs make finality a stated property. Validators vote, and once a sufficient supermajority has committed, the block is final by rule — reversing it would require those validators to contradict themselves in a way the protocol can detect and penalise.
The guarantee here is different in kind. It is not “this would be expensive to undo” but “undoing this is a punishable protocol violation”. That is stronger in one sense and narrower in another: it holds as long as the validator set behaves within the assumptions the protocol makes about it. Our guide comparing proof of work and proof of stake covers the underlying mechanisms.
Why confirmation counts do not transfer
A confirmation is one block. Blocks arrive at different intervals on different chains, so a given number of confirmations represents a different amount of elapsed time and a different amount of accumulated cost depending on where you are. Comparing “six confirmations here” with “six confirmations there” is comparing two different quantities that happen to share a name.
This is one of the more common sources of confusion when moving between chains, and it is entirely avoidable once you know to convert to time and cost rather than counting blocks.
The practical version
For small amounts, waiting is mostly a formality. For large ones, the right waiting period is a function of what an attacker would gain versus what an attack would cost — which means it scales with the value being moved. Services that set a single threshold for all amounts are making a simplifying assumption, usually a conservative one.
The general principle is worth carrying: inclusion and settlement are not the same event, and the gap between them is where most of the interesting engineering lives. See what a blockchain is for the foundations, and our methodology page for how we source the chain data shown on this site.