This post is based on post by @ michaelsuttonil “Kaspa Covenants++ ‘Toccata’ Hard-Fork Outlook.”
It presents the key elements of the hard fork in a structured format, with added context and commentary to help explain how the pieces fit together and what it could mean for users.
Kaspa is entering a new phase. The upcoming “Toccata” hard fork introduces programmability to the network in a structured and deliberate way, while keeping the base layer stable and predictable. This post tries to walk through what is being introduced, how it rolls out, and what it enables in practice.
What Toccata brings
Michael outlines that this hard fork introduces two programmability paths:
• A new compiler for L1 scripting, called Silverscript
• Infrastructure for zk-based applications, built on covenant foundations
These systems are designed to operate from the same underlying base layer.
The dual structure of programmability
Michael describes Kaspa’s programmability as having two pillars.
1. Native L1 covenant programming
This is built directly into Kaspa’s script engine.
He describes it as:
• aimed at peer-to-peer applications
• capable of “complex stateful multi-contract flows”
• grounded in local UTXO computation
Silverscript is being finalized to make this system easier and safer to deploy.
2. Based zk applications
This layer includes:
• zk verification opcodes
• sequencing commitment access
• the partitioned sequencing commitment architecture (KIP-21)
Michael explains that these, together with covenants, provide the foundation for:
• based zk applications
• canonical bridging between layers
He also notes that these applications follow L1 sequencing and cannot add or remove transactions.
Where this fits in the roadmap
Michael writes:
“This is also a significant milestone on the road to vprogs(yellowpaper)”
He also states:
“We are not there yet.”
The stage he is referring to is synchronously composable verifiable programs (vprogs).
He explains:
• the current focus is standalone zk applications
• these communicate through L1 proof-based bridging
• synchronous composition is part of a later stage
He also notes that the vprogs runtime layer is already being developed, primarily by Hans Moog.
What is already implemented
Michael states that a substantial portion of the hard fork is already in place:
• KIP-17: extended script-engine opcodes, forming the covenants backbone
• KIP-20: covenant IDs, enabling lineage tracking
• KIP-16: zk opcodes and verifier subsystem
The zk system currently supports:
• a flexible Groth16 verifier
• a RISC Zero STARK verifier, active on testnet 12, with a decision pending for mainnet
Also included:
• sequencing commitment access opcode
He also mentions completed proof-of-concept work:
• inline zk covenants
• based zk covenants with a canonical KAS bridge
Why sequencing commitments matter (KIP-21)
Michael explains that zk applications need proving costs that scale with their own activity, rather than the full DAG.
This allows zk applications to operate in a way that remains practical as the network grows.
KIP-21 is designed to support that requirement.
What is being finalized now
** Expected feature freeze: April 15, 2026**
Items being finalized:
• script-engine pricing policies
• KIP-21 review
• subnet and gas commitment support
This stage focuses on locking interfaces before moving toward mainnet.
Why the mainnet date moved
Originally targeted: May 5, 2026
Updated: ~June 5 to 20, 2026
Michael explains that the sequencing commitment architecture needed to be finalized correctly before activation, especially for zk systems. Once zk circuits and runtimes bind to that structure, later structural changes would become breaking. The additional time is used to finalize that design before launch.
The path to Mainnet
Michael outlines the rollout sequence:
1. Feature freeze (April 15, 2026)
2. Restart TN12 as a clean testnet with all final features
3. Merge the long-lived development branch into master
4. Final auditing, cleanup, and activation logic work
5. Simulate a full transition via a hard fork on TN10
6. Finalize and hardcode the mainnet activation date
He emphasizes that the TN10 rehearsal is the key step before mainnet.
The steps after feature freeze are not assigned specific dates. They proceed in sequence, with timing dependent on successful testing and integration.
The mainnet activation is expected within a window of **~June 5 to June 20, 2026,** and is finalized only after the full transition rehearsal is completed to satisfaction.
Detailed release notes, as always, will be available and the support crew can assist in any integration if requested.
Ecosystem readiness
Michael describes a straightforward operational impact:
• Node operators upgrade
• Existing functionality continues to work
• Disk usage may increase by approximately 20–50%
For developers:
• New SDKs and APIs will support the new capabilities
• Existing APIs continue working
• Tooling will continue to evolve after the fork
Kaspa core also intends to support adoption through compilers, SDKs, and runtimes.
What is not included in this stage
Michael does not present this hard fork as the final form of Kaspa programmability.
He explicitly states:
• the network is not yet at vprogs, described as synchronously composable verifiable programs
• the current focus is on standalone zk applications, not full synchronous composition
No timeline for vprogs completion is given in this article.
Why the name “Toccata”
Michael introduces the name as part of Kaspa’s musical naming tradition.
A toccata is a composition associated with technical expression and range.
The name reflects a phase where the system begins to support more expressive behavior.
(A deeper commentary on what this name is a perfect fit is incoming)
Why this matters
This section reflects what these capabilities could enable in practice.
👩🏻💻Developers
• Ability to define transaction flows with enforceable rules
• Direct access to L1 scripting through covenants
• Foundation for building zk applications aligned with L1 sequencing
💳Merchants
• Payments that follow defined conditions
• Structured flows such as staged payments or conditional release
• Coordination handled at the transaction level
🏢Enterprises and institutions
• Asset flows with defined rules and verifiable lineage
• Systems built on shared, verifiable transaction logic
• Integration paths for zk-based applications and bridging
⛏️Miners and node operators
• Continued participation with upgraded nodes
• Expanded network capabilities
• Similar operational model with moderate resource increases
🙋🏽Everyday users
• Transactions that include conditions and structure
• Interaction with applications that coordinate multiple steps
• Assets with clearer origin and movement history
Simply Put
Toccata introduces two forms of programmability on Kaspa built on the same foundation:
• native L1 covenant programming
• zk-based applications that follow L1 sequencing
From this foundation, transactions can carry defined rules and follow structured paths, enabling applications that coordinate value across multiple steps with outcomes enforced by the network itself.
Many of these pieces exist across the industry today. But, bringing them together at the base layer, with parallel processing, covenant logic, and zk systems aligned to L1 sequencing, is where this development and future path can set Kaspa apart.