Rusty Kaspa v1.1.0 was a final node-software release focused on integration, initial-block-download recovery, pruning, storage, and mining connectivity. It added GetVirtualChainFromBlockV2, RocksDB presets, and an in-house Stratum Bridge that remained explicitly beta. Reported performance gains were contributor observations on some machines, not a universal benchmark or new consensus activation.

Key takeaways

• GitHub published v1.1.0 as a final, non-prerelease release after three release candidates.
• VSPC API v2 combined selected-chain changes with accepted transaction data and optional verbosity and confirmation filters.
• IBD catchup and pruning-proof logic were refactored to handle pruning-point movement and reconstruction more predictably.
• Compressed level parents and on-demand higher-level relations targeted lower storage and processing overhead; “up to roughly 3x” applied only to reported header-stage IBD results on some machines.
• Database schema version 6, downgrade risk, Rust 1.88 requirements, and the beta status of the Stratum Bridge were operationally important.

What shipped in Rusty Kaspa v1.1.0?

The official Rusty Kaspa v1.1.0 release notes list four central areas: a new virtual-chain RPC, IBD catchup improvements, performance and storage optimizations, and pruning-proof stability work. GitHub marks the tag as a final release, not a pre-release.

This distinction matters after RC1, RC2, and RC3. A final software tag indicates maintainer release status for that code revision. It does not imply that every bundled component is production-grade: the notes retained the BETA label for the in-house Stratum Bridge.

How did VSPC API v2 change integrations?

GetVirtualChainFromBlockV2 returns removed and added selected-chain block hashes plus accepted transactions grouped by added chain block. Optional dataVerbosityLevel values range from None through Full, with Full as the default. minConfirmationCount can filter added-chain blocks by their distance from the virtual tip.

The previous GetVirtualChainFromBlock remained unchanged, so the new operation was described as non-breaking. Combining chain movement and transaction context can simplify indexers and payment services, but clients still need durable checkpoints, duplicate protection, reconnect behavior, and policies for confirmation changes.

Python users could access the corresponding binding through the separately released SDK. The broader Kaspa Python SDK v1.1.0 analysis explains that client-side layer and its compatibility changes.

What changed in IBD and pruning-proof handling?

Initial block download and catchup were adjusted around pruning-point movement, trusted-body syncing, and transitional states. The release also described guided pruning-proof reconstruction with cleaner per-level context. These changes targeted recovery and maintainability as well as speed.

Pruning lets a node validate current consensus without retaining unlimited historical block data, but proof construction and validation must still preserve the security assumptions required for synchronization. A refactor that passes project review is meaningful engineering evidence; it is not a formal proof that every failure mode or corrupted database state has been eliminated.

What supported the storage and processing gains?

Two changes received specific credit: compressed level-parent data in headers and networking, and on-the-fly reconstruction of higher-level relations when pruning-proof work needs them. The latter replaces continuous maintenance of those relations for every header with targeted computation for a small subset.

The notes say contributors observed up to approximately three-times faster header-stage IBD on some machines. That claim should retain all qualifiers. The release did not publish a controlled cross-platform dataset, hardware matrix, confidence interval, or guarantee. Node operators should compare wall time, disk growth, memory, I/O, and error logs on their own workload before generalizing the result.

What did RocksDB presets add?

Version 1.1.0 added presets for archive and HDD-oriented use cases, a separate write-ahead-log directory option, and cache controls. These controls let operators match database behavior more closely to storage hardware and retention goals.

Presets are starting points, not automatic capacity planning. Archive retention, UTXO indexing, disk latency, available RAM, filesystem behavior, and backup strategy can change outcomes. Measure the node after configuration rather than assuming a label guarantees a particular throughput.

Was the Stratum Bridge production-ready?

The release included Rusty Kaspa’s in-house Stratum Bridge but explicitly called it beta. A Stratum bridge connects mining software to node mining interfaces; beta status signals that operators should expect additional testing, changes, and issue reporting.

The Kaspa Stratum Bridge beta guide covers its role in more detail. Neither inclusion in a final node release nor successful pool testing removes the need for failover, monitoring, version compatibility, and independent operational validation.

What should operators check before upgrading?

The database schema advanced to version 6. The notes say upgrades from older schemas are supported, but a later downgrade to an older node may require deleting the database. Startup from an old schema requires confirmation, or --yes for automation. The workspace also moved to Rust edition 2024 with minimum Rust 1.88 for source builds.

Operators should back up configuration and keys, document rollback procedures, verify disk headroom, test automation prompts, and monitor sync after restart. A database rebuild may be operationally expensive even when funds are not at risk.

Did v1.1.0 activate new Kaspa consensus rules?

The release notes describe node, RPC, sync, storage, and infrastructure work; they do not announce a new mainnet hard-fork activation. Software release status, testnet behavior, and consensus activation are separate evidence categories.

Did the release predict KAS price?

No. Faster sync and easier integration can improve infrastructure, but the release provides no adoption, fee-demand, liquidity, or valuation data. It cannot support a guaranteed KAS price direction.

Frequently asked questions

Was Rusty Kaspa v1.1.0 still a release candidate?

No. GitHub labels v1.1.0 as the final release. Earlier v1.1.0-rc.* tags were pre-releases.

Was the Stratum Bridge final because it shipped in v1.1.0?

No. The release notes explicitly retained the beta label for the bridge.

Does the reported 3x figure apply to every node?

No. It was an up-to observation for header-stage IBD on some contributor machines, not a universal benchmark.

Can an operator freely downgrade after upgrading the database?

Not necessarily. The notes warn that downgrading to older node versions may require deleting and rebuilding the database.

Source and verification note

This article is based on the official Rusty Kaspa v1.1.0 release notes, including final-release status, VSPC v2 fields, sync and pruning descriptions, performance qualifiers, beta labeling, and upgrade warnings. The source does not prove universal benchmark gains, third-party integration correctness, Stratum production readiness, a new hard-fork activation, adoption, or KAS price performance.