Igra Finality Explained

This page covers the security model behind Igra's finality guarantees. For practical integration guidance, see Ethereum Compatibility.

Probabilistic Finality in PoW

Unlike Ethereum's deterministic PoS finality, the finality in PoW is probabilistic: the probability that an attacker with α < 1/2 of the global hashrate reverts a block with C confirmations is asymptotically:

$$\left(\frac{\alpha}{1-\alpha}\right)^C$$

In PoW, we can only compute the required number of confirmations C relative to a maximal possible adversarial hashrate fraction α<1/2, and a revert tolerance. For example, Bitcoin's famous "six block rule" was chosen to guarantee 99% confidence against a 30% attacker (though it also guarantees 70% confidence against a 45% attacker).

After 12 hours, Kaspa's finality protocol kicks in and provides deterministic finality.

Confirmation Thresholds

Against a 45% attacker we have:

Confs	Revert Probability	Comparable To
100 (~10 sec)	0.0000002%	Negligible
300 (~30 sec)	Lower than ECDSA cracked in 1 hour	Very safe
4800 (~8 mins)	Lower than guessing a private key on first try	Extremely safe
Half a million (~12 hours)	Formal finality (pruning window)	Protocol-guaranteed

Using Time Instead of Counting Confirmations

The expected time it takes to accumulate C confirmations is about C block delays, which suggests waiting C block delays since first inclusion instead of counting confirmations. This approach simplifies logic, and makes confirmation times more predictable, but is only viable for sufficiently large C.

There are two reasons it breaks down for smaller values of C.

The first reason is inherent to all PoW protocols: the inherent noise of block production. The expected time it takes to create C blocks is C block delay, but the standard deviation from that time is √C block delays. This means that the probability of a deviation of, say, 10%, vanishes for large values of C, but could be meaningful even for not-so-small values of C.

For example, a 99% confidence that at least 100 blocks were created requires waiting 125 block delays, which is a 25% safety margin. For 99% confidence that at least 300 blocks were created its enough to wait 340 block delays, which is a 13% safety margin.

Another consideration, that is unique to high BPS systems, is that not all blocks created after the confirming block will become confirmations, some of them will be parallel. The expected number of parallel blocks is constant (up to an exponentially decaying deviation), making this effect negligible in scales beyond several seconds. However, applications that seek ultra-quick confirmations should consider it.

Wait Time Formulas

To account for both, we recommend the following to applications that fix a waiting time for C confirmations instead of counting confirmations directly:

Confirmations	Wait Time
C < 150	C × λ × 1.5 + 1 seconds
150 ≤ C < 300	C × λ × 1.25 + 1 seconds
300 ≤ C < 1800	C × λ × 1.1 seconds
1800 ≤ C < 36000	C × λ × 1.05 seconds

For example, in Kaspa we have λ = 0.1, so for C=50 we recommend setting a confirmation time of 8.5 seconds.

We stress that all waiting intervals above are since first inclusion and do not account for the time the transaction spends in the mempool.

Recommendations by Use Case

Use Case	Recommended Confs	Recommended Wait
Low-value transfers	50	8.5 seconds
DEX swaps, DeFi	300	33 seconds
High-value transfers	2000	4 minutes
Exchange deposits	4000 (or use finalized block tag)	8 minutes
Formal compliance	--	12 hours

The finalized block tag in RPC returns blocks older than the 12-hour pruning window.