How long until a payment is safe
Waiting is what makes a payment safe, not the block count. Drag to change how strong the attacker is, and watch how long each chain needs.
A reorg is not a paperwork problem. If the block carrying your payment gets replaced, the payment can vanish and the attacker can spend the same coins again somewhere else. That double-spend is what this whole wait protects against.
Safe here means the attacker has lost the race to out-mine the payment: a probability that falls the longer you wait, and that depends on how much hash power the attacker has, which is what the chart below shows. Finality is a different kind of guarantee, not a point on that curve. Past 432,000 blocks, 12 hours at Kaspa's 10 blocks per second, a node refuses to reorganize at all, regardless of the attacker's share. The two thresholds differ in kind, not just in degree: the curve below is a race an attacker can still enter with enough hash power, while the 12-hour rule is a wall the protocol will not move past no matter how much hash power shows up.
Three chains, same three this site compares everywhere: Bitcoin and Litecoin as classic single-chain proof of work at different speeds, Kaspa as the fast blockDAG this site explains.
The model, and where the Kaspa line is an approximation
Model. This is the "double-spend race" from Satoshi Nakamoto's Bitcoin whitepaper, section 11 (2008). An attacker holding a share of the network's mining power races to out-produce the blocks already confirming a payment. The whitepaper models that race as a Poisson process and asks: what is the chance the attacker still catches up after z blocks.
Block count is converted to wait time using each chain's target block interval (Bitcoin 600 s, Litecoin 150 s, Kaspa 0.1 s), which is why Bitcoin's line visibly steps every ten minutes while Kaspa's looks smooth.
Where the Kaspa line is an approximation. Kaspa is not a single chain. GHOSTDAG keeps parallel blocks instead of discarding them and orders them by accumulated work across a DAG, not a simple block count. Feeding Kaspa's block interval into this single-chain formula is a stand-in, not a derivation from GHOSTDAG's own security proof. It likely understates Kaspa's real security, since a naive fast chain would waste a lot of honest work to collisions that GHOSTDAG does not waste. It may also understate how GHOSTDAG's bounded tolerance for parallel blocks affects very recent ordering. Net effect not established with confidence either way.
Finality is a different, harder guarantee, not shown here. This site's chain comparer puts Kaspa's finality boundary at 12 hours: a fixed rule past which a node will not reorganize at all, no matter the attacker's share. It sits far to the right of anything on this chart.
Is 12 hours arbitrary? It is a chosen constant, not one derived from a security proof the way GHOSTDAG's own k parameter is. In rusty-kaspa's consensus code, FINALITY_DURATION is a plain 43,200-second (12-hour) constant, and the block-count threshold is just that duration times blocks per second: 432,000 blocks at 10 BPS. Compare that to GHOSTDAG's k, which the same codebase computes from a target probability bound through a named function, calculate_ghostdag_k. Finality duration has no equivalent formula behind it in the source. It is a judgment call about how much margin is enough, held fixed in wall-clock time even as Kaspa's blocks per second have changed, and picked to sit well past the point where the curve above has already fallen close to zero for any attacker share worth trying. This site does not dress that up as derived math: it is a number someone chose.