Toccata Hard Fork: A practical upgrade timeline and checklist for Kaspa node operators

Quick take

The Toccata ("Covenants++") hard fork is Kaspa’s next major programmability upgrade. It brings native covenants via the SilverScript toolchain and primitives for verified off-chain computation using L1 sequence commitments plus ZK verification opcodes. Kaspa teams have pushed the mainnet activation window to roughly June 5–20, 2026 to finalize sequencing commitments and rehearse the rollout. This note translates the technical update into a practical timeline and a step-by-step checklist for node operators, wallet teams, and infrastructure providers.

What Toccata changes (in plain terms)

Toccata adds two developer-visible paths:

• Native L1 covenants and the SilverScript compiler for richer on‑chain spending conditions.
• A ZK‑anchored path where off‑chain computation is verified on L1 via new ZK opcodes and sequencing commitments, enabling the vProgs architecture for verifiable programs.

Low‑level building blocks include KIP‑16 (ZK verification opcodes), KIP‑17 (extended script opcodes), KIP‑20 (covenant IDs) and KIP‑21 (partitioned sequencing commitment). KIP‑16 is already merged into the rusty‑kaspa reference implementation; KIP‑21 remains the gating design for safe ZK app activation.

Timeline snapshot — what to expect

• Feature freeze & review: Core KIPs have been merged or are in review. The project entered a feature freeze while finalizing sequencing commitments.
• TN12 restart (clean): A clean testnet restart is planned to validate the combined changes.
• Development merge, audits, rehearsals: Merge, third‑party audits, and a TN10 rehearsal are scheduled before activation.
• Mainnet activation window: Moved from the original May 5 date to approximately June 5–20, 2026 to finalize KIP‑21 and complete checks.

Upgrade checklist for node operators (prioritize this now)

Before the hard fork

• Subscribe to official release notes and upgrade announcements from the Kaspa team and the rusty‑kaspa releases channel. Expect required client upgrades; rusty‑kaspa v1.1.0 (Mar 4, 2026) already introduced DB schema and toolchain changes as a precedent for mandatory upgrades.
• Plan for storage: the team warns disk usage may rise ~20–50% after Toccata; audit node disk/IO capacity and increase headroom.
• Take a recent full node snapshot and verify backups of wallet keys and config. Test restores in a sandbox environment.
• Run a local or staging node on the latest release candidate builds used in TN10/TN12 rehearsals where available. Watch community testnet reports for RAM and throughput behavior under sustained high TPS.

During the rollout/rehearsal phase

• Follow the project’s rehearsal steps: TN12 restart, merge dev branch, audits, TN10 rehearsal. Coordinate with other operators if you provide RPC endpoints or public peers.
• Monitor node logs for new opcode or signature‑operation (sigop) pricing messages — KIP‑16 introduces ZK precompiles and benchmarking guidance that may influence mempool and fee behavior.
• If you run pruning or archival nodes, validate that your pruning policy is compatible with the new covenant metadata and sequencing commitments.

After mainnet activation

• Ensure all nodes are upgraded to the activated client version before the activation point. Outdated nodes will not follow the new ruleset.
• Monitor resource metrics closely (disk, RAM, CPU). Expect tooling and SDK updates from the ecosystem; coordinate rolling restarts where necessary.
• Validate wallet integrations and third‑party services against the network behavior. Watch for upstream library releases that add support for new opcodes and covenant IDs.

Wallet and ecosystem notes

Hardware wallet support varies today: Ledger lists Kaspa and points users to third‑party wallets (for example, KasVault) for account management, while Trezor’s page indicates it does not currently support Kaspa natively. Wallet teams should prioritize compatibility tests, signing behavior for new covenant scripts, and any RPC changes introduced by the updated node releases.

Short checklist for wallet teams

1. Confirm signing flows for covenant scripts and test serialized transactions on rehearsal testnets.
2. Coordinate with hardware wallet providers and communicate any UX changes to users before activation.
3. Track SDK/tooling releases that implement KIP‑16/17/20 and the sequencing commitment APIs.

Notes for builders and infra providers

If you build ZK‑anchored apps (vProgs), KIP‑21 — partitioned sequencing commitments — is the key gating feature. The vProgs draft describes an architecture where L1 only verifies externally computed results via submitted proofs and sequencing commitments, preserving L1’s role as a shared ordering and availability layer while avoiding on‑chain execution of heavy computation.

Developers should follow testnet rehearsals to see how proof submission flows, gas metering (ScopeGas), and conditional proof batches behave in practice before targeting mainnet deployments.

Where to follow updates

Track the official Kaspa hard fork announcement and developments page for feature‑freeze, rehearsal, and activation announcements. Follow the rusty‑kaspa releases channel for client builds and the KIP PRs for technical details on opcode merges and benchmarks.

Staying prepared now — upgrading test nodes, validating backups, and coordinating with wallet partners — will make the Toccata transition smoother. The June activation window gives a short runway; use it to rehearse, test, and confirm your operational procedures.

— Kaspa Daily operations & upgrades desk