Kaspa nodes delete most of the chain's history by design
Kaspa nodes discard most block history by design, keeping only a roughly 30-hour window since the Crescendo upgrade lifted block production to 10 per second. Here is what that means for node operators and coin balances.
(Advertisement)
Most blockchain nodes are built to remember everything. Kaspa takes a deliberately different path: its nodes are designed to forget.
Where a Bitcoin node stores and replays every block stretching back to 2009, a Kaspa node keeps only a recent slice of the chain and discards everything older than a threshold known as the pruning point. The result is a much lighter node, but one that carries no deep archive of the network's past.
What Crescendo changed for pruning
The Crescendo hardfork transitioned the Kaspa network from 1 block per second to 10 blocks per second. That tenfold jump in block production had a direct knock-on effect on how much history a default node retains. Due to the higher block rate, the pruning period shortened from approximately 50 hours to 30 hours. New nodes joining the network sync from the pruning point rather than from the chain's genesis block, keeping initial setup lean even as throughput rises.
To counter the data growth, Crescendo shortens the period for retaining full historical data, with old blocks pruned more aggressively since time progresses ten times faster. This does not weaken security, because any attempt to reorg or attack finality beyond the pruning point is computationally infeasible.
What node operators can control
Operators now have greater control over data management through a new retention-period-days configuration. The parameter determines how many days of historical data to retain, with a minimum value of two days. If not set, the node defaults to keeping only data for the pruning period.
Critically, pruning block history does not affect coin balances. Kaspa nodes by default prune data older than approximately 30 hours to reduce storage requirements, and while block data including transactions and headers are pruned, the full UTXO set is retained. That means native Kaspa balances remain verifiable even without the deleted history.
Reducing node storage requirements in turn lowers hardware requirements, promoting decentralization. The trade-off is a network where deep historical lookups require purpose-built archival infrastructure rather than a standard node.
Sources:
Rusty Kaspa v1.0.0 Mainnet Crescendo Release Notes, GitHub
Kaspa Pruning Glossary, Kaspalytics
(Advertisement)
Latest News
Read More...
Author
Crypto RichRich has been researching cryptocurrency and blockchain technology for eight years and has served as a senior analyst at BSCN since its founding in 2020. He focuses on fundamental analysis of early-stage crypto projects and tokens and has published in-depth research reports on over 200 emerging protocols. Rich also writes about broader technology and scientific trends and maintains active involvement in the crypto community through X/Twitter Spaces, and leading industry events.