Kaspa prunes old data to limit the storage needed to run a node. Pruning is part of its working design, not a proposal: nodes can discard older information while keeping what the protocol needs to continue checking the network. The safety rules behind this are studied in the research work *Prunality of the GHOSTDAG protocol*. [1]
What gets removed, and what stays?
A node is a computer that checks and follows the network. Kaspa distinguishes between keeping the current state needed for validation and keeping every old transaction record. Its pruning design allows old transaction data to be discarded. [2]
The UTXO set is the collection of coins that have not yet been spent. This current coin state is separate from the complete transaction history: Kaspa’s node design retains the UTXO set even when older block data is pruned. Removing an old transaction record therefore does not remove an unspent coin created by that transaction. [2]
An archival node serves a different purpose: it keeps historical data older than the recent window that a normal node keeps. That history can be useful when someone needs old records, but retaining it is not the same task as maintaining the current coin state. [2]
Why pruning needs special care
Kaspa’s blocks form a DAG, a structure in which blocks can have several connections rather than forming only one line. Deleting old blocks must not destroy the information needed to understand the relationships between surviving blocks. The June 2025 developer workshop explains this as the need to remove information while preserving what it implies for the remaining structure. [3]
That is why pruning is more than deleting files older than a chosen date. Kaspa has rules for which information can be removed and which information must survive; its background documentation points to separate research on pruning headers and proving history after headers have been removed. [1]
Why it is considered safe
A joining node does not simply accept a downloaded balance list. In the normal synchronization process, the pruning-point proof and the UTXO state are validated. The pruning point provides the reference from which the node continues, without requiring it to download and replay every discarded transaction. [4]
There is also a practical safety issue: the computer might stop halfway through pruning. Michael Sutton’s change to Rusty Kaspa, merged on 1 June 2023, added database batches that save the current position, recovery on restart, and a saved marker so an unfinished pruning operation can resume. [5]
The important distinction is that safe validation does not mean permanent access to every old record. A pruned node and an archival node deliberately retain different amounts of history. [2]
Is everything deleted at one fixed age?
No. In the June 2025 workshop, the default retained window was described as roughly 30 to 42 hours, with pruning advancing about every 12 hours. The workshop also described configurable longer retention, using 30 days as an example. Those were the settings explained at that workshop, not a promise that every record disappears at one exact age. [6]
For the explanation to watch, see the 4 June 2025 developer workshop with Michael Sutton and Hans Moog, at 2:52, on why pruning must preserve the relationships between remaining blocks. [3]