Rusty Kaspa v2.0.1 is a maintenance release for the Mainnet Toccata release series. It builds on v2.0.0 with RPC and Wasm SDK improvements, operational tooling, node maintenance, and covenant-binding refinements. Mainnet operators are encouraged to upgrade (release).
The release can be used in two ways: as a drop-in update for nodes already running v2.0.0, or as the Toccata upgrade version for pre-Toccata 1.x nodes (release). The underlying Toccata hard fork was introduced in v2.0.0, with mainnet activation scheduled at DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC (v2.0.0 release, Toccata guide).
This makes v2.0.1 a release focused on readiness and usability around the Toccata transition. It does not introduce a separate hard-fork plan. Instead, it improves the software surface around Toccata's new sequencing, lane, SMT, covenant, wallet, and operator workflows.
RPC Support For Toccata Seq-Commit Lane Proofs
The most protocol-facing addition in v2.0.1 is a new RPC method, get_seq_commit_lane_proof(block_hash, lane_key), available through both gRPC and wRPC (PR #961). The method returns the witness a client needs to verify a single KIP-21 active lane against the seq_commit in a block header without running a full node (PR #961).
This relates directly to KIP-21, the Toccata sequencing-commitment design. KIP-21 replaces a single global accepted-transaction sequencing stream with a partitioned sequencing commitment. Consensus maintains active application lanes, commits their lane tips in a sparse Merkle tree, and still exposes one 32-byte commitment through the block header's accepted_id_merkle_root after activation (KIP-21).
In KIP-21, the current lane identifier is the transaction subnetwork_id. The purpose of the design is to support lane-local proofs whose cost tracks the relevant lane's activity instead of total global network activity (KIP-21). This is important for applications and proof systems that only need to reason about one application lane rather than every accepted transaction.
The new RPC returns data such as the SMT proof, optional lane tip and lane blue score, payload and context digest, and parent seq-commit. If a lane is absent, the response can represent non-inclusion rather than inclusion (PR #961). For light clients, SDKs, indexers, and ZK-related applications, this provides an RPC path for retrieving a verifiable lane witness from a node.
SMT Sync Progress Notifications
v2.0.1 adds wallet/core and Wasm notification support for SMT sync progress (release, PR #1047). The change introduces SyncState::SmtSync { processed, total } in wallet/core, detects SMT import progress from node output, exposes an ISyncSmtSyncEvent through the Wasm notification layer, and adds CLI output for SYNC SMT (PR #1047).
The Wasm event is documented as being emitted when a node imports the pruning-point SMT state during Initial Block Download, or IBD (PR #1047). This gives wallets, browser clients, and service interfaces a more specific sync state to display while Toccata-related SMT state is being imported.
The practical effect is clearer status reporting. Instead of treating this phase as a generic sync delay, software can show that the node is importing SMT state and can expose progress through processed and total values.
SMT Database Inspection Tooling
The release adds kaspa-rocknroll, a developer database-scanning crate, and an smt_prune_scan binary for read-only consensus database inspection (PR #990). This is the SMT database inspection tooling included for operators and developers in v2.0.1 (release).
The scanner is designed to inspect stale SMT pruning entries. It resolves appdir-based consensus databases through metadata, skips archival nodes, verifies pruning stability, mirrors the inclusive SMT prune cutoff, and reports stale branch, lane, and score-index entries (PR #990). The implementation also adds read-only RocksDB opening support and a read-only MultiConsensusManagementStore constructor for scanner use (PR #990).
This is operational and diagnostic tooling rather than a consensus-rule change. Its output includes database identity, pruning point, retention checkpoint, cutoff blue score, and stale-entry counts for branch versions, lane versions, and score indexes (PR #990).
Read-only RocksDB access against a concurrently open read-write database is treated as best-effort, and nodes using custom WAL directories should be scanned after clean shutdown when authoritative results are required (PR #990).
User-Lane Transaction Generation Tooling
v2.0.1 improves transaction-generation tooling for user-lane workflows. The rothschild, or roth, tool now includes an lps option for generating transactions that target a runtime per-generated user-lane pool. It also adds a subnet-pool-size option for controlling that pool size (PR #1021).
This is connected to KIP-21 because post-Toccata lanes are based on transaction subnetwork_id. KIP-21 defines valid user lane IDs as a namespace-shaped subnetwork ID with a 16-byte zero suffix (KIP-21).
Generated user-lane transactions use a weighted distribution for the gas field. The stated goal is to usually allow 200 transactions from the same lane within one block under consensus gas-limit enforcement, while also generating cases that reach or exceed limits for test coverage (PR #1021).
This change is mainly relevant for testing and development. It helps generate lane-aware transaction traffic so that user-lane behavior, gas handling, and related tools can be exercised.
Node Sync And Error-Reporting Refinements
The release includes several node maintenance changes grouped under sync and error-reporting refinements (release). These changes are aimed at clearer failures and more robust node behavior around the Toccata release line.
v2.0.1 adds more specific pruning-proof errors, including cases for a pruning proof whose last header at a level is not the computed selected tip and for unexpected header-only pruning-point chain-segment blocks (PR #1053). It also bounds header-only chain segments accepted during IBD using finality depth plus a 2K margin, improves IBD progress handling, tightens transaction-relay message size checks, truncates retained reject reasons for processing and logging, and returns an explicit transitional IBD-state error for an RPC path where route transactions may be unavailable while the sink is missing a block body (PR #1053).
The release fixes a shutdown race in the connection manager. Before the fix, a wakeup send used .unwrap(). If an AddPeer RPC raced with daemon shutdown after the event-loop receiver had been dropped, the handler task could panic. The fix ignores the send error because the wakeup is unnecessary when the loop is already exiting (PR #1029).
The release also fixes Wasm/client transaction deserialization compatibility. It defaults computeBudget on transaction inputs and accepts mass as an alias for storageMass, with tests covering legacy v0 JSON and safe JSON transaction shapes (PR #1052). This aligns with the Toccata guide, which says the older transaction mass field is now named storage_mass in Rust/protobuf APIs and storageMass in JSON/JavaScript APIs, while compatibility handling remains for older JSON forms (Toccata guide, PR #1052).
Covenant Binding Handling In Client And Wallet Components
Toccata includes covenant-related consensus changes through KIP-17 and KIP-20. KIP-17 adds transaction introspection and scripting capabilities, while KIP-20 introduces covenant IDs and covenant-bound outputs carrying a CovenantBinding with an authorizing_input and covenant_id (KIP-17, KIP-20).
v2.0.1 refines the client-side representation of this machinery. kaspa_consensus_client::CovenantBinding now uses a new CovenantBindingInner struct rather than directly wrapping the consensus-core type (PR #935). This addresses a JavaScript and TypeScript usability issue where a getter could return a clone, and a setter on that returned object would update the clone rather than the original object (PR #935).
The same change adds native Rust outputs() and set_outputs() methods for GenesisCovenantGroup, because the Wasm-exposed versions use JavaScript-oriented NumberArray types while native Rust and Python SDK use needs Rust-native types (PR #935). The changes also extend into wallet transaction generation, payment handling, and PSKT conversion paths (release, PR #935).
The result is not a new covenant consensus feature. The consensus model is defined in the KIPs. The release improves how covenant-bound data is represented and manipulated in client and wallet-facing code.
Operator Impact
For operators, the direct action is to upgrade to v2.0.1 if preparing for Toccata. Mainnet operators are encouraged to upgrade, and v2.0.1 can be used either from v2.0.0 or from pre-Toccata 1.x nodes (release). The release cadence is also expected to move toward smaller, more frequent updates so improvements can reach operators and builders faster.
The existing Toccata operational guidance remains relevant. The Toccata guide says node operators should upgrade before activation, that the database upgrade is one-way, and that returning to an earlier version after upgrading the database requires resyncing (Toccata guide). It also recommends that exchanges, miners, pools, explorers, wallet operators, and other service providers test their infrastructure against Testnet-10 before mainnet activation (Toccata guide).
Pending Work
Additional ZK SDK APIs and UTXO pagination support are already pending for the next version. These items should be treated as pending work, not as features delivered in v2.0.1.
In summary, v2.0.1 strengthens the Toccata release series around proof access, sync visibility, SMT inspection, user-lane testing, client compatibility, covenant-binding SDK behavior, and node robustness. It is a maintenance and readiness release for Toccata rather than a separate protocol milestone.