This week in Kaspa R&D, from September 27 through October 4, centered on trust: how users might verify an on-chain application, how developers can avoid unsafe contract behavior, and how wallets or services could retrieve large sets of spendable outputs more reliably.
The clearest advance came from Argent, Kaspa’s developing language and toolkit for programmable contracts. New proof support was merged with a larger goal: letting explorers connect a contract to its original code and starting state. Important pieces remain unfinished, but the direction could make unfamiliar applications much easier to inspect.
The week in one minute
- Argent merged work on “genesis proofs,” intended to show how a stateful contract began and give explorers useful evidence for auditing it.
- The proof system is not a finished public standard. Metadata verification and broader explorer support remain future work.
- A developer building an on-chain order book tested Argent in a real application and identified safety, size, compatibility, and browser-wallet concerns.
- Argent’s maintainers clarified that the compiler cannot automatically enforce every application rule. Contract authors remain responsible for checking important value flows.
- Separate UTXO pagination work received basic command-line testing and was described as ready enough to merge, pending more testing and review.
The big story: Argent’s merged proofs could give Kaspa contracts a visible origin
Imagine opening an explorer and finding an unfamiliar on-chain application. You can see its identifier and transactions, but not enough evidence to answer two basic questions: What program created this, and what state did it start with?
That gap matters because a contract identifier alone does not explain what the contract is supposed to do. Users, auditors, wallets, and explorers need a trustworthy path back to its origin.
Argent’s newly merged work takes a step toward that path through a “genesis proof.” Here, genesis means the contract’s beginning. The proof is intended to connect a stateful covenant to information about its initial deployment.
A covenant is a rule attached to coins or tokens that restricts how they may be spent. A stateful covenant also carries information forward as it changes, allowing developers to build applications whose rules and state live directly on Kaspa’s base network.
Michael Sutton described the ambition in practical terms: every stateful covenant deployed on Kaspa should provide this kind of origin evidence, and explorers should make it available for each contract identifier discovered on-chain. That could give users something resembling a contract inspection page, where code and initial state can be examined instead of blindly trusted (source).
For users, the important word is “evidence.” A proof would not make a contract safe by itself, but it could make the contract easier to identify and audit. That is the difference between seeing an opaque address and having material that independent tools can inspect.
The implementation arrived as Argent pull request 66, first presented as “kind of” ready for review on October 2 and then reported merged on October 4 (review request, merge confirmation). That makes the code change real, but not the entire ecosystem around it.
Explorer integration was described as a goal, not a completed feature. Support for KCC-23 metadata verification was also discussed as something Argent could add after that format is finalized (source). Metadata can provide descriptive information about an asset or application, but the archive does not establish that this verification already exists.
For developers: Sutton said the lower proof layers and the SilverScript ABI interface could theoretically belong in silverc. An ABI, or application binary interface, defines how separate pieces of software represent and communicate with a program. That placement remains a design possibility, not a confirmed move (source).
The takeaway is concrete but limited: Argent now contains merged proof work aimed at establishing a contract’s origin. Turning that into a familiar, explorer-visible trust layer will require conventions, public proof data, and supporting tools that have not yet been shown as complete.
What else moved forward
A real order book test exposed where Argent ends and application safety begins
Argent received unusually detailed feedback from a developer using it as the outer application layer for KOB, an order book built directly on Kaspa’s first layer. L1, or layer one, means the base network itself rather than a separate system built above it.
The test raised concerns about unconstrained outputs, one output accidentally satisfying two orders, large scripts, compiler limits, imported contract verification, and browser-wallet integration. These were presented as field notes rather than confirmed compiler bugs (source).
The most important clarification was about responsibility. Argent can provide language rules and reusable checks, but it cannot infer every business rule of an application. If a transaction must pay a specific recipient, or each order must receive a separate output, the contract author has to express that requirement.
One example involved co_spent(), a check that confirms another covenant was spent in the same transaction. Sutton explained that it is intentionally a simple presence check. It does not inspect the entire movement of value. A developer assigning ownership to a covenant identifier must ensure that the corresponding contract checks signatures or carefully monitors the transaction’s flow (source).
That distinction is easy to miss. A compiler can confirm that code follows its language rules while the application still permits an economically unwanted transaction. It is similar to a form accepting a valid number without knowing whether that number is the correct payment.
The maintainers did not accept every concern as a compiler issue. Some behavior was described as intentional, while warnings for potentially unsafe patterns remain open for discussion. One comparison limitation was already marked as work in progress, and support for observed ranges was promised before Argent’s first release. Per-entry script splitting, which could reduce the size and cost of large contracts, was described as a possible later improvement rather than a first-release feature.
For developers: The test also reported a 244-live-binding limit, contracts between roughly 25 and 35 KB before being split into smaller actors, and about 500 extra bytes in one port compared with hand-written code. These are reports from one application, not general benchmarks. The maintainers asked for more detail on several points before drawing conclusions.
The browser-runtime concern was also corrected. The roughly 5 MB WebAssembly build came from the application team’s own experiment, not an official Argent browser package (source). WebAssembly is a format that lets compiled code run inside web environments.
The practical result is healthy but unfinished: Argent is now being tested against a demanding application, and that test is separating language problems from rules each application must enforce itself.
Argent’s cleaner imports come with a breaking syntax change
A separate merged pull request changed how Argent imports named modules. The older import actor Foo from "..." form is no longer supported. Developers can either import without a namespace or use the new import "..." as FooModule syntax (source).
A namespace gives imported code a chosen label. This can prevent two imported items with the same name from colliding, while making it clearer where a piece of code came from.
The repository’s examples were updated, but existing Argent projects using the old syntax will need changes. This is confirmed, merged work, not a proposal (source).
For users, there is no immediate visible feature. For builders, the benefit is cleaner composition at the cost of a small migration before the language’s first release.
UTXO pagination passed basic calls, but still needs outside review
Work also continued on pagination for UTXO queries. A UTXO, or unspent transaction output, is a piece of value that has been created by a transaction and is still available to spend. Pagination lets software retrieve a large result set in manageable pages instead of requesting everything at once.
That matters to wallets, indexers, and services that may need to process many spendable outputs without one oversized response.
After a final commit, the author tested basic calls with kaspa_cli, Kaspa’s command-line client. They said the work felt ready enough to merge, while explicitly asking others to try it and confirm that earlier review comments had been resolved (source).
No merge confirmation appears in this week’s archive. The accurate status is therefore tested at a basic level and considered merge-ready by its author, but still awaiting broader testing or re-review.
What is decided, and what is not
Completed or confirmed
- Argent pull request 62 was merged, introducing the new import syntax and removing the old named-actor form.
- Argent pull request 66, covering genesis-proof work, was reported merged on October 4.
- Basic UTXO pagination calls were tested through
kaspa_cli. - The reported Argent WebAssembly package was confirmed to be an external experiment, not an official repository feature.
Proposed, planned, or still open
- Explorers providing genesis-proof data for discovered contracts is an ecosystem goal, not a completed deployment.
- Argent support for finalized KCC-23 metadata verification is desired but not implemented in the evidence provided.
- Compiler warnings for loosely constrained value flows remain under discussion.
- Observed-range support is planned before Argent’s first release.
- Per-entry script splitting is a possible future optimization, not a first-release commitment.
- UTXO pagination still needs additional users to test it and reviewers to confirm that previous comments were addressed.
What happens next
- Watch for explorers or other tools to begin consuming Argent’s genesis-proof data.
- Look for review and follow-up work that defines where the proof layers should live.
- Expect more detailed responses from the order book developer after the team reviews its Argent integration.
- Track fixes for the comparison limitation and the promised observed-range support before Argent’s first release.
- Look for a confirmed merge, or further review findings, on UTXO pagination.
This week’s main advance is not that Kaspa contracts suddenly became self-explanatory. It is that Argent merged a building block for showing where they came from, while real application testing made clear how much careful contract design still matters. The next meaningful proof will be seeing those two efforts meet: auditable origins, paired with applications whose spending rules hold up under use.