Kaspa's Programmability Upgrade Lands, But Usage Numbers Haven't Followed

That shifts the project into a more ambitious category. Kaspa is no longer only competing for attention as a faster proof-of-work chain; it is trying to prove that a PoW blockDAG can also support an application ecosystem. The harder question is whether the new functionality is being used. Early post-fork data suggests that the technical surface area has expanded, but user and protocol activity still look thin and concentrated in a single rollup.

Kaspa’s new pitch

Kaspa sits in an unusual part of the crypto market. Like Bitcoin, it uses proof-of-work rather than proof-of-stake, relying on miners and computational cost for security. But unlike Bitcoin, Kaspa was designed around a blockDAG structure that allows multiple blocks to be created and ordered in parallel, giving it much higher throughput than traditional proof-of-work chains. That made its original pitch relatively simple: a faster PoW network for settlement and payments.

Toccata changes that pitch. A hard fork is a protocol-level upgrade that changes the rules nodes follow, meaning the network must coordinate around the new version. In this case, the upgrade pushes Kaspa closer to the programmable-chain category occupied by Ethereum, Solana and other application platforms. The difference is that Kaspa is trying to do this while preserving its proof-of-work identity. That makes the experiment more distinctive: it is not trying to become another proof-of-stake smart-contract chain, but rather a PoW base layer that can support more complex application logic through covenant-based applications and ZK-related infrastructure.

That shift matters because programmability raises the standard for judging the network. For a payments-oriented chain, speed and settlement capacity are central. For an application platform, the test is broader, involving developers, active users, protocol activity, fees and liquidity. Toccata gives Kaspa the technical foundation to enter that conversation, but it also makes the next phase more demanding.

Usage still looks low

The early activity data does not yet show a broad post-upgrade adoption cycle. On 30 Jun, Kaspalytics showed roughly 3.6k–3.7k unique sending addresses. That is low not only for a programmable-chain thesis, but even for a payments network. Kaspa's original pitch was high-throughput proof-of-work settlement; yet the current active sender base remains small relative to that ambition. It is smaller still than Kaspa's own history: Kaspalytics recorded a peak of 753.63k unique sending addresses on 5 Oct 2025, with sustained activity above 300k daily addresses through October and November before falling below 10k. Toccata has not moved that baseline. Daily unique addresses remain in the same low thousands as before the fork, with no sign yet that the upgrade has added fresh momentum to the chain.

Protocol-level activity gives a more nuanced picture, but it is also highly concentrated. Over the prior seven days, tracked protocol activity totalled roughly 329,337 transactions across the listed categories. Igra L2 accounted for 300,610 transactions, or about 91% of the tracked total. Igra L2 is an EVM-compatible based rollup that uses Kaspa as its base layer, so its activity appears concentrated in rollup-related transaction flow rather than broad activity across many separate Kaspa-native applications. Kasplex L2 followed with only 7,274 transactions, while Kasia generated 4,641, KNS 1,629, and K Social just 61.

(Source: Kaspalytics)

Fees show a different concentration, but the bigger issue is how small the numbers are. While Igra dominated the transaction count, KRC inscriptions generated 11,630 KAS in fees from 15,122 transactions, representing roughly 95% of tracked protocol fees. At $0.03 per KAS, that is only about $349 over the past seven days. Igra, despite handling far more transactions, generated just 551 KAS, or roughly $17, in the same period. Across the listed protocols, total fees were about 12,247 KAS, equal to roughly $367 over seven days. Annualised, that is only about 638,600 KAS, or about $19,200 at $0.03 per KAS. That run-rate should not be treated as a forecast, but it makes the point clear: Kaspa's post-fork ecosystem is producing activity, but almost no fee economy. One L2 dominates transactions, inscriptions dominate what little fee revenue exists, and the overall scale remains far from a diversified application ecosystem.

Traders reacted, but Kaspa didn't reprice

Market data show Toccata attracted attention, but mostly as an event trade. On 30 Jun, the day of the hard fork, Kaspa's estimated market cap was $802.8mn, down 3.8% on the day, after rising from $760.5mn on 28 Jun to $834.2mn on 29 Jun. That looks like a classic pre-event bid followed by a post-activation fade.

Volume was the clearest reaction, though the absolute numbers remained small. Spot volume reached $13.7mn, about 64% above the prior seven-day average, while futures volume jumped to $32.4mn, roughly 156% above the same baseline. For a network trying to move into the programmable-chain conversation, less than $50mn in combined spot and futures turnover on upgrade day is still thin.

Positioning was also limited. Open interest rose 9.4% to $17.1mn, but remained below its 30-day and 90-day averages. Funding was positive at roughly 9.1% annualised, showing a mild long bias but not euphoria. The read-through is simple: traders engaged with Toccata, but the market has not yet treated it as proof of a higher valuation regime.

The fork was real, the adoption test comes next

Toccata gives Kaspa a more ambitious technical roadmap, but the first data do not yet show that the network has crossed into a new adoption phase. Unique sending addresses remain low, even for a payments-oriented chain. Protocol activity exists, but it is heavily concentrated around Igra L2, while most of the small fee base comes from inscriptions. Market activity tells a similar story: traders reacted to the hard fork, but volumes, open interest and valuation did not suggest a durable repricing.

That does not make Toccata irrelevant. It is a meaningful upgrade because it expands what developers can build on Kaspa. But the burden of proof has now shifted. The next important signal is not another technical milestone, but whether the new programmability leads to sustained address growth, broader protocol usage, more meaningful fees, deeper L2 liquidity and applications that users return to. For now, Kaspa has upgraded what it can support. It still needs to prove there is demand for it.