The Transaction Is Already Confirmed—Why Can’t We Call It Absolutely Safe?

When a transaction is broadcast and, after a while, the block explorer shows “confirmed,” many people relax at this point: the money should have arrived, and it can’t change anymore, right?

This intuition is common, but it is not entirely accurate. On a blockchain, “confirmed” and “permanently irreversible” are two different things. A transaction showing Confirmed only means that it has entered a certain block, and that block itself may still be discarded by the network. To understand why, we first need to clarify what “confirmation” actually confirms, and under what circumstances a blockchain can “take something back.”

Confirmed Does Not Equal a Final Result

What Confirmation Actually Means

When you see a transaction marked “confirmed” in a wallet or block explorer, it usually means that the transaction has been packaged into a block by a miner or validator. If another new block later connects after that block, the transaction gains more “confirmations.”

For example, if a transaction is included in block N, then when block N+1 appears on the chain, the transaction has about 2 confirmations; when block N+6 appears, it has about 6 confirmations. The confirmation count essentially indicates how many blocks deep the transaction is buried.

Why “Confirmed” Easily Makes People Think It Is Safe

The problem is that “confirmed” describes the chain state currently seen by a local node, not a fact that will remain unchanged forever across the whole network.

The chain a node sees is the chain it currently considers correct. If another chain later becomes more advantageous, the node will switch to the new chain, some blocks on the original chain may be discarded, and the transactions in those blocks will return to an unconfirmed state.

So Confirmed only means the transaction has made it on-chain; it does not mean it has been nailed down. A transaction entering a block and a transaction becoming irreversible are judgments at two different stages.

Why a Blockchain Can “Take Something Back”: Forks and Reorganizations

How Forks Arise

A blockchain is made of blocks connected by hash pointers, and each block records the fingerprint of the previous block. Under normal circumstances, the chain keeps extending forward.

But the network is distributed, and different nodes are not synchronized at every moment. Suppose two miners produce valid new blocks almost simultaneously. After they broadcast them to the network, some nodes see block A first, while others see block B first. At this point, the chain temporarily splits into two branches.

This does not mean two “official versions” have appeared; rather, the network has briefly disagreed about which is the latest chain.

How the Network Chooses the Main Chain

After a while, the network will choose one of the branches to continue extending according to the consensus rules. In a proof-of-work chain such as Bitcoin, consensus usually forms around the chain with the greatest cumulative work (which can be roughly understood as the longest chain).

When most of the hash rate continues producing blocks on one branch, the other branch will gradually be eliminated. Nodes will switch to the more advantageous chain and discard blocks on the original chain. This process is called reorganization.

If the block that originally contained a transaction is reorganized out, the transaction will return to an unconfirmed state, and it may even be replaced if another of two competing transactions gets confirmed. Thus, a transaction that originally showed “confirmed” may disappear or change.

Reorganization Depth and Risk

Reorganization can be understood as “how many blocks are rolled back.” If only 1 block is rolled back, the impact is relatively small; if 10 blocks are rolled back, it means all transactions in the past ten blocks are affected.

The deeper the reorganization, the more confirmed work must be overturned, and the lower the probability of occurrence. This is exactly the significance of “waiting for more confirmations,” which will be discussed later. But one misunderstanding should be avoided here: a low probability does not mean zero probability.

A rough analogy can help: a blockchain is like a ledger jointly maintained by many people, and everyone can continue writing on their own copy; in the end, the network only recognizes the ledger that has been continued by the most people and has accumulated the most work, and records in other versions will be discarded. This analogy illustrates the basic logic of forks and reorganizations, but it does not cover protocol-level finality guarantees, nor the specific economic incentives of miners or validators. Real blockchain mechanisms are more nuanced than this.

Finality: From Confirmed to Irreversible

Definition of Finality

Finality refers to a transaction reaching an irreversible state: under the protocol or economic mechanism, it is almost impossible for it to be rolled back.

Finality is not concerned with “whether the transaction has entered a block,” but with “whether the transaction can still be revoked.” Only when Finality is reached, or when enough confirmations are reached, can a transaction be regarded as truly safe.

Relationship Between Confirmed and Finality

Confirmed is an intermediate state, while Finality is a target state. Their relationship can be understood as follows:

  • Confirmed: the transaction has entered a certain block and has been accepted by the current chain.
  • Finality: the transaction can no longer be, or is extremely unlikely to be, revoked.

Between Confirmed and Finality, there is a time window. Within this window, although the transaction shows as confirmed, it may still be rolled back due to forks and reorganizations.

This is also why “confirmed” cannot be directly equated with “safe”—it is only a stage on the road to safety, not the destination.

Why Finality Is Needed

If all transactions were only “confirmed” and never “final,” the recipient could never fully determine whether the money has truly arrived. Finality provides a criterion: once this state is reached, the recipient can reasonably consider the transaction irrevocable and therefore confidently deliver goods, release withdrawals, or confirm settlement.

Two Kinds of Finality: Probabilistic and Deterministic

Different blockchains implement Finality in different ways, which can be broadly divided into two categories.

Probabilistic Finality

A typical example of probabilistic Finality is a proof-of-work (PoW) chain such as Bitcoin. Such chains do not explicitly declare in the protocol that “this block is already final”; instead, as blocks continue to stack, the difficulty and cost of rolling back a transaction become higher and higher.

To roll back a transaction buried deep enough, an attacker needs to redo a large amount of computational work, and the cost rises rapidly with block depth; therefore, the greater the depth, the lower the probability of reversal and the higher the security. But strictly speaking, it can never drop to absolute zero.

Deterministic Finality

A typical example of deterministic Finality is a chain that uses BFT-style consensus or a Finality gadget. Such systems explicitly mark certain blocks as final at the protocol level, and once this state is reached, they will not be rolled back under normal protocol operation.

Take Ethereum as an example. After the Merge, it uses Casper FFG as its finality tool: validators vote by epoch, and after about two epochs, a block is marked as finalized. According to the protocol design, a block that reaches finalized cannot be normally reorganized. It should be noted that about two epochs, roughly 12.8 minutes, is the protocol’s typical target time; actual parameters may be adjusted with network conditions, and exceptions still exist in extreme cases.

It should be emphasized that the mechanism of Finality is closely related to the consensus mechanism. PoW chains usually have only probabilistic Finality, while chains based on BFT or a Finality gadget usually provide deterministic Finality. This is not a difference in implementation details, but a fundamental difference in “where security comes from”: the former relies on economic cost, while the latter relies on the protocol’s voting guarantee.

Block Time Is Not the Same as Finality Time

There is an easily confused point here: a short block time does not mean a transaction reaches Finality faster.

Block time only determines the speed at which blocks are produced. The time to Finality also depends on how many confirmations are needed, or how many consensus stages must be passed. Some chains produce blocks quickly but need many confirmations to be considered safe; some chains produce blocks somewhat slowly but can reach deterministic Finality after a fixed number of stages. Therefore, to judge how quickly a transaction becomes safe, you cannot look only at block time.

How to Judge Safety in Practice, and Common Misunderstandings

Different Chains Have Different Waiting Standards

Because Finality mechanisms differ, different blockchains also have different “safe waiting standards.”

On Bitcoin, the long-standing community convention is to wait for 6 confirmations as a relatively safe reference for large transactions. The number 6 is not a protocol rule but an empirical threshold: it means an attacker would have to pay a very high cost to roll back the transaction, but it does not mean it is absolutely impossible. Small payment scenarios sometimes accept 1 to 2 confirmations, while large transfers or exchange deposits may require more.

On Ethereum, you can wait for the block to be marked as finalized. If a wallet or explorer shows a finalized status, it means the transaction has reached protocol-level finality.

Different services and exchanges have non-uniform requirements for confirmation counts, depending on their respective risk tolerance and business scenarios.

Common Misunderstanding 1: Confirmed Means Unchangeable

This is the most common misunderstanding. Confirmed only means the transaction has entered a certain block, and that block may still be discarded by a reorganization. Only when Finality is reached, or when the confirmation depth is deep enough, is the transaction extremely difficult to reverse. “Confirmed” is a process, while “irreversible” is a result; the two cannot be equated.

Common Misunderstanding 2: All Chains Have the Same Finality Mechanism

This is not the case. Different consensus mechanisms produce different forms of Finality: PoW chains usually have only probabilistic Finality, while many PoS chains or BFT-style chains provide deterministic Finality. Therefore, directly applying one chain’s confirmation experience to another chain may underestimate or overestimate risk.

Common Misunderstanding 3: Reaching Finality Means Absolute Safety

Finality provides a very strong guarantee, but it is still not “absolute” on a cosmic level. In extreme cases, such as serious protocol vulnerabilities, governance-level social forks, or large-scale consensus failure, the original Finality assumptions may still be broken. Probabilistic Finality, in particular, can never reach 100%. Understanding Finality means understanding “extremely difficult to reverse under normal assumptions,” not “absolutely impossible in all possible worlds.”

Common Misunderstanding 4: Short Block Time Means Fast Finality

As mentioned earlier, block time only determines the speed of block production. The speed of Finality also depends on the number of confirmations and consensus stages, and the two are not always positively correlated. To evaluate when a transaction is safe, you need to look at the specific Finality rules of that chain, not just its block production speed.

Bringing the Mental Model Together

Back to the initial question: why can’t a transaction showing Confirmed be considered absolutely safe?

Because Confirmed only means the transaction is included in a block seen by the current node, and that block may still be discarded due to forks and reorganizations. To judge whether a transaction is truly safe, you need to see whether it has reached Finality, or whether the confirmation depth is deep enough.

Different chains implement Finality in different ways: PoW chains such as Bitcoin rely on block depth to keep reducing the probability of reversal, but they always retain a tiny possibility; chains with a Finality gadget, such as Ethereum, mark blocks as finalized after the protocol conditions are met, and under normal circumstances they cannot be rolled back. Neither can provide a zero-risk absolute guarantee in “all possible worlds.”

So a more accurate way to judge is: first confirm which Finality mechanism the transaction’s chain uses, then combine that chain’s recommended confirmation count or finality status to assess the risk of the transaction. Confirmed is a stop on the road to safety, not the destination.

No posts found.
Scroll to Top
This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.