Pruning
Notes on why Kaspa nodes discard old block data, what they keep, and why it is safe.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’s answer: nodes 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.
- 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.
In this model, block data is a temporary broadcast medium rather than a permanent archive. The durable state is the UTXO set; blocks exist to update it and are kept long enough to make that update trustless.