Confirmations & Finality
Notes on transaction confirmations on Kaspa's blockDAG and the point at which a transaction becomes final.Acceptance
On a blockchain, a transaction counts once it is in a block on the main chain. On Kaspaâs blockDAG, a transactionâs containing block can be anywhere in the DAG - including in a red block. So Kaspa uses a different milestone: acceptance.
A transaction is accepted when it is merged into the Virtual Selected Parent Chain (VSPC) by a chain block. That chain block is the transactionâs accepting block. At 10 blocks per second, acceptance typically happens within about a second of block inclusion.
Confirmation count
Confirmations accumulate on top of the accepting block:
confirmations = sink blue score - accepting block blue scoreWhere sink is the current end of the chain backbone and blue score counts blue blocks. At 10 BPS, confirmation count grows at roughly 10 per second.
Probabilistic finality
Like all PoW networks, Kaspa has probabilistic finality: every block mined on top of a transaction makes reverting it exponentially harder. The probability of a reorg never reaches exactly zero, but becomes negligible quickly. Kaspaâs blocks arrive 600Ă faster than Bitcoinâs, so equivalent confirmation counts are reached in seconds rather than hours.
How many confirmations are âenoughâ depends on the value at stake - wallets typically treat transactions as settled within seconds, while services handling large values wait longer.
Deterministic finality
Kaspa additionally enforces deterministic finality via the finality depth, currently ~12 hours (432,000 blocks). Blocks deeper than the finality depth cannot be reorged - nodes reject any competing chain that attempts to rewrite history past that point.
Deterministic finality exists primarily to make pruning safe: nodes can only discard old block data if that history is guaranteed to never change.