Kaspa's Toccata Hard Fork: Covenants, ZK Opcodes, And A New June Target

Kaspa's upcoming Toccata hard fork will add two new programmability paths to the network: native L1 covenant programming and based zero-knowledge (zk) application infrastructure, with mainnet activation now scheduled for June 5–20, 2026, pushed back from the original May 5 target.

Michael Sutton of Kaspa Core published a detailed update on what the hard fork includes, why the date moved, and how the next few months are expected to unfold. The fork was originally initiated by Ori Newman as an effort to bring covenants into Kaspa's script engine, partly in response to the OP_CAT discussion in Bitcoin circles. It has since grown into something considerably larger.

What Is The Toccata Hard Fork?

Toccata is a scheduled hard fork for the Kaspa network that introduces new capabilities directly into the base layer. A hard fork, for those less familiar, is a protocol upgrade that is not backward-compatible. All nodes must upgrade to continue participating in the network.

The name follows Kaspa's tradition of using musical references for major upgrades. This one takes its name from a classical musical form, the toccata, a piece designed to showcase technical skill across a keyboard instrument.

At a high level, Toccata adds two things to Kaspa:

• Native L1 covenant programming via a new compiler called Silverscript
• Based zk application infrastructure, built on top of those same covenant foundations

These are not interchangeable systems. They serve different use cases and target different developer audiences.

What Are Covenants And Why Do They Matter For Kaspa?

Covenants are conditions placed on how funds in a transaction output can be spent in the future. In a standard Bitcoin or Kaspa transaction, once coins are sent, the recipient can do whatever they like with them. Covenants change that by embedding spending rules directly into the script.

Kaspa uses a UTXO model, similar to Bitcoin, where each transaction consumes existing outputs and creates new ones. Covenants in a UTXO system allow developers to build surprisingly complex stateful multi-contract flows, even though the underlying computation remains local to each UTXO.

To make covenant development more accessible, Kaspa Core is finalizing Silverscript, a compiler initiated by Ori Newman, Michael Sutton, IzioDev, and Manyfest. Silverscript is designed to make it easier and safer to write and deploy complex covenants directly on Kaspa L1, without developers needing to work at the raw script-engine level.

What Are Based ZK Applications?

The second programmability pillar introduced in Toccata is based zk applications. This is the more technically dense of the two and worth unpacking carefully.

ZK stands for zero-knowledge, a cryptographic method that lets one party prove something is true without revealing the underlying data. ZK proofs are increasingly used in blockchain scaling because they allow off-chain computation to be verified on-chain cheaply and securely.

"Based" in this context means the zk system fully follows L1 sequencing. A based zk application cannot add or drop transactions independently. It is anchored to Kaspa's own transaction order, which is what makes it trustworthy without a separate sequencer.

Toccata introduces several components to support this:

• ZK verification opcodes, including a flexible Groth16 verifier and a RISC Zero STARK verifier
• A sequencing commitment access opcode, enabling based applications to anchor themselves to L1 ordering
• KIP-21, a partitioned sequencing commitment architecture that ensures a zk app's proving costs scale with its own activity, not with overall DAG activity

The RISC Zero STARK verifier is already implemented and activated on testnet 12. Whether it activates on mainnet is still being decided.

Why Proving Costs Matter

For any zk application to be practical, the cost of generating proofs needs to stay proportional to what the application itself does. If a zk app had to prove work relative to all activity on the broader DAG, costs would become unpredictable and unmanageable. KIP-21 solves this by partitioning sequencing commitments, keeping each app's workload self-contained.

What Is Already In Place?

A significant portion of the hard fork is already implemented. The following features are already built:

• Extended script-engine opcode support, the core covenants backbone, under KIP-17
• Covenant IDs for lineage management as a consensus and engine feature, under KIP-20
• ZK opcodes with a zk-verifier precompile subsystem, under KIP-16, authored by Alexander Safstrom
• Sequencing commitment access opcode
• KIP-21, authored by Sutton and implemented by Maxim Biryukov, fully implemented and pending review

Proof-of-concept milestones, including inline zk covenants and based zk covenants with a KAS canonical bridge, have also been completed by Maxim and were instrumental in shaping the final design of the fork.

Why Did The Hard Fork Date Move To June?

The original mainnet target was May 5, 2026. It has since moved to a window of June 5–20, 2026.

The reason is architectural. Once zk circuits and runtimes bind to a sequencing commitment hashing structure, any structural changes after the fact become breaking changes. Getting the design wrong and patching it later would be far more disruptive than taking the extra time now.

KIP-21 is already designed to be future-compatible with the commitment scheme that will eventually be required by vprogs, Kaspa's longer-term roadmap for synchronously composable verifiable programs. Locking in the right structure before mainnet activation avoids costly migrations later.

The feature freeze is expected on April 15, 2026.

What Happens Between Feature Freeze And Mainnet?

After the April 15 feature freeze, Kaspa Core plans a clean restart of the dedicated testnet, TN12, with the full final feature set included. This is not a simulation of the hard fork transition. It is a clean network for testing the complete feature set in its final form.

From there, the team will merge the accumulated months of work from a long-lived pending branch back into the master codebase. That process involves final auditing, closing open items, perfecting hard-fork activation logic, and handling database upgradability.

Once that work is complete, a test hard fork will run over TN10, the long-term testnet, to simulate a full mainnet-style transition. The mainnet date will only be hardcoded after that rehearsal runs to the team's satisfaction.

What Node Operators Should Expect

For miners and node operators, the upgrade is designed to be straightforward. Nodes need to be updated, and existing functionality should continue working. Disk space requirements are expected to increase by roughly 20 to 50 percent. No dramatic infrastructure changes are anticipated.

What Toccata Actually Delivers For Kaspa

Toccata adds two working programmability systems to Kaspa's base layer: native L1 covenant scripting through Silverscript, and based zk application infrastructure through KIP-16, KIP-20, and KIP-21. A large portion of the technical work is already done. What remains is finalizing interfaces, merging the pending branch into master, and running a full rehearsal on TN10 before the mainnet date is confirmed.

The June 5–20, 2026 window exists because the team chose to get the sequencing commitment architecture right the first time rather than fix it later under live conditions. For node operators, the upgrade is designed to be straightforward, with no major infrastructure changes beyond a modest increase in disk space.

Resources

1. Kaspa on X: Post (April, 2026)

2. Blog article by Michael Sutton: Kaspa Covenants++ “Toccata” Hard-Fork Outlook