Fittingly, we begin by crowning this effort with its proper musical tone -- “Toccata” -- in keeping with our harmonic tradition.

Initiated by Ori Newman as an effort to introduce covenants into Kaspa’s script engine, partly in the context of the OP_CAT discussion in BTC circles, this hard fork has since expanded well beyond covenants themselves. At a high level, Toccata now brings two new programmability paths to Kaspa:

• a brand new compiler for utilizing these script capabilities directly on L1, namely Silverscript
• the infrastructure for a zk layer built over those same covenant foundations

The dual landscape

Kaspa’s programmability landscape is now taking a clearer shape, and it has a dual form.

The first pillar is native L1 covenant programming, aimed at peer-to-peer oriented applications -- including surprisingly complex stateful multi-contract flows -- even though the model itself remains grounded in local UTXO computation. This is the world of direct script-engine programmability on Kaspa itself. On this side, core is actively finalizing Silverscript -- initiated by Ori Newman, myself, IzioDev, and Manyfest -- to make it easier and safer to deploy complex covenants directly on Kaspa L1.

The second pillar is based zk applications: zk verification opcodes, sequencing commitment access, and the partitioned sequencing commitment architecture of KIP-21. Together with covenants -- now expressive enough to implement the L1 side of a based zk settlement protocol -- these provide the foundation for building based zk applications over Kaspa, including canonical bridging. For background, see the research posts on based zk rollups over Kaspa and the L1-L2 canonical bridge entry/exit mechanism.

This is also a significant milestone on the road to vprogs (yellowpaper), where the long-term destination is synchronously composable verifiable programs. We are not there yet. The current focus is on standalone based zk applications, which communicate via L1 proof-based bridging rather than synchronous composition.

A key part of that broader direction arriving in this hard fork is the partitioned sequencing commit scheme. It matters even for standalone apps, because for an app model to make practical sense, proving costs have to scale roughly with the app’s own activity rather than with overall DAG activity.

In parallel, the vprogs repo, primarily developed by Hans Moog, is already implementing the runtime layer for these apps. It carries the vprogs name because of where it is aiming to go after this hard fork, but its immediate role is to provide a highly optimized, parallel-centric execution environment for based computation over Kaspa.

Kaspa core will make it a primary effort to make both of these programmability systems approachable in practice: through compilers, SDKs, and runtimes, and by helping external developers navigate the decision process of choosing the right tools.

Already in

A substantial part of the hard fork is already in place:

• extended script-engine opcode support -- the main covenants backbone (KIP-17)
• covenant IDs, allowing easy lineage management as a consensus + engine feature (KIP-20)
• zk opcodes with a zk-verifier precompile subsystem (KIP-16), authored and implemented by Alexander Safstrom, who is also developing SDK support around this area; currently supporting:
  - a flexible Groth16 verifier, allowing arbitrary parameters and verification keys
  - a RISC Zero STARK verifier, already implemented and activated on testnet 12, with the remaining decision being whether to activate it on mainnet
• sequencing commitment access opcode, enabling based applications, i.e. zk systems that fully follow L1 sequencing and cannot add or drop transactions

In parallel to the protocol and tooling work, key PoC milestones from the initial hard-fork kickoff gist are already behind us, including inline zk covenants and based zk covenants with a KAS canonical bridge. Implemented by Maxim, these PoCs were instrumental in driving and validating the shape of the hard fork as it matured.

Finalized these days

Expected feature freeze: April 15, 2026

The following items are being finalized now:

• final script-engine pricing policies (implemented; KIP pending)
• KIP-21, authored by myself and implemented by Maxim Biryukov, now fully implemented with strong performance, and currently pending thorough review
• subnet and gas commitment support, complementing KIP-21

Why the mainnet hard-fork date moved to ~June 5–20, 2026

The hard fork was originally targeted for May 5, 2026 (partly for Crescendo symbolism). However, as Kaspa’s dual programmability landscape came into focus, it became clear that the sequencing commitment architecture had to be finalized correctly before activation, especially for the zk-oriented path.

Once zk circuits and runtimes bind to a sequencing commitment hashing structure, later structural changes become breaking changes. So we prefer to take this extra time and lock in the right design from the start.

KIP-21 is already future-compatible with the CD commitment scheme that will be required by vprogs. It also enables an important property for the current roadmap: a zk application only needs to prove work proportional to its own activity. That is crucial both for the current standalone zk-app roadmap and for future vprogs.

The road from feature freeze to mainnet

Right after feature freeze, we plan to restart the dedicated testnet, TN12, as a clean network containing all final features. This will not try to simulate complex hard-fork activation paths or DB upgrades. It is simply a clean restart with the full final feature set, still over a dedicated branch in the rusty-kaspa repo.

From there, the main engineering effort shifts to merging the long-lived pending branch, with all the accumulated months of work, back into master. This is where the remaining integration work happens: final auditing, closing each and every todo, perfecting hard-fork activation logic, and handling DB upgradability correctly.

The end goal is for the master branch to fully support both pre-activation and post-activation logic in one coherent codebase.

Once that is in place, we will schedule a test hard fork over the long-term TN10, in order to simulate a full mainnet-style transition. That rehearsal is the key step. Once it happens to our satisfaction, we can finalize the mainnet date and hardcode it.

For miners and the ecosystem, the operational story should remain simple: upgrade nodes, and everything that already works should keep working. Node requirements are expected to stay in roughly the same range, with possibly something like 20–50% more disk space usage.

This hard fork also brings new utility, which means new SDKs and APIs will increasingly target the new developer audience. At the same time, classic Kaspa APIs should continue working without change. So we are not in a rush to make every new SDK perfect before the hard fork itself -- that will remain ongoing work.

Toccata marks the point where Kaspa’s high-frequency monetary base layer meets programmability in two layered forms: native L1 covenant systems, and based zk systems built on top of the same foundations.

The remaining work is not about expanding scope further, but about freezing the right interfaces, rehearsing the transition properly, and bringing this to mainnet in a way the ecosystem can rely on, while keeping the underlying L1 lean, sound, and stable.

This post was written with the help of coderofstuff, Shai Wyborski and others

With the successful deployment of the Rusty Kaspa (RK) node software (stable release), and its broad adoption by Kaspa’s P2P network and mining community (~97% of Kaspa blocks are mined via RK nodes), the core open-source development team is now starting to prepare for a hard-fork¹ that will, among other things, increase the block rate of the network from 1 to 10 blocks-per-second (BPS)². In this post, I outline the tentative roadmap for the upcoming hard-fork, hereby named the Crescendo Hard-Fork, what it will likely include, and the process of deploying it.

Overview

At a high level, here’s how we envision the steps needed to implement such an acceleration on Kaspa’s main network. The process involves the following iterative phases:

• Launch & stabilize: Launch a testnet with the desired block rate and related network settings, and work on stabilizing it. This has been accomplished with TN11, the existing 10-BPS Kaspa testnet, which has been operational since January 7, 2024. (Done)
• Identify bottlenecks: Iteratively identify processing bottlenecks and make performance optimizations to lower the hardware specifications required for running a node. (Done)
• Iterative improvement: Repeat the above until the minimal specs are affordable enough and low enough to satisfy the decentralization required for the mainnet. (We are here, getting close to the convergence of this optimization loop. Approximate timeline: ~2 months from now.)
• Enhanced user experience: Once performance requirements are settled, perfect the node software to the level of user experience required by mainnet operators. That is, some minor problems that can be neglected in a testnet setting need to be addressed here (~3 months from now). (Next)
• Additional features: Implement any additional hardfork features and deploy them on TN11. (Target timeline: ~4–5 months from now. Some features might be excluded to fit the timeline.)
• Feature freeze.
• Hardfork version: Implement the hardfork transitioning version
• Deploy transition testnet: Deploy the transition version on TN10 (1 BPS testnet) to simulate the mainnet transition.
• Mainnet deployment with hardfork transitioning activated 1–2 months later

A more detailed walkthrough

Currently, RK developers are busy with preparing a mainnet version that is focused on introducing many mempool features whose necessity was detailed by the KRC-20 beta launch. These include delicate features such as RBF (replace-by-fee) and a fee estimation API, both of which require careful work with ecosystem developers.

After this version is released³, focus will shift to creating a performance oriented version meant to stabilize TN11 nodes. This version will be used to align TN11 participants behind a version which hopefully solves all current processing bottlenecks and provides a smooth operation of the network as a whole.
The main bulk of work would be to merge the following existing PRs:

• Computing GHOSTDAG on higher levels only on-demand while creating a pruning proof. This is a significant yet delicate PR that still requires a thorough review before merging.
• Parallel input validation, introduces finer granularity when processing transactions by validating inputs in parallel.
• Upgrading the KIP9 formula on TN11 to its final form (TN11 was launched with a premature version of KIP9).
• An implementation of KIP10, compounding addresses, allowing microtransactions with KIP9, see here.
• An improved logic for transaction sampling while building block templates

After these features are merged, TN11 will be rolled out with this new version, and run under maximum load for a few weeks. This will allow us to understand the system requirements required to run such a node. If the minimal system requirements are deemed too high, some parameters (such as difficulty adjustment window size and sample rates, finality depth, etc) will have to be adjusted, followed by a few more weeks of testing. Alternatively, further performance cycles might be considered.

During the testing period, work will resume on some other features including:

• Improving and perfecting the IBD process, addressing some edge-cases in the new node sync process that are extremely rare on mainnet, but will be exacerbated with higher BPS and shorter pruning periods.
• Improvements of finality rules and new node headers-proof validation process (KIP7, KIP8).
• Cryptographic receipts (KIP6), a modification that allows a much smaller and simpler proof that an arbitrarily old transaction was confirmed.
• Enabling transaction payloads, which will streamline specifications such as KRC-20.

Once all of the above is completed, we can start with the process of writing a mainnet version of this hard-fork. This version will have to include the logic for transitioning from the current protocol parameters to the new ones. This is an intricate process that will have to be heavily tested and involves making some crucial decisions such as when the HF will go into effect, and whether it should be done gradually or in one hit.

We emphasize that the plan outlined above is tentative. The purpose of this post is not to present a finalized, set-in-stone roadmap, but to highlight that the 10BPS hard-fork is the next major focus for the core team and that significant effort will be devoted to meeting this target. Above all, our guiding principles remain unchanged: network security and stability, and allowing sufficient time for the ecosystem to adapt. In the same spirit, we note that while the above details pertain to the responsibilities of the core developers, the broader ecosystem — including wallet developers, pools, exchanges, block explorers, and others — will also need to make adjustments, and should actively engage in this effort by testing their software components in the 10-BPS testnet.

¹In our context, “hard-fork” refers to a community-agreed and scheduled change in the consensus protocol, rather than a contentious fork resulting from disagreements within the network.

²None of the changes included in this hard-fork will affect user funds or the emission schedule. The increase to 10 BPS will result in ten times more rewards, but the reward per block will be reduced by the same factor, maintaining the same emission rate per second.

³A mempool-focused mainnet release candidate version is expected by the end of this week (~August 25th).

We are excited to announce the first stable Rusty Kaspa (RK) node Release (version 0.14.1).

This is a significant milestone for the Kaspa network, as it marks the point where we shift to a new improved and optimized engine, which can now be built upon and accelerated to its limits.

Approx. 2 years ago, when I first proposed the Rust Rewrite, I dreamed of unleashed performance and superb code quality. Today I can say that the new codebase is of highest quality possible, and that the set of individuals contributing to it is now an elite group of people, forming a decentralized and world-spread core development force.

Currently, as part of the open beta announced a few weeks ago, RK nodes already comprise ~1/4 of the P2P network, and as much as 29% of the hashrate is mined through them.

Going forward, this stable release signifies the point at which we recommend RK as the main software to be running the network.

Switching to RK is crucial for major network-wide future advances such as accelerating mainnet to 10-BPS (10-BPS testnet-11 runs solely on RK nodes), upgrading to Dagknight, supporting smart-contract opcodes, etc. However, it also provides the following immediate benefits to node maintainers:

• Near-constant storage: Unlike golang nodes which only prune transaction data, RK nodes constantly prune headers as well, hence node disk usage is lower and nearly constant.
• Fast sync times: RK heavily utilizes parallelism to accelerate header and block processing. This is mostly notable during IBD where RK nodes enjoy increased processing throughput and are significantly faster.
• RPC software stack: RPC interfaces have an enhanced design and will be extended in the near future (with a fully-featured transaction index being a notable example)

Transition strategy & technical details

We aim for a gradual process where more and more nodes slowly switch to RK. The following provides detailed instructions for the upgrade based on your specific use case:

• Rust open beta participants: Version 0.14.1 contains several stability fixes for issues that have been reported over the beta testing period. It is highly recommended that you upgrade to this version as soon as you can for the reliable operation of your node (if you upgraded to 0.14.1 RC during the last week, there’s no need to take any action)
• Golang node maintainers: Pick a random number between 0–7. Wait this amount of days before you switch your node to RK. Note that RK uses a completely different database, so you'll need to resync the new RK node from the network. If possible, keep the former golang node up and running in parallel to the new node for a stability period.
• Golang archive node maintainers: RK supports a robust archival mode, but a full archive migration process was not deployed yet. If you wish to keep your archive continuous, keep the golang node for now, a DB migration process will be implemented and announced.
• Mining Pools: Pool operators who haven’t experimented yet with the RK node should begin this process and should allocate a small hashrate percentage to be mined through it. Hashrate should then gradually shift entirely to RK nodes. Large pools should coordinate the timing and hashrate percentage with the core development group.
• Exchanges (and other transaction confirmation service providers): Test the RK node in your test environments. It should work as a drop-in replacement to current golang node as it implements the same gRPC API. Get comfortable with running the node and maintaining it. Then gradually move your services to run over it. If you use kaspawallet golang CLI wallet at your backend services, upgrade to latest version (0.12.17) which was just released and is compatible with RK nodes. See the following point as well —
• Wallet developers: Follow KIP9 simplified instructions (disallow sub 0.2 KAS payments; make sure change is above 0.2 KAS by selecting larger/additional inputs if needed). Test your wallets over the RK node. A long term guide with a detailed wallet reference implementation for fully adapting wallets to KIP9 will be published in the coming weeks.
• Normal users (who only access their wallet via web or mobile app): No action needed. Be patient with wallet developers if minor problems occur when making very small payments.

The RK node has a CLI interface which is mostly identical to golang nodes. The following lists any (breaking) CLI changes:

• RPC defaults to localhost (127.0.0.1) so is not accessible externally. To restore golang-like behavior add --rpclisten=0.0.0.0
• UPnP is supported and on by default. This means nodes can be visible publicly even if launched behind a router. To disable UPnP add --disable-upnp
• Config file format has a slightly different structure, see Using a configuration file
• Configurable RAM cache usage: Node maintainers who wish to increase (or decrease) their RAM usage can set --ram-scale=1.0 to a number higher (or lower) than 1.0 respectively. This increases sync and overall node performance by using additional RAM.

Kaspa Next Generation (KNG) & WASM SDK

A rich software stack has already been built over the RK codebase. Subsequent announcements will focus on each of them separately. Here we only bring a brief summary.

KNG: Kaspa NG (KNG) — A feature-rich desktop solution that integrates the RK P2P node as well the ability to connect to the public P2P node infrastructure. KNG includes a Rusty Kaspa wallet implementation, node and network performance metrics, and a real-time Block-DAG visualizer.
KNG makes it easy for any desktop user to contribute to the network topology decentralization by powering up the local P2P node without any extensive knowledge.

WASM SDK: The WASM SDK enables the Rusty Kaspa framework to work within the WASM32 environment, making it accessible from JavaScript and TypeScript. This adaptation allows the RK framework to be used in web browsers, Node.js environments (such as Electron and NW.js), and Chrome browser extensions. The SDK includes essential tools for handling network-focused cryptographic functions, interacting with the RK peer-to-peer (P2P) nodes via WebSocket RPC, and creating wallets.

I would like to personally thank everyone who has contributed to the development and testing of this enormous project, no matter how large or small your contribution has been, and to Yonatan Sompolinsky, for dreaming about 10-BPS and beyond, and being a true inspiration. None of this would be possible without the above-mentioned community of developers and enthusiasts that had formed around this effort ❤️

Summary of events leading to Kaspad version 0.12.7

The attack vector described below resembles some similarity to the bitcoin transaction malleability issue, but is actually a bit different and even reverse in some sense. Exploiting this vector would require intrinsic knowledge of our consensus and codebase, but nonetheless we decided to be precaution and fix this issue as soon as possible despite the short-term hassle. Finding this issue and fixing it is another advantage of the code rewrite to rust acting as an audit process. All solutions below were already gradually applied through the above mentioned version. The final hard-fork kicked in at September 28, 2022, 09:20 UTC at DAA score 27905000.

Background:

Transactions include a per-input sig_op_count field indicating the number of signature operations required to verify the spending of that input. This field is used when calculating the overall mass of a transaction since signature verification is the most costly operation in the transaction verification process.

Problem (discovered by Ori Newman during the Rust rewrite at September 12th):

Transaction hash (as well as transaction id), do not include the sig_op_count field in the hashing process. This means that the Merkle root of all transactions is unaffected by this field, and as a result, nor does the block hash.

Attack vector #1:

A malicious node can easily manipulate sig_op_count to render the block mass too high without affecting the block hash, so that nodes receiving this version of the block will mark this hash as invalid, while others receiving the original block will consider it valid and will mine over it. Even if the recipients of the modified block get the correct block data eventually, it will hash the same, and the block will not be re-checked and will remain invalid. Which will immediately result in a net-split.

Attack vector #2:

A malicious node manipulates sig_op_count with a small change, where it’s still under valid mass, but different from the real number of signatures. The block passes “body in isolation” validation, but when considered by virtual resolver a few things can happen: (i) if it’s a candidate to be a chain block it gets disqualified from chain since the validation logic discovers that it lied about the number of sigs; (ii) when merged by a chain block, this tx will not verify correctly (tx sig engine will expect the wrong number of signatures). This attack vector does not lead to a net-split, however it can lead to a chain-split since nodes disqualify each other’s blocks from being chain blocks.

Permanent solution (#1):

Hard fork such that sig_op_count does get included in the transaction hashing process.

Problem:

HF code must be published at least a week in advance. Leaking this vulnerability to anyone tracking us closely and actually increasing the threat of a net-split in the intermediate period.

Added solution (#2):

In the HF version, we made the following changes immediately apply (aka “the security patch”):

1. Ignore sig_op_count when calculating mass

2. Ignore wrong sig_op_count when validating transactions against past UTXO

This means that as long as we get a majority to adapt this version very fast, then only non-upgraded nodes are vulnerable to the net-split attack.

However this opens the door to possible data spamming by sending txs with many transactions (since no sig_op_count limit until the HF kicks in). This is not too bad since every signature still increases the number of bytes in the signature payload, a quantity which remains under mass limit.

Note: #2 includes some components that can be used to net-split non-upgraded nodes from upgraded ones, however, unlike the permanent solution (#1), this will happen only as a result of an actual attack, so the strategy was to cover as much details as possible during this “sensitive” period.

Added solution (#3):

In the pre-HF changes, we limited the number of actual sig_ops and limited the overall number of tx inputs per block with relatively large constants.

Explanation: since #2 still includes the possibility for an attacker to net-split the minority which did not upgrade, we can temporarily add other constraints that will limit the block mass and thus limit possible spamming. These constraints are already implicitly respected by previous versions, so only a deliberate attacker could have used them.