Kaspa development this week, October 11 to 18, focused on making network data easier for wallets and applications to use. A paginated query for spendable outputs reached the main codebase, work began on covenant-specific searches, and nodes gained a storage profile for slower disks.
Developers also merged fixes for JavaScript clients and reusable support for embedded devices. The practical theme was access: helping software retrieve the data it needs without overloading a node, duplicating core code, or locking future applications into an awkward interface.
The week in one minute
- Kaspa’s main Rust implementation merged paginated UTXO queries, allowing large result sets to arrive in smaller, controlled batches instead of one potentially unwieldy response. This also lays groundwork for covenant searches. Source
- A draft covenant ID index prompted a detailed review of database efficiency, pagination, query limits, and future RPC compatibility. The feature is not finished or approved. Source
- A tested low-I/O database profile reached the master branch, aiming to help nodes running on hard drives or lower-tier solid-state drives. Source
- Fixes for transaction generation, WebAssembly fee calculations, and covenant-aware JavaScript clients also reached master, although packaged releases will come later. Source
- A merged library change should reduce the amount of custom non-native code required by firmware and other constrained platforms. Source
The big story: Large coin queries now fit into manageable pages
Imagine asking a library for every book matching a broad subject. Returning the entire collection in one pile would be slow, wasteful, and difficult to resume if the connection failed. A better system hands over one shelf at a time and includes a marker showing where to continue.
Kaspa can now apply that model to UTXOs. A UTXO, or unspent transaction output, is a piece of value recorded on the network that has not yet been spent. Wallet balances and future transactions are built from these outputs.
The newly merged work lets software request UTXOs in pages. Instead of expecting a node to return every matching output at once, a client can process a limited batch and then request the next one. The change was merged into the rusty-kaspa master branch after initial work and review from several contributors. Source
For users, this is mostly plumbing, but useful plumbing. Wallets and applications should be able to handle large collections more predictably, with less pressure to load everything into memory in one operation. Pagination also gives developers a cleaner way to build services that may need to resume long queries.
The merged query is not the end of the work. Developers suggested deprecating older, non-paginated methods in a future release and removing them after another two or three releases. That migration has not been confirmed, and wallet framework changes may be required first. A tracking issue was created for the possible transition. Source
More importantly, pagination establishes a base for the next requested feature: retrieving UTXOs by covenant ID.
A covenant is a programmable rule that restricts how an output may be spent. Its ID identifies the particular rule involved. Applications built around covenants may need to ask a node, “Which unspent outputs currently belong to this rule?” The pagination merge makes such a query easier to structure, but it does not itself provide the finished covenant lookup.
That distinction matters. One useful building block is merged. The covenant index being built on top of it remains a draft under design review.
What else moved forward
Covenant lookup is wanted, but its safest interface is still unsettled
The proposed covenant ID index could make it much easier for applications to discover outputs controlled by a particular programmable rule. That is the immediate goal, and developers described it as a feature receiving substantial demand.
The debate this week was not about whether basic covenant lookup is useful. It was about how much the first version should do and how its database layout will shape later features.
One design stores an SPK as part of the database key. An SPK, short for script public key, is the locking condition attached to an output, often associated with who or what can spend it. Putting it in the key could let a node jump more directly into selected parts of the data when the caller already knows which SPKs matter. Source
The alternative discussed was storing the SPK as a value and filtering results while iterating through outputs for a covenant. That could simplify pagination and reduce the number of fields exposed through the remote procedure call, or RPC, which is the interface wallets and applications use to ask a node for data. However, it may also require scanning more records.
The discussion eventually clarified that keying by SPK can avoid some unnecessary work in specific searches. It did not settle whether those searches represent the main expected use. One view was that most callers will know the covenant ID but not the SPK, making a straightforward “get outputs for this covenant” call the priority. Source
A reviewer also raised a safety concern about where the draft applies its result limit. If filtering happens before the limit is counted, a carefully constructed request might force the database to inspect far more entries than the number returned. The reviewer proposed limiting the underlying database operations, not merely the successful matches. This was a review finding about draft code, not evidence of an exploited production flaw. Source
For developers: Open questions include whether the covenant store should depend on the existing UTXO index, whether duplicating roughly nine extra bytes per record could avoid secondary reads, and whether the RPC should accept SPK ranges or an explicit list. The key order also involves a DAA score, an ordering value used to locate outputs within Kaspa’s block history. More precise seeking may reduce scanning, but frequent seeks could create their own cost.
The current takeaway is clear: covenant lookup is still being designed. Developers appear willing to start with a minimal version, but query bounds and RPC compatibility need attention before the draft can be treated as settled. Source
Slower disks gained a node profile tuned for lower I/O
Node operators using hard drives or inexpensive SSDs may benefit from a new lowio RocksDB profile. RocksDB is the storage engine used to keep node data on disk, while I/O means the reads and writes performed against that storage.
The contributor behind the profile reported testing it locally and on several virtual private servers before opening the change. By October 14, the profile was reported as present in the rusty-kaspa master branch. Source
No benchmark figures were supplied in the archive, so the improvement should not be reduced to a universal speed claim. Its stated purpose is narrower: improve behavior on storage systems where disk operations are the limiting factor.
For node operators, the practical implication is broader hardware tolerance. The profile is merged into master, but the archive does not identify a packaged release containing it.
JavaScript covenant tooling was fixed before its next packaged release
A second group of changes in master addressed the transaction generator, fee calculations in WebAssembly, and support for WebAssembly clients interacting with covenants. WebAssembly, commonly called WASM, lets Kaspa’s Rust-based functionality run in environments such as JavaScript applications.
These fixes matter because an application must estimate fees correctly and construct valid transactions before it can safely interact with programmable spending rules. The underlying work is in master, but JavaScript users cannot yet obtain it through a new prebuilt package.
Developers who need the fixes immediately must build the WASM package from source. Everyone else must wait for a future release that publishes the package directly. Source
The status is therefore mixed but straightforward: the code has landed, while convenient distribution has not.
Embedded builders can reuse more of Kaspa’s native libraries
Another merged pull request reduces the amount of non-native support code that firmware and other platforms without Rust’s standard library need to create themselves.
This is mainly a developer-facing improvement, but it could lower the effort required to bring Kaspa functionality to constrained or specialized devices. Instead of rebuilding pieces around the core libraries, embedded developers can rely more heavily on code already maintained within rusty-kaspa. Source
The archive confirms the merge, but it does not describe specific devices, products, or release timing. The immediate result is a stronger foundation, not a newly announced hardware feature.
What is decided, and what is not
Completed or confirmed
- Paginated UTXO querying was merged into
rusty-kaspamaster. Source - The low-I/O RocksDB profile was reported in master after testing on local and hosted systems. Source
- Transaction generator, WASM fee, and covenant-client fixes reached master.
- The embedded and non-standard-platform library work was merged. Source
Proposed or still under review
- Searching UTXOs by covenant ID is not yet a finished feature.
- The covenant index’s storage independence, key layout, filtering model, and query limits remain design questions.
- Deprecating older UTXO query methods over two or three releases is a suggestion, not a confirmed schedule. Source
- KIP-24 had remaining local review comments to check, so the archive does not support calling it merged. Source
- Prebuilt JavaScript packages containing this week’s WASM fixes await a future release.
What happens next
- Watch for a revised covenant index draft that makes database iteration limits explicit.
- Look for a decision on whether SPKs belong in the database key and how callers should specify them.
- Expect work on the basic “get UTXOs by covenant ID” path before optional filtering grows more elaborate. Source
- Watch for wallet framework updates and a formal decision on deprecating older, non-paginated queries.
- Look for a packaged WASM release so JavaScript users can obtain the merged fixes without building from source.
This week delivered the first half of an important improvement: Kaspa can now return large UTXO sets in orderly pages. The next half is harder. Covenant-aware applications need equally practical searches, and the current review is testing whether those searches can remain efficient, bounded, and compatible before their shape becomes difficult to change.