TLDR: Although decentralized, Kaspa offers low latency at the expense of lacking historical verifiability. It also lacks privacy features, which makes it difficult to identify a clear use case.
As of January of 2025, Kaspa's full node takes up only ~14GB of storage to run.
Such Kaspa nodes publish in their decentralized ledger many times more bytes worth
of transactions than Bitcoin nodes do. And so not only is Kaspa faster than Bitcoin but it
is also cheaper for Kaspa's users to run a node than it is for Bitcoin
users to run theirs. Moreover, due to Kaspa's both high block rate emission and the energy efficiency of kHeavyHash, mining of Kaspa is far more decentralized than there is the mining of Bitcoin.
As of now, 59.7% of miners solo-mine it. Kaspa's mining is optical-ASIC-friendly.
It is a heavyCapEx mining, which Sompolinsky views as a decentralizing force
and an important factor in Kaspa's censorship resistance:
OPOW is a decentralizing force. It levels the mining field by centering competition around capital rather than energy, the former being order-of-magnitude easier to transport, convert, and distribute.Aside from geographical decentralization, the low-carbon signature additionally allows for stealth mining operations, the existence of which is essential for censorship resistance […]
As of early 2025, there are only 272 public Kaspa nodes and Kaspa market cap is only $3.6B. Both of these pale in comparison with Bitcoin's 21293 public nodes and BTC's market cap of $2T.
What are then the weaknesses of Kaspa? Let's look for them in the writings of its designer:
Yonattan wrote in 2021 that some important reasons for Kaspa's existence are
the need for the renaissance of P2P cash and the lowering the cost of running a node:
First, to make Satoshi great again. PHANTOM is really a neat generalization of Nakamoto Consensus (when k=0 PHANTOM coincides with the longest chain rule), it follows the same principles just with support for concurrency. It is Satoshi at its best, and the only path to fulfil His electronic cash vision. We make DAGs because we know how to and because no-one else does. We implement PHANTOM because we want to ping with “send txn” and be ponged “txn mined” [...]Third, because we need a base layer whose tradeoffs are centered around the crypto-informed user’s needs and asks. This implies, in particular, and according to the worldview I suggested above — implementing the default node to skip historical verification, making it an optional operation, one that relies on the fewer archival nodes that some entities choose to maintain and make available [...]Accordingly, Kaspa nodes prune block data by default, and new nodes by default do not request historical data, rather, they sync in SPV mode, i.e., by downloading and verifying only block headers. I reiterate that this is not a stronger trust assumption than a history-verifying node, rather a different requirement. The node then requests the UTXO set from untrusted peers in the network, and verifies it against the UTXO commitment embedded inside the latest received header (technically, this is done against the latest pruning point). [...]
When paying a small amount at a point of sale, this lack of historical verifiability does not seem to be of much importance. However, it becomes significant in transactions involving larger amounts than those typically handled at a point of sale, especially when there is a possibility of a legal dispute whose outcome depends on the transaction or when the transaction results in a significant tax liability. Examples of such transactions include monthly rent payments, car purchases, and real estate transactions.
Comparison of would-be-moneys:
| Asset | Scalability | Latency | Historical Verifiability | Anonymity | Mining |
|-------------------------------------------------------------------------------------------------------------
| BTC | Poor | High | Default | None | dominated by pools,high variance
| KAS | Good | Low | Expensive and optional | None | decentralized, CapEx-heavy
| XMR | Poorest | High | Optional with viewkey | Good | OpEx-heavy, high variance
The Lightning Network shifts the above comparison in favor of BTC with regard to scalability, latency, and anonymity. Providing anonymity for Kaspa's users does not appear to be a priority for its developers:
There is no official roadmap as there’s no organized development. I can write down what devs should be working on IMO, post bug fixing and version updates (HFs). In short, IMO priorities should be accelerating gradually to 10 blocks per second, then implementing an amazing upgrade to the consensus protocol, pending theoretical research results of Michael Sutton. In parallel, if someone can promote a privacy gadget (e.g., bulletproofs) and implementation for Kaspa that would definitely leap us forward.