Kaspa VSPC confirmations became configurable in Rusty Kaspa through a minimum-confirmation field on GetVirtualChainFromBlock. The August 2025 change lets indexers and exchanges request virtual-chain blocks only after a chosen blue-depth threshold, reducing repeated processing near the tip without turning a confirmation count into absolute finality.

Key takeaways

• Pull request 667 added an optional minConfirmationCount to the virtual-chain-from-block RPC flow.
• The server measures confirmation distance using the virtual sink’s blue score and each candidate chain block’s blue score.
• Waiting for more depth can reduce tip-related I/O, but it also delays when an integration sees newly added chain blocks.
• The change covered core RPC models, gRPC, WASM interfaces, the CLI, service logic, and integration tests.
• Integrators still need checkpoints, idempotent writes, rollback handling, and release-compatible clients.

What are Kaspa VSPC confirmations?

VSPC is shorthand for Kaspa’s virtual selected parent chain, the chain-oriented view that applications can use to process an ordered stream from the BlockDAG. GetVirtualChainFromBlock asks a node for changes after a known block, including added-chain hashes and any removed-chain hashes that an integration must reconcile.

Near the virtual tip, that view can change as new blocks arrive and the selected-parent path updates. The motivating GitHub issue 666 described indexers polling while already current and repeatedly processing removed entries caused by ordinary reorganizations around the tip. Its proposed remedy was to return only chain blocks that had reached a requested blue-depth distance.

This feature concerns an application’s consumption boundary. It does not change which blocks Kaspa consensus accepts, how miners construct blocks, or how the virtual chain itself is selected.

What did pull request 667 add?

The merged Rusty Kaspa pull request 667 added 134 lines and removed 14 across 16 files. Its request model gained an optional unsigned 64-bit min_confirmation_count field. The gRPC schema exposed the corresponding optional field, and the WASM TypeScript interface added minConfirmationCount?: number.

The command-line RPC module also parsed an optional count. A bundled Node.js example demonstrated two calls: one requesting a depth of 30 and another omitting the value. The interface documentation stated that an omitted value is interpreted as zero.

The breadth of the diff matters because an RPC capability is only useful when its wire formats, native model, browser bindings, server implementation, examples, and tests agree on the field’s meaning.

How does the minimum count work?

The service first obtains a virtual-chain batch from the supplied start hash. When a positive minimum is present, it reads the current sink blue score. It then examines added blocks from the newest end of the batch, loads each header, and compares that header’s blue score with the sink score. Blocks inside the requested tip window are withheld from the returned added list.

In practical terms, the integration deliberately stays behind the latest virtual tip. On a later poll, previously withheld blocks can be returned once sufficient distance has accumulated. The server uses saturating subtraction, so the distance calculation cannot underflow if an unexpected ordering reaches that expression.

The count is a protocol-specific depth filter, not a wall-clock promise. Ten blocks do not mean exactly one second of elapsed time, and a numeric threshold should not be marketed as irreversible settlement.

Why would an indexer or exchange use it?

An indexer commonly stores block-to-transaction relationships, address activity, balances, and derived analytics. Reprocessing the newest chain segment can generate database reads, reversals, cache invalidations, and downstream events. An exchange may similarly want a quieter boundary before crediting a workflow.

By requesting a minimum depth, an integration exchanges freshness for stability. A larger value generally means later data and less exposure to routine movement at the tip; zero produces the most current response. The correct setting depends on the product’s risk model, latency goal, transaction value, database design, and ability to reverse derived state.

This trade-off should be explicit. A wallet display, public explorer, merchant checkout, and custodial crediting system need not use the same threshold.

What backward-compatibility work was included?

The binary RPC request serializer advanced its message version from one to two and wrote the optional field. During deserialization, version-one messages map the new value to None, while newer messages read it. That design allowed older serialized requests to remain understandable instead of requiring the missing field.

The change also threaded the parameter through the Rust RPC trait and gRPC conversion code. An integration test requested a minimum count of one and asserted that a newly created chain block was not yet returned. These details provide stronger evidence than the pull-request title alone because they show the intended behavior across interfaces.

Compatibility is still a release-management question. Operators should pair server and client versions supported by the release they deploy, verify generated bindings, and test against a controlled network before changing production credit logic.

What limitations remain?

Minimum confirmations reduce exposure to the newest added-chain blocks; they do not remove the need to process removed-chain hashes or make a consumer database self-correcting. A client can crash between writes, repeat a request, begin from a stale checkpoint, or encounter an RPC timeout. Every state transition should therefore be idempotent and recoverable.

An integration should persist its last durable block reference, commit related records atomically where possible, deduplicate transactions, and make rollback paths observable. It should also alert when the processed head falls unusually far behind the node.

For related maintenance context, see Rusty Kaspa and Rust 1.89 and the rare UTXO-index overflow fix.

Frequently asked questions

Does minConfirmationCount change Kaspa consensus?

No. It filters which already computed virtual-chain additions the RPC returns to that caller. Consensus behavior is unchanged.

Is a higher confirmation count always better?

No. It can reduce tip churn but adds latency. The appropriate value depends on the application’s risk and user-experience requirements.

Can an indexer stop supporting rollbacks after enabling it?

No. It should continue handling removed-chain data, retries, stale checkpoints, and other recovery cases.

Source and verification note

The primary source is merged kaspanet/rusty-kaspa pull request 667, merged August 15, 2025. Behavioral intent was cross-checked against issue 666, while implementation claims were verified in the RPC model, service, protobuf, WASM interface, example, and integration-test diffs. This is technical education, not a guarantee of finality or investment performance.