Kaspa prepares the Toccata hard fork

Kaspa is asking operators to prepare for the Toccata hard fork, scheduled on mainnet at DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC according to the official guide in the rusty-kaspa repository. The project presents v2.0.1 as a release that can serve both as a drop-in update for nodes already on v2.0.0 and as the Toccata upgrade version for nodes still running the 1.x line. The operational message is direct: infrastructure operators should upgrade before activation, because a consensus change can leave unprepared nodes split from the network.

Toccata is more than routine maintenance. The guide links the hard fork to several KIP proposals and highlights two technical goals: bringing native L1 covenant programming to Kaspa and preparing infrastructure for applications based on ZK proofs. A covenant is a constraint embedded in the spending logic of an output, for example a rule that limits what can happen to funds in a future transaction. In Kaspa’s case, the point is to make that kind of rule usable without pushing all the logic into an external layer.

The most practical section is aimed at integrators. The guide says wallets and transaction-submitting software should avoid old fixed-fee assumptions. After Toccata, the minimum standard fee rule moves to 100 sompi per gram, with a formula that accounts for compute grams and transaction bytes. Software that relies on the node fee-estimation API should follow the change automatically, but services that calculate fees themselves need to update. The APIs also change terminology: the old mass field becomes storageMass or storage_mass, although temporary JSON compatibility remains.

For pools, explorers, and exchanges, the risk is therefore operational rather than abstract. They are asked to test deposits, withdrawals, block templates, indexing, balance tracking, and transaction parsing against Testnet-10 before mainnet activation. Kaspa also warns that the node database upgrade is one-way, so returning to an earlier version may require a resync. The useful signal is that a proof-of-work network is trying to add richer programming capabilities while surfacing the integration burden early. The technical upgrade only matters if the surrounding tooling can absorb it without breaking user-facing infrastructure.