Disk space by chain, why some keep every block forever, and why a Kaspa node holds near 50 GB no matter how long it has run.
Linear scale: bar length is proportional to gigabytes, not to its logarithm. A bar under 3% of the row width is floored to stay visible; read its number, not its length. Figures are this site's own chain dataset, captured 2026‑08‑01.
No. It would already be bigger than it is today, and it would keep growing forever. Pruning is what keeps the pruned figure above flat, not an incidental detail.
A node that never pruned would already hold at least about 76 GB of coinbase transactions alone since genesis, before a single user payment, block header, or byte of DAG bookkeeping is counted. The real pruned node running today is 50 GB, total.
This is an estimate built from real protocol constants (block rate history, genesis date, transaction byte sizes), not a measurement and not an invented curve. It is a floor: block headers, per-block DAG metadata, and every user transaction are left out because no published figure covers their size, so the true unpruned number is higher, likely well above this floor. See the arithmetic below.
This is a pruned Kaspa node, not one run with --archival (below), and not another chain.
Two different lines, not one. Finality is where a reorg becomes impossible. Pruning is where a node actually throws the block away, deeper than that, on purpose.
432,000 is not an arbitrary cutoff and it is not the discard point either. It is where the safety guarantee ends. The extra 18 hours the node keeps past that is a deliberate margin the protocol's own code adds on top, not a number squeezed to the edge of the security proof. Full derivation and sources are in the collapsible below.
A default Kaspa node is not the only option, and pruning is not one cut, it is two, backed by a specific proof rather than a guess.
Full node vs. archival node. The behavior above is what a default node does. Anyone who wants every block kept forever can run the same rusty-kaspa software with its own --archival flag, documented in the node's own help text as running "an archival node: avoids deleting old block data when moving the pruning point," with a plain warning attached: "heavy disk usage." No published size exists for a mainnet node run this way, so this page does not estimate one.
First-order and second-order pruning. Pruning itself is two passes, not one. First, at the 1,080,000-block boundary above, a node discards block bodies and transactions, keeping headers. Second, deeper still, it discards most of the headers too, keeping only a sparse "posterity" chain of headers spaced about 24 hours apart back to genesis, plus a cryptographic pruning proof that lets a new node verify that sparse chain is genuine. Source: rusty-kaspa's pruning-processor code and KIP-15.
MuHash: the actual answer to "is this safe." None of this works without a way to prove the current UTXO set, who owns what, right now, is correct without replaying the history that produced it. MuHash is Kaspa's answer: a rolling, order-independent commitment over the UTXO set, so a node can add and remove entries as coins are created and spent and land on the same fingerprint it would get from hashing everything at once (rusty-kaspa's crypto/muhash crate). A pruned node checks each new block's UTXO commitment against that fingerprint instead of re-deriving it from years of transactions. That check, not an assumption that old data probably doesn't matter, is what makes discarding it safe.
A pruned Kaspa node runs about 50 GB. Bitcoin's default is 758 GB, Ethereum's around 2 TB, Solana's 2.5 TB, Internet Computer's 32 TB. That gap is not better compression. Each of those keeps more history than Kaspa does, by choice or by design, for reasons the panel above breaks down chain by chain.
Block count since genesis. Kaspa's mainnet genesis is timestamped November 22, 2021 (rusty-kaspa genesis.rs). The Crescendo hard fork moved the network from 1 block/second to 10 blocks/second on May 5, 2025, mainnet DAA score 110,165,000 (rusty-kaspa v1.0.0 release notes). That gives two eras: about 1,260 days at 1 block/sec (108,864,000 blocks), then about 474 days at 10 blocks/sec through today, August 22, 2026 (409,536,000 blocks). Total: about 518,400,000 blocks ever produced. This part is measured, not estimated, aside from ordinary day-rounding.
Bytes per coinbase transaction. Every block carries exactly one coinbase transaction, a structural fact, not an estimate. Its size is modeled here as a transaction header (94 bytes) plus one output (52 bytes) — 146 bytes — using the same byte-level constants this site's own mass calculator sources from rusty-kaspa's transaction serialization code (consensus/core/src/mass/mod.rs, constants.rs). This is an ESTIMATE: real coinbase transactions can carry extra payload (miner tags and similar), which this model does not include, so 146 bytes is a floor, not a measurement.
The multiplication. 518,400,000 blocks × 146 bytes ≈ 75,700,000,000 bytes ≈ 76 GB. This counts only the mandatory coinbase transaction in every block. It excludes block headers, GHOSTDAG/DAG parent-pointer metadata, and every ordinary user transaction ever sent, none of which have a published per-block byte figure in this site's sources, so the real unpruned total is higher than 76 GB, and could be substantially higher.
What this does and doesn't show. It shows that even the smallest, most conservative slice of unpruned growth (one mandatory transaction type, modeled at its smallest plausible size) already exceeds the actual pruned node running today, 50 GB. It does not show a growth curve over time, a total including user transactions, or a true unpruned figure, because those inputs are not sourced anywhere this site can check. No number here is invented; where an input is a genuine measurement it is labeled as such above, and where it is a model built from real but incomplete constants, it is labeled ESTIMATE.
Finality and pruning depth: rusty-kaspa consensus/core/src/config/{params.rs,bps.rs,constants.rs}. FINALITY_DURATION is 43,200 seconds (12 hours); PRUNING_DURATION is 108,000 seconds (30 hours). At mainnet's 10 blocks/second, finality_depth() = 432,000 blocks and pruning_depth() takes the larger of a formula (finality depth plus safety terms for merge depth and anticone/mergeset size, referencing the project's Prunality analysis) and the flat 108,000-second floor; at 10 BPS the flat floor wins, giving 1,080,000 blocks. No source found explains why 30 hours specifically, rather than a different round number, was chosen for that floor; it reads as a margin the protocol's authors judged sufficient rather than a value derived from a unique calculation. KIP-15 independently states the same figure in its own words: a node "prunes the transaction and header data after c. 52 hours (30 hours post-Crescendo)."
Archival mode: rusty-kaspa kaspad CLI, --archival flag, help text "Run as an archival node: avoids deleting old block data when moving the pruning point (Warning: heavy disk usage)," plus --retention-period-days for partial retention. First-order and second-order pruning, and the posterity-header chain: rusty-kaspa's pruning-processor source (consensus/src/pipeline/pruning_processor) and KIP-15. MuHash: rusty-kaspa crypto/muhash/src/lib.rs, documented there as a rolling (homomorphic) hash supporting order-independent add_element/remove_element.