Kaspa developers spent October 5 to 11 testing a practical improvement for integrations: retrieving large sets of unspent transaction outputs in manageable pages. The full flow worked as intended, including migration, which gives wallet and service builders an encouraging result without pretending the work is complete.
The week also brought a wider debate about Argent contract safety. Developers considered whether the compiler should prevent certain mistakes, or whether a separate auditing tool should warn authors without restricting complex applications. Alongside that debate, a real multi-actor application exposed questions about code size, imported artifacts, and trust.
The week in one minute
- UTXO pagination passed an end-to-end test, including migration, and gained a JavaScript example. This could make Kaspa integrations easier to operate.
- A proposed fix addresses WebAssembly compatibility and a database iteration edge case, but review comments remain pending.
- Argent developers debated how to catch missing authorization checks without making the compiler too restrictive.
- A separate contract-auditing tool emerged as the possible middle ground, but it remains an idea rather than a finished feature.
- Testing a larger multi-actor application revealed roughly 1 KB of extra generated code, apparently caused mainly by rebuilding the full state.
The big story: Large UTXO lists can now be tested one page at a time
Imagine asking a library for every book in a large collection and receiving the entire catalogue in one enormous response. That may work for a small library, but it becomes awkward as the collection grows. A page-by-page request is easier for both the library and the reader to handle.
That is the basic purpose of UTXO pagination. A UTXO, or unspent transaction output, is a discrete piece of value that has been created by a transaction and remains available to spend. Wallets, explorers, and other integrations may need to retrieve many such records. Pagination divides that result into smaller batches instead of returning everything at once.
This week, IzioDev reported testing the complete flow from end to end, including migration from the previous database setup. The result was direct: it “works as intended.” A JavaScript example was also added, giving integrators a more concrete reference for using the feature.
That matters because infrastructure work is valuable only when outside software can use it reliably. One participant said the feature would “help a lot in integrations,” reflecting the practical goal: make large data requests easier for services to consume and manage.
The migration test is especially important. A feature can behave correctly on a fresh database while still failing when existing data must move to a new layout or access pattern. Testing migration alongside the normal request flow reduces that uncertainty, although the archive does not provide detailed test cases or performance measurements.
The successful test does not mean the work is merged or ready for general release. IzioDev asked for review of a pull request that fixes WebAssembly and a database iterator edge case, while noting that the remaining review comments still apply and are pending. WebAssembly is a portable compiled-code format, while a database iterator is the mechanism that walks through stored records one by one.
For developers: The reported validation covered the full flow and migration, and the accompanying pull request addresses both WASM behavior and an iteration edge case. A JavaScript usage example was added. The archive does not confirm final approval or merger, so the accurate status is “working in end-to-end testing, with review still open.”
The week therefore produced proof that the pagination path can work, not proof that every concern has been resolved. The next meaningful milestone is closure of the outstanding comments and confirmation that the fixes have been accepted.
What else moved forward
Argent’s safety debate found a possible middle ground
Argent developers are trying to decide how much protection a contract language should provide against mistakes in complex applications.
Argent is a language and toolchain for writing blockchain contracts. These contracts can use covenants, which are rules that restrict how funds may be spent. In a multi-actor application, several contract-controlled components may interact, making it easier for an author to forget an authorization check in one path.
IzioDev suggested that Argent could enforce handling of an actor’s covenant identifier, called cov_id, across all of that actor’s entries. An entry is a callable contract path or operation. The goal was a “fool guard” that would remind developers to account for the relevant actor whenever an entry is written.
Michael Sutton questioned whether mandatory compiler enforcement would be too strict. Complex ownership and financial logic already require testing, auditing, and careful design, he argued, and a compiler rule could interfere with applications that intentionally authorize different actors under different conditions.
A decentralized exchange pilot supplied exactly that counterexample. Its entries may conditionally allow one covenant identifier while rejecting another. A global rule would therefore fit simpler applications but not necessarily larger ones with context-dependent authorization. IzioDev suggested that the compiler might still provide an informational note in those cases (source).
The discussion then moved toward a less restrictive answer: an automatic auditing tool that inspects contracts and raises warnings about logical, financial, and blockchain-specific risks. Such a tool could live in the compiler suite while allowing developers to suppress warnings when they have intentionally chosen a particular design (source).
For developers: One possible compiler-level approach would declare that an application authorizes a specific cov_id through co_spent, a check concerning whether related contract-controlled items are spent together. Entries would then either observe that identifier or receive a generated rejection check. Sutton noted that this idea is not well-defined unless the identifier is constant, and remained unconvinced that it belongs in the compiler.
No safety mechanism was selected this week. The useful result was a clearer trade-off: strict enforcement can catch omissions, but warnings may better accommodate legitimate complexity. The auditing-tool concept now offers a direction worth exploring without being mistaken for an approved feature.
A larger pilot exposed where generated code grows
A “big” multi-actor application was approved as a useful pilot example in the Argent playground (source). That makes it valuable not just as a demonstration, but as a way to reveal costs that smaller examples can hide.
Ross Ku reported a corrected measurement showing that the Argent port produced roughly 1 KB of additional code, rather than the approximately 500 bytes initially estimated. An opcode-level comparison suggested that most of the difference comes from rebuilding the entire state, not from duplicated checks (source). An opcode is one low-level instruction executed by the contract environment.
That diagnosis is still presented as an interpretation, not a settled finding. The comparison makes the suspected cause easier to inspect, but the archive contains no final agreement or optimization plan.
Another size boundary also appeared in the pilot. Ross reported that a router fits within the relevant limit, but adding a continuation pin to a two-by-two swap exceeds 244. The archive does not define the unit or the full constraint, so it would be misleading to generalize from that number. The application currently omits that pin because individual orders check their own continuation (source).
The takeaway is practical: larger examples are doing their job by exposing real size and composition limits. The port works far enough to measure, but those measurements are evidence for further investigation, not proof that the overhead has been solved.
Imported contract artifacts still need a stronger trust link
The pilot also surfaced a subtler problem: how an application knows that the contract handles it trusts actually belong to the published artifact it reviewed.
An artifact is the packaged output produced from contract source code. Ross explained that the current interface fingerprint does not cover handles, leaving nothing on the importer side that binds those trusted handles to the reviewed artifact. An ID pin proposed in pull request 12 is an attempt to create that link (source).
In plain language, reviewing one package is not enough if the identifiers used later cannot be firmly connected to that exact package. It is similar to approving a document while leaving its referenced attachments unnamed: the review may be sound, but the connection can still be ambiguous.
The archive does not say that the ID-pin approach has been accepted. It remains an attempted solution, alongside temporary application-level workarounds for other open issues. For users, there is no announced behavior change yet. For builders, it is a reminder that reproducibility and identity are part of contract safety, not just packaging details.
What is decided, and what is not
Completed or confirmed this week
- The UTXO pagination flow was tested end to end and worked as intended, including migration.
- A JavaScript example was added for the pagination flow.
- Argent pull request 68 was announced for merger, and a later report tested against Argent’s master branch with that change included (source).
- The Argent port’s measured size difference was corrected from about 500 bytes to about 1 KB.
- The larger application pilot confirmed that its router fits the relevant limit, while an added continuation pin does not.
Still proposed, under review, or unanswered
- The pagination-related WASM and database iterator fixes still need review, and other comments remain pending.
- There is no confirmed decision to enforce covenant authorization handling in the Argent compiler.
- A contract checker for logical, financial, and blockchain-specific risks is an idea, not a completed tool.
- Rebuilding the full state is the suspected main source of Argent’s additional code size, but the archive records no final conclusion.
- The proposed ID pin may bind trusted handles to reviewed artifacts, but acceptance is not confirmed.
- Several application-level workarounds remain in use while related Argent changes are unsettled.
What happens next
- Watch for review or revision of the pagination pull request covering WebAssembly and database iteration.
- Look for confirmation that all outstanding pagination comments have been resolved, followed by any merger or release decision.
- Expect further examination of the roughly 1 KB Argent port difference and whether full-state rebuilding can be reduced.
- Watch whether Argent adopts compiler warnings, a separate auditing tool, or another approach to missing authorization checks.
- Follow the ID-pin proposal to see whether it becomes the accepted link between imported handles and reviewed artifacts.
This week’s clearest result was modest but useful: UTXO pagination survived a realistic end-to-end test, including migration. The larger question now is whether review turns that working flow into finished infrastructure, while Argent’s pilots continue showing where safer tooling must remain flexible enough for real applications.