The Kaspa VCC v2 data aggregator arrived in rusty-kaspa PR #740 as GetVirtualChainFromBlockV2, also described as VSPC API v2. It lets an observer request virtual-chain changes and per-chain-block accepted transactions through one RPC flow, with incremental verbosity and optional confirmation filtering. This improves integration visibility; it does not change which transactions consensus accepts.

Key takeaways

• The new RPC returns removed hashes, added hashes and accepted transaction data grouped by accepting chain block.
• Acceptance context can include the accepted DAA score, accepting block and sender/source information, depending on verbosity.
• None, Low, High and Full are incremental levels; the final merged behavior defaults an omitted level to Full.
• minConfirmationCount can hold near-tip added-chain blocks back until they meet the requested distance.
• The pull request’s benchmark is useful engineering evidence, not a service-level guarantee for every node or workload.

What is the Kaspa VCC v2 data aggregator?

The primary source is merged rusty-kaspa PR #740, whose branch and title use “VCC v2” while its description uses “VSPC v2.” The shipped operation is unambiguous: GetVirtualChainFromBlockV2. A caller supplies a starting block hash and receives changes in the virtual selected-parent chain after that checkpoint.

The response includes removedChainBlockHashes, addedChainBlockHashes and chainBlockAcceptedTransactions. Each accepted-transaction group belongs to an added chain block and can carry an optional header plus optional transaction fields. This packaging helps an indexer advance a checkpoint while also recording what the selected chain accepted.

The existing GetVirtualChainFromBlock operation remains available, so the addition is designed to be non-breaking rather than a forced replacement.

Why does acceptance data matter on a BlockDAG?

Kaspa processes parallel blocks and then maintains an ordered virtual view. An external service needs more than a stream of newly seen blocks if it wants to know which transactions became accepted through each chain block’s mergeset. Before v2, the PR author says observers could need a parallel added-block listener and a separate sender resolver.

V2 brings that context into one request. The stated use cases include retrieving accepted DAA score, accepting block and sender address for accepted transactions. Exchanges, payment systems and explorers can therefore build a more coherent ingestion loop from a known checkpoint.

“Better consensus visibility” should not be misunderstood. The RPC exposes a richer view of decisions the node has already made; it does not grant the API client a vote, alter ordering rules or increase finality by itself.

How do verbosity levels control response size?

The endpoint can be chatty, so PR #740 replaced granular per-field selection with four top-level levels: None, Low, High and Full. They are incremental, meaning a higher level includes fields assigned to lower levels. Optional models make it possible to omit expensive detail while preserving the response structure.

An early code example on the PR page says the default is None. A later pre-merge commit, 3b7423c, changed the default to Full; the final release specification also records Full. Integrators should follow the merged code or exact release documentation rather than copying an earlier comment from a long-running review.

For production, request only the fields the application stores or validates. Lower payload volume can reduce serialization, transfer and parsing work, but the source does not provide a universal cost for each level.

What does minConfirmationCount do?

The optional minConfirmationCount filters returned added-chain blocks by their distance from the virtual tip. Near-tip virtual-chain membership can change as new blocks arrive, so an indexer may prefer a delayed, steadier view instead of immediately processing every update.

The parameter is an application policy control, not absolute finality. A service must choose a count based on its risk model and still handle removed hashes, retries, duplicate requests and checkpoint persistence. The earlier guide to Kaspa P2P compatibility addresses peer negotiation; RPC confirmation filtering is a separate layer.

What did the performance test show?

The PR includes an integration benchmark under simulated high load. With 20 parallel clients making 20 sequential requests each, it reports 400 requests in 21.994 seconds, 18.19 requests per second, average latency of 372.96 milliseconds, p95 of 881.66 milliseconds and p99 of 1.061 seconds.

With one client making 20 requests, it reports 1.368 seconds total, average latency of 53.28 milliseconds and p99 of 126.07 milliseconds. These figures describe the author’s test setup. Hardware, database state, response verbosity, checkpoint distance, accepted transaction volume and concurrent node work can materially change results.

The patch itself is broad: GitHub reports 70 commits, 69 files, 5,100 additions and 352 deletions, plus six passing checks. That breadth reflects changes across consensus queries, RPC models, gRPC, wRPC, WASM, examples and tests.

How should an integrator adopt VCC v2?

Pin a supported release and store a durable last-processed chain-block hash. Test each required verbosity level against representative traffic, including empty responses, removed blocks, large accepted sets and pruning-boundary recovery. Make ingestion idempotent so replaying a response cannot duplicate credits or records.

Monitor response bytes and latency rather than assuming Full is harmless. Validate sender/source derivation for the transaction types your application supports, and never credit a deposit solely because an untrusted frontend says it was sent. The RPC should be one input to a documented acceptance workflow.

For broader context, the Kaspa 2025 price and fundamentals review separates infrastructure milestones from market performance. A better API can lower integration friction, but it does not guarantee adoption or price appreciation.

Frequently asked questions

Did VCC v2 replace the original RPC?

No. The pull request describes a non-breaking addition, and the existing GetVirtualChainFromBlock remains unchanged.

Is Full always the best verbosity level?

No. It is the final default, but applications should explicitly request the lowest level that contains their required fields and benchmark the result.

Does minConfirmationCount prevent every reorganization?

No. It delays returned added blocks by a chosen distance. Risk falls with an appropriate policy, but the client must still process removed hashes and recovery cases.

Source and verification note

Technical claims come from kaspanet’s merged rusty-kaspa PR #740, including its examples, benchmark, 69-file diff and December 11, 2025 merge. The final default was checked against the pre-merge default-change commit and official release specification because an earlier PR comment was stale. Benchmark results are reproduced as source-reported measurements, not independently repeated performance guarantees. No consensus-security or market claim is inferred.