Did Kaspa lose its
transaction history?

Yes. Some of it. Here's exactly what happened, what it means, and what it doesn't.

Scroll to begin ↓
What Happened
The security cameras went down.
The vault was untouched.
🏦
Think of it like a bank vault
Every dollar inside is accounted for — you can count it, verify it, it's all there. But the security camera footage from the first three months got corrupted. You can't rewind the tape and watch who walked in and out. The money is all there. The recording isn't.

Kaspa launched November 7, 2021. For roughly the first six months, detailed transaction history became inaccessible on block explorers. Balances were never affected. The UTXO set — who owns what — was always cryptographically intact. What was lost was the ability to browse individual transactions from that period.

Nov 7, 2021
Mainnet launches. Mining begins at 500 KAS per second.
Nov 21, 2021
Consensus bug splits the network. ~648M KAS already mined.
Nov 2021 – May 2022
The "missing data" window. ~7.8B KAS mined (~29% of max supply). Explorer-level transaction browsing lost for this period.
Aug 2023
Team publicly asks community for help recovering data. Not the behavior of people hiding something.
2024–2025
Bug found and fixed (PR #2275). Supertypo builds Rust indexer. 75–100% of data recovered from community LevelDB backups.
Claim vs Reality
What the critics say.
What actually happened.
"Transaction data was deliberately destroyed to hide insider accumulation."
Reality: It was a software bug. The Go node's database filler crashed on large blocks, and the node software erroneously refused to serve block data beyond the pruning depth — even when the data existed in LevelDB. PR #2275 fixed the retrieval bug. The data was never deleted from nodes that preserved their directories — which is why 75–100% has been recovered.
"There is not a single Kaspa full node out there today."
Reality: Every Kaspa node is a full-validating node. It verifies every block, every transaction, every signature, every consensus rule. Pruning old transaction browsing data is a storage optimization — it doesn't skip validation. Bitcoin SPV wallets skip validation. Kaspa nodes don't.
"The fair launch claim is unverifiable."
Reality: The genesis block's UTXO commitment equals the MuHash of an empty set — cryptographically proving zero coins existed at launch. This is independently verifiable by anyone. We built an entire page walking through the 9-step proof.
The Kill Shot
The supply is provably correct.
Here's why.
🧾
The receipt got smudged. The cash is all there.
The transaction history is like a receipt — a record of who paid what. The UTXO set is the actual cash in the register. You don't need the receipt to count the cash. Every Kaspa node independently counts every coin and verifies it matches the deterministic emission schedule. If even one extra KAS existed, every node would reject it.
Total supply correct — UTXO commitment proves it on every node. Genesis started at zero (verified).
No coins created outside emission schedule — consensus rules enforce 500 KAS/sec. Every node rejects non-compliant blocks.
Every coin traces to a valid block reward — deterministic schedule, hardcoded, immutable.
100% of data after Feb 2022 recovered and browsable.
75% of data from Nov 2021 – Feb 2022 recovered from community LevelDB backups.
~25% of earliest browsable history still missing from explorers. The gap is real.

The FUD conflates auditability of distribution (who mined what) with auditability of supply (is the total correct). They're different things.

"People had their Kaspa stolen."
Reality: Pruned nodes have validated every signature since the genesis block. Pruned nodes ARE Kaspa's security. This is impossible.
The Recovery Is Trustless
Recovered data can't be faked.
Here's why.
🔐
The headers are the lock. The data is the key.
Kaspa prunes transaction bodies but keeps every block header forever. Each header contains a merkle root — a cryptographic fingerprint of every transaction in that block. When someone submits recovered block data, it has to hash to the merkle root already stored in the header. If even one byte is wrong, the hash won't match. It's like trying to forge a key for a lock that already exists — computationally impossible.

This means the 75% of recovered data isn't taken on trust. It's mathematically verified against headers that have been on every node since day one.

What if someone submitted fake transactions?
The transaction hashes wouldn't match the merkle root in the header. Rejected instantly. Blake2b with 256-bit output — forging a match would take longer than the age of the universe.
What if someone faked entire blocks?
Block headers form a hash chain — each one references its parents. The headers were never lost. You can't insert a fake block because there's no header for it to match.
What about the UTXO commitments?
Every header also contains a UTXO commitment (MuHash). If you replayed recovered transactions and the resulting UTXO set didn't match the commitment in the next header, the data is invalid. It's a double-check on top of the merkle root.

But what about the worst case — could one person have mined all the early Kaspa?

Even if a single entity mined 100% of blocks in the missing window, the recovered data proves this didn't happen. The 75% of recovered blocks show diverse mining activity — different miners, different addresses, distributed across the network. And the remaining 25% can't contain a different story, because the UTXO commitment chain constrains what's possible. The math at each checkpoint has to add up. You can't hide a secret mining operation inside a cryptographic commitment that every node already validated.

Headers never pruned — the merkle roots have existed on every node since genesis
Recovered data verified by hash — must match the merkle root in the existing header
UTXO commitments double-check — replayed transactions must produce matching state
75% recovered shows diverse miners — not a single entity accumulating
Remaining 25% is constrained by math — UTXO commitments limit what those blocks can contain
What Went Wrong
A series of early-stage
engineering oversights.
1
The original indexer struggled with large blocks. The PostgreSQL database filler (written in Go) ran into query size limits on blocks with many parents or transactions. When it crashed, operators often had to reset the database to get it running again.
2
Archival mode had a gap. Nodes running with --archival could lose historical data if they went offline for an extended period and re-synced using pruning proofs. This edge case wasn't caught early enough.
3
A metadata flag caused data to be skipped. The Go node's RPC handler checked an IsHeaderOnly flag and assumed no transaction data was available — even when the full block existed in LevelDB and was retrievable.
4
The fix came during a transition period. Toni Lukkaroinen submitted PR #2275 in May 2024. It was merged in March 2025 — the delay largely because the team was focused on the Rust rewrite by that point.

Small team building something no one had built before. The first-ever blockDAG. Moving fast, prioritizing the protocol. Archival tooling didn't keep pace with the rest of the stack.

The Recovery
If it was deliberately destroyed,
recovery would be impossible.

The data existed in LevelDB on nodes that preserved their data directories. The problem was always retrieval, not deletion.

Aug 2023
Call to action. Team asks community to check old data directories.
May 2024
Toni Lukkaroinen identifies the exact bug in the Go node. Submits PR #2275.
Dec 2024
Supertypo builds simply-kaspa-indexer in Rust — a proper replacement for the broken Go indexer.
2025
75–100% of data recovered from community LevelDB snapshots. Recovery is ongoing.

Community members dug through old hard drives, found preserved node data, and submitted it. Block by block, the history has been pieced back together. You can't recover data that was deliberately erased network-wide.

The Honest Take
We're not going to spin this.

Is this a black mark?

Yes. A production network should not lose browsable history for its highest-emission period. It was an engineering failure and a real transparency shortcoming.

Is it fraud?

No. The UTXO set is math. Every node verifies it independently. The supply is provably correct. The genesis started at zero. The emission schedule is deterministic. No coins were created outside the rules.

The strongest counterpoint

The UTXO set is math, not trust, and it has always been valid.

The missing data is a transparency shortcoming, not a supply integrity issue. You don't need security camera footage to count the cash in the vault.

PoW Protocol University

Sources: PR #2275 · The Forgotten Blocks · simply-kaspa-indexer · TechLeaks24 (the FUD article) · Genesis Proof