Kaspa R&D from September 20 through September 27 centered on two practical problems: helping nodes synchronize reliably, and helping wallets retrieve large sets of transaction outputs without asking for everything at once.
Rusty Kaspa 2.1.0 delivered the finished work, including chunked downloads and broader security hardening. Meanwhile, developers narrowed the design of a paginated UTXO query, but did not finish or release it during the covered week. That distinction matters: one improvement is ready for operators, while the other remains active engineering.
The week in one minute
- Rusty Kaspa 2.1.0 was released. It breaks large initial-sync transfers into 20 MiB chunks, adds stricter safety limits, and remains compatible with nodes using the previous peer-to-peer protocol.
- Node, mining, and infrastructure operators were strongly encouraged to upgrade. The release includes defenses against denial-of-service attacks, arithmetic overflow risks, and invalid data.
- A paginated UTXO query moved closer to a lean design. Instead of returning a potentially huge result in one response, it would let clients retrieve manageable pages using a cursor.
- Tests challenged an early ordering optimization. Preserving the caller’s address order was nearly 15% faster in one short-page benchmark, while sorting helped a different full-scan case by about 6%.
- Several pagination details remained open. Developers still discussed how much work the server should do, how clients should handle completed addresses, and how to represent the cursor.
The big story: Kaspa 2.1.0 divides heavy node sync into safer pieces
Imagine moving house with one enormous box. If the box is too large for the doorway, the entire move stops. Several smaller boxes take more trips, but each is easier to carry, retry, and control.
Rusty Kaspa 2.1.0 applies that basic idea to a node’s initial synchronization. A new node must download enough network history and supporting data to catch up. This process is called Initial Block Download, or IBD. Some of its payloads can become large enough to encounter message-framing bottlenecks or timeouts.
The new release streams large IBD payloads in 20 MiB chunks instead of treating them as single oversized messages. The change covers pruning-point proofs, headers, and trusted data. In plain English, these are pieces of evidence and history a node uses to establish an up-to-date view of the network.
This is part of P2P Protocol Version 11. P2P means peer-to-peer, the protocol nodes use to communicate directly with one another. Importantly, Version 11 remains backward-compatible with Version 10 peers, so the release announcement did not describe a sudden network-wide compatibility break.
For operators, the practical goal is fewer sync failures caused by oversized transfers. Overall safety limits and transfer timeouts remain in place, so breaking data into chunks does not mean accepting an unlimited stream. Rusty Kaspa 2.1.0 is a completed release, and its announcement strongly encouraged node, mining, and infrastructure operators on mainnet and testnets to upgrade (source).
Security work went beyond synchronization
The release also tightened limits on peer messages and blocks to guard against denial-of-service attacks, where abusive traffic attempts to exhaust a node’s resources. Developers completed a workspace-wide audit of arithmetic operations to reduce overflow risks, strengthened consensus validation, and improved the stability of the Stratum bridge used in mining infrastructure.
These are defense-in-depth changes. That phrase means adding several protective layers so one weakness is less likely to become a system-wide failure. The announcement did not claim that every possible attack had been eliminated. It described narrower limits, safer arithmetic, and stricter checks that collectively make nodes harder to disrupt.
The release also separated Kaspa’s zero-knowledge tooling into a standalone software package. A zero-knowledge proof lets one party prove that a computation or statement is valid without exposing all of the underlying information. The new package supports generating verifiers for RISC Zero Groth16 and STARK proofs, adds controls against oversized inputs, and addresses cross-platform build problems.
For developers: The package is named kaspa-txscript-zk-sdk. It supports dynamic or static image IDs and generates proof-verification scripts. This extraction makes the tooling independently reusable, but the archive does not establish that any particular application has adopted it yet.
The takeaway is concrete: Version 2.1.0 is available now, its largest operational change targets more reliable initial synchronization, and its security improvements cover several independent parts of the node.
What else moved forward
Wallets could retrieve large balances one page at a time
The week’s main unfinished effort was a new version of Kaspa’s UTXO query. A UTXO, or unspent transaction output, is a piece of value created by a transaction that has not yet been spent. Wallets inspect UTXOs to determine what funds they can use.
The existing version does not paginate its response. Pagination divides a large result into smaller pages, much like loading the next page of search results instead of downloading every match at once. The proposed second version would return a cursor, a marker telling the client where the following request should resume.
That change matters most when a wallet or service tracks many script public keys. A script public key, shortened to SPK in the discussion, defines the conditions under which an output can be spent and often corresponds to what users think of as an address.
Developers broadly agreed on the core purpose: clients would loop through multiple requests, passing each returned cursor into the next request. This could make large scans more manageable and allow a client to resume from a previous checkpoint rather than repeat as much work (source).
What was not settled was the exact contract between client and server. Should the node sort the requested SPKs? Should it remove duplicates? Should a client omit SPKs that earlier pages have already completed? The conversation increasingly favored respecting the caller’s supplied order, but some server-side filtering questions remained active at week’s end.
For developers: The emerging lean model was described as no sorting, no iterator bounds, and no deduplication, with a length check when unsafe RPC mode is disabled. The cursor would likely become its own structured object, keeping fields such as a transaction outpoint together. These were design positions in discussion, not a reported merge or release (source, source).
For users, the promise is simpler than the debate: wallets could fetch extensive account histories in manageable portions. The feature was requested by integrators, but it was still being refined.
Measurements changed the ordering decision
The developers did not rely only on intuition when considering whether the server should reorder SPKs. A benchmark over one million UTXOs compared different query shapes.
Global iterator bounds produced almost no benefit for sparse queries or short pages. They improved one contiguous scan of 256 SPKs by 3.6%. Sorting made complete sparse scans about 6% faster, but preserving the submitted order made a 32-entry page drawn from 256 SPKs 14.9% faster (source).
Those figures do not prove that one order will always win. They show that an optimization can help one workload and hurt another. Since pagination often serves short pages, the test weakened the case for imposing server-side sorting. One participant then agreed that using the submitted order appeared preferable.
This was a useful result, not a completed product decision. The implementation’s implicit ordering was later reported as removed, but the wider pull request still had open cursor and filtering questions (source).
The broader lesson is that “optimized” depends on the workload. Here, a simpler contract may also perform better for an important use case.
Reliable wallet recovery remains a design tension
Pagination raised a second question: how can a wallet know that the network view did not change while it was moving through several pages?
Kaspa can reorganize recent history, commonly called a reorg, when the network’s accepted ordering changes. One participant suggested returning a network-state reference with each cursor so a client could identify which view produced its UTXOs and repeat any affected range.
Another proposed flow already available to wallets: start listening for SPK notifications, run the full cursor-based scan, then apply the changes received while scanning. The command-line wallet was described as using an initial full scan plus notifications to maintain a nearly immediate complete state. After losing its connection, it can repeat that process or recover from a prior checkpoint with a safety margin (source, source).
The disagreement was about resilience and complexity, not about whether wallets need correct balances. Notification-based designs can be responsive, but a missed notification may be difficult for sensitive applications to detect. Checkpoint-based calls can make recovery more explicit, but may require extra node support.
No new checkpoint mechanism was agreed this week. Developers treated it as a possible later enhancement rather than a blocker for basic pagination. The immediate target remained the paginated query itself.
Covenant-based lookup is wanted, but comes next
Developers also discussed a follow-up endpoint for finding UTXOs by covenant ID. A covenant is a spending rule that restricts how an output may be used in future transactions. Its identifier could let an application locate outputs governed by a particular rule even when their SPKs change during execution.
The feature was described as much requested, and one developer offered to move to its storage implementation after completing pagination. The proposed database layout remained open, including whether the DAA score or SPK should come first in the key. A DAA score is a measure tied to Kaspa’s accumulated proof-of-work progression and can help queries follow network history.
The stated primary goal is lookup by covenant ID, with SPKs expected to change in many non-static cases. That observation favored placing the DAA score before the SPK in storage, but the participants deferred the decision to a separate design discussion (source, source).
The feature therefore has demand and a likely next owner, but no reported implementation or release in this archive.
What is decided, and what is not
Completed or confirmed
- Rusty Kaspa 2.1.0 was released with P2P Protocol Version 11, chunked IBD transfers, the standalone zero-knowledge SDK, and broader node hardening (source).
- Protocol Version 11 retains compatibility with Version 10 peers.
- The pagination implementation stopped implicitly reordering supplied SPKs (source).
- Review comments on the pagination work were described as minor, with no remaining blocker identified by one reviewer (source).
Proposed or still open
- The paginated UTXO endpoint was not reported as merged or released.
- Developers had not finalized whether clients must remove already-traversed SPKs between requests or whether the server should handle that step.
- A structured cursor had support in the discussion, but its final RPC layout was not confirmed.
- More explicit checkpoint or reorg information was deferred rather than solved.
- UTXO lookup by covenant ID remained a follow-up feature, with its storage order still awaiting a dedicated discussion.
What happens next
- Watch for the pagination review to close and for confirmation that the endpoint has merged or shipped.
- Look for a final decision on whether clients or nodes filter SPKs already covered by earlier pages.
- Expect the cursor’s public structure, including how it represents transaction outpoints, to receive further attention.
- Watch for a separate covenant-ID lookup discussion and a decision on its database key order.
- Operators can evaluate and deploy Rusty Kaspa 2.1.0 now, following the release’s upgrade recommendation.
This week produced both sides of protocol engineering: a release that operators can use today, and a seemingly simple wallet improvement whose edge cases still matter. Chunked sync is delivered. Paginated wallet scanning is closer, but its real milestone will be a stable contract that clients can adopt without guessing.