From September 13 through September 20, Kaspa developers focused on three practical questions: how wallets should retrieve large amounts of coin data, how Argent should reject invalid transaction groups, and whether a new cryptographic construction performs well enough to justify deeper review.
The wallet discussion carried the widest consequences. Pagination lets software fetch a large result in smaller pages, but dividing many addresses into pages can leave each address current to a different point in network history. The API works, yet using it correctly may require more knowledge than its callers should need.
The week in one minute
- A debate over paginated wallet queries exposed a synchronization trap: batching many addresses is efficient, but the resulting data can become unevenly current.
- Developers compared single-address requests, fixed checkpoints, and more flexible per-address ranges. No final design decision appeared in the archive.
- An Argent pull request covering transaction-group validation rules was reviewed and merged, with a possible follow-up proposed for clearer construction errors.
- A revised LtHash cryptographic design entered shadow testing on two development-network nodes. It is explicitly unaudited and unreviewed.
- Demand is rising for queries that find coins by covenant ID, which makes a sound pagination model more important.
The big story: Wallet pagination works, but its flexibility can make wallets fall behind
Imagine a wallet with thousands, or even a million, addresses. Asking a node for every coin connected to all those addresses in one response could be unwieldy, so the node returns pages. A cursor acts like a bookmark, telling the wallet where to continue.
The coins being retrieved are UTXOs, or unspent transaction outputs. Each UTXO is an individual piece of spendable value that has not yet been used in another transaction.
The hard part is not producing the next page. It is deciding what the completed set of pages actually represents.
Kaspa developers discussed a proposed replacement for GetUtxosByAddresses that would support cursors and pagination. One approach allows a wallet to submit many addresses together, set a historical range, and keep requesting pages until that range is complete. This preserves batching, which can reduce repeated node work and ease migration from the existing API.
The problem appears when the wallet wants to run the next update.
One request can produce many different “latest” points
Kaspa’s DAA score is a measure of the network’s progression that developers can use to order or bound data. In this discussion, it served as a checkpoint for deciding how far a wallet had scanned.
When many addresses share one paginated stream, the first address may be processed at an earlier network point than the last. By the time a large scan finishes, the network may have advanced substantially.
Maxim Biryukov argued that the next scan must then begin from the oldest point to avoid missing information. That causes the wallet to download data it already knows for addresses that were scanned later. With large or unevenly used address sets, the amount of refetching can depend on where those addresses fall in the ordering source.
Put simply, the wallet eventually catches up, but it may keep rereading part of the book.
IzioDev summarized the consistency concern another way: for a fixed set of locking scripts, the DAA value carried by the cursor can move backward between fetches source. A locking script, called a script public key or SPK in the discussion, defines the condition that must be satisfied to spend a UTXO.
Single-address streams are simpler, but batching is cheaper
Biryukov proposed forcing each stream to cover one address and omitting an explicit upper DAA bound. Each address would then have its own cursor and clearly defined freshness point. That makes the client’s next step easier to understand and removes some filtering logic.
Ds defended multi-address batching. A normal wallet may have a very large address set, and grouping addresses into parallel paginated calls could be more efficient than repeatedly asking the node about one address at a time. The current design can already serve a single address when clients need that behavior source.
That leaves a real API trade-off:
- Single-address streams provide simpler state and clearer freshness.
- Multi-address streams reduce requests and preserve efficient batching.
- A flexible API supports both, but callers must understand how to choose ranges and checkpoints.
The debate showed that flexibility alone is not the same as usability. Biryukov noted that even he had not initially considered using an upper score to make snapshots consistent, though he suggested a library or software development kit could hide that complexity source.
A fixed checkpoint helps, but it accepts lag
Ds described a straightforward wallet flow: choose a DAA checkpoint behind the network tip, paginate all selected addresses up to that fixed point, then use it as the starting point for the next completed range source.
This gives the wallet a coherent operating model. It can ignore changing network conditions until it completes the current scan. However, a very large wallet may still finish with data that is well behind the live network. Biryukov called this an “always lagging approach” source.
Developers also warned against presenting a DAA distance as a security confirmation. Ds said it should be described as a DAA threshold representing the age or staleness of a UTXO, not as proof of transaction security source. Wallets already apply local “maturity” heuristics during periods when newly observed UTXOs remain undependable, according to IzioDev.
For developers: One possible extension would accept separate (from_daa, to_daa) ranges per address. That could advance each SPK independently while retaining batching, but Ds suggested treating it as follow-up work rather than expanding the current pull request.
No final choice was recorded. The clearest outcome was the problem definition: a simple batched scan can be consistent at a fixed checkpoint, but it may lag or refetch data; per-address progress is cleaner, but potentially more expensive for nodes and clients.
What else moved forward
Argent merged validation rules, but clearer errors may need a follow-up
Argent’s pull request 63 completed review and was merged this week. Michael Sutton applied a small compilation fix left over from the merge process, reviewed the change, made wording adjustments, and added a static fixture for rule 6 before merging it source.
The discussion included terminology for entries that can participate without consuming another input or being designated as another entry’s leader. Such an entry performs no group-wide checks. IzioDev suggested describing this as independent participation, while Sutton preferred the more distinct “batching” label. The archive does not establish a broader terminology decision.
A practical follow-up remains open. Sutton suggested adding rules 5 and 6 to the runtime builder as pre-checks. That would let bad constructions fail with a clear, targeted error instead of a generic VerifyError source.
For builders, the distinction is useful: the validation work is merged, but better error reporting was only proposed.
Covenant queries add pressure for dependable pagination
Developers reported rising demand for getUtxosByCovenantId. A covenant is a rule attached to coins that restricts how they may be spent; a covenant ID gives software a way to identify a particular set of such rules.
A query by covenant ID could potentially cover many UTXOs across the network, so returning everything at once may not scale well. IzioDev therefore connected that demand to the pagination work, saying the proposed query would benefit greatly from it source.
Ds suggested that a covenant-specific call might justify a different index ordering, potentially putting DAA information before the locking script to support global covenant searches. He also considered that outside the scope of the current address-pagination pull request source.
The takeaway is not that covenant lookup has been approved. It is that another likely consumer of pagination has appeared, raising the cost of getting the underlying cursor model wrong.
A faster cryptographic candidate entered shadow testing, not production
Aglovale reported additional benchmarks of several cryptographic options before pivoting the LtHash experiment to a construction using LtHash (1024,16), B2b-512, and two ChaCha20 instances.
The design splits a 512-bit root between two ChaCha20 instances, with each producing half of the resulting state. Aglovale reported that this raised the seed funnel from roughly (2^{128}) to (2^{256}) while keeping LtHash faster than MuHash in the benchmarks performed source.
Those results are preliminary. The construction has not been audited or reviewed. It is running in shadow mode on two development-network nodes, meaning it can be compared against existing behavior without becoming the authoritative production path.
This week therefore produced benchmark evidence and live comparison data, not a security endorsement or deployment decision.
What is decided, and what is not
Completed or confirmed
- Argent pull request 63 was reviewed and merged.
- Its merge included wording changes and a static fixture for rule 6.
- The revised LtHash candidate is running in shadow mode on two development-network nodes.
Proposed or still under discussion
- Whether paginated UTXO queries should favor one address per stream or preserve multi-address batching.
- Whether SDKs should hide checkpoint and cursor complexity from wallet developers.
- Whether future requests should support a separate DAA range for every address.
- Whether covenant-ID lookup should use a differently ordered index.
- Whether Argent’s runtime builder should pre-check rules 5 and 6.
- Whether the LtHash construction is secure enough to advance beyond experiments.
What happens next
- Watch for a concrete decision on the address-pagination API, especially its default behavior and cursor semantics.
- Look for documentation or SDK logic that turns fixed DAA checkpoints into a safe, repeatable wallet flow.
- See whether per-address ranges become a follow-up proposal rather than part of the current pagination work.
- Watch for an Argent change that converts generic verification failures into clearer builder errors.
- Expect more LtHash comparison results, followed by review or audit work before any stronger conclusion is justified.
The week’s central lesson is simple: fetching wallet data in pages is easy; making every page efficient, current, and difficult to misuse is not. The next meaningful step will be an API decision that gives ordinary wallets a clear path without closing off higher-volume use cases.