Pruning | Kaspalytics

Why prune

Kaspa produces 10 blocks per second - roughly 864,000 blocks per day, about as many blocks as Bitcoin has produced in its entire history. Storing every block forever would push node storage requirements up quickly, centralizing the network around those who could afford to run one.

Kaspa nodes therefore discard old block data by default. A Kaspa node retains block data for approximately 30 hours (the pruning depth is 1,080,000 blocks). Everything older is pruned.

What is pruned, what is kept

The block at which all earlier data is discarded is the pruning point.

Pruned: full block data - transactions and block bodies older than the pruning point.
Kept: the complete UTXO set. This is all a node needs to validate new transactions - whether a coin is spendable depends only on the current UTXO set, not the history that produced it (covered in UTXO Model).
Kept: headers and cryptographic data (the pruning proof) sufficient to prove to newly syncing peers that the node’s DAG state is the honest one, without the pruned blocks.

Note this is the inverse of Bitcoin’s model, where keeping everything is the default and pruning is opt-in. On Kaspa, pruning is the default and keeping everything is opt-in via archival mode (--archival). Explorers and analytics services run archival nodes; most users and applications do not need to.

Why it is safe

Pruning is only sound if pruned history can never be rewritten - otherwise a node could not rule out a deep reorg into data it no longer has. This is what deterministic finality provides: the finality depth (~12 hours) guarantees blocks cannot be reorged well before they reach the pruning point (~30 hours). By the time data is discarded, it is provably immutable.

What a node keeps, and for how long

Blocks become final at 12 hours and are not discarded until 30, so a block is both final and still on disk for 18 hours. No data that could still change is ever discarded. The band runs right to left because the DAG grows rightward; each marker moves that way in real time, roughly 36,000 blocks an hour.

In this model, block data serves to propagate updates rather than as a permanent archive. The durable state is the UTXO set; blocks are retained long enough to verify the updates they carry.

Together, pruning and the difficulty adjustment bound block storage to hours of data and keep consensus state small enough that a Kaspa node runs on consumer hardware.