Ross Ku is building KOB, an order book using contracts on Kaspa, and has brought its practical difficulties back to the people building the tools. On 29 September, he shared notes about making contracts cooperate, keeping their size manageable and connecting them to browser wallets. He presented them as questions and development feedback, explicitly asking that they not be treated as a list of bug reports. (His message)
That same day, Michael Sutton merged IzioDev's rework of how Argent combines code from different files and applications. A separate discussion about fetching a wallet's spendable coins has also moved forward, with reviewers narrowing the remaining questions. These are changes to the tools around Kaspa applications, with different parts at different stages of completion.
Reusable code without name clashes
Argent is a language and compiler for applications made from several cooperating contracts. It builds on SilverScript, which turns readable contract code into the scripts Kaspa nodes check when coins are spent. Argent adds a way to describe how those contracts participate in the same transaction. (Argent)
That makes reusing code important. A trading application might need a token contract, an order contract and rules coordinating the exchange. If those pieces come from different files, the compiler needs to know exactly which definition a name refers to. Two pieces of code can use the same name without meaning the same thing.
IzioDev's change gives imported modules their own optional names, so a developer can distinguish one module's definitions from another's. It also follows names through dependencies and rejects ambiguous references. The new tests include cases where imported code itself imports another module, and cases where different definitions would otherwise collide. (Merged change, resolution code)
For developers, the immediate cost is updating older source code. The previous actor-import syntax is no longer supported in the changed compiler. IzioDev warned about that breaking change and said the repository's examples had been updated. This is merged compiler work, rather than a change to the rules of the Kaspa network. [1]
An order still has to pay the right person
Ross's KOB work combines handwritten SilverScript order contracts with Argent as the layer that coordinates them. An order book records offers to buy and sell. Turning a matched offer into a transaction requires more than putting the right contracts together. The transaction must also pay the amounts and recipients each order requires.
One of his questions concerns a check called co_spent. It establishes that a particular covenant participates as a valid input in the transaction. A covenant is a set of rules attached to coins that controls how they can be spent. Knowing that one is present does not, by itself, establish which movement of money it has authorised.
Argent deliberately makes that distinction. Its specification says that the application must connect the participating contracts' permissions to the particular changes being made. Ross asked whether the compiler could provide more warning when a developer uses a presence check without sufficiently restricting where the tokens go. (Ross's feedback, Argent's contract-cooperation rules)
He also described a test in which one payment output could satisfy two orders, allowing the transaction builder to retain value. He said he added his own rule tying an order's input position to its payout position. This was a reported test in his application, not a report of traders losing funds on a live exchange.
IzioDev replied that the first two points in the message described intentional behaviour. He considered much of the remaining feedback application-specific and asked for source code to examine it properly. He also said an existing request involving references to imported contract templates would be addressed. Sutton thanked Ross on 30 September and said he would provide a fuller response. (IzioDev's reply, Sutton's reply)
The distinction matters for anyone considering these tools. Argent supplies checks for the structure of an application, but the developer still has to express the intended trading rules. Code that compiles is not automatically a correctly designed market. Argent remains under development and its maintainers say it needs further audit and hardening before general production use. (Project status)
Contract size and the wallet approval step
Ross also reported that combining several operations into one contract had made its script large. In his testnet-10 measurements, the router script reached roughly 25 to 35 kilobytes, with cancelling an order costing around 0.05 to 0.07 test KAS. He split the work into separate, more specialised contracts to reduce their individual size. Those figures describe his test setup, not a general fee for trading on Kaspa. [2]
The practical question is how much code each operation has to carry. A contract that includes every possible operation can be convenient to organise, but Ross wants better ways to avoid paying for unnecessary script size when performing a smaller task. He also reported that a direct Argent version of his handwritten order code was larger because it repeated some checks he had already written.
Getting the result into a browser wallet is another part of the work. Ross wants transaction preparation, the request for a wallet signature and final assembly to be separate steps. A browser wallet needs time to show the transaction and wait for the user's decision. A builder that expects signing to happen inside one operation can be awkward to connect to that flow.
IzioDev questioned which browser version of the Argent runtime Ross was using, saying he did not know of such a wrapper in the project. The signing discussion therefore still needs to establish which software Ross was trying to connect to his wallets. [3]
There is also a recorded compatibility issue when building the runtime against Rusty Kaspa v2.1.0. Sutton has pointed to a related SilverScript issue that needs attention first. Both reports remain open. For builders, the version of the node code, the contract language and the transaction-building tools still needs to be considered together. (Argent issue, SilverScript issue)
Wallets need manageable pages of coins
The wallet-data discussion has progressed since the earlier argument about keeping paginated results up to date. The proposed interface would let software fetch spendable coins in smaller pages, instead of requesting every record in one response. A cursor records where the next request should resume. (Previous coverage, proposal)
On 23 September, Maksim Biriukov said he no longer thought he had blockers, provided libraries or examples could make the flexible interface intuitive to use. That was a change from the earlier concern that developers would need too much background knowledge to use it correctly. [4]
D-Stacks subsequently said the implementation would preserve the order of addresses supplied by the client rather than impose its own ordering. Another question remained about work already completed. After a scan has finished some addresses, should the client remove them from its next request, or should the node continue to skip them? Removing that work from the node would require more bookkeeping in the client. (Ordering update, client and server discussion)
This is work on how software reads wallet data, not a change to who owns the coins. IzioDev noted that the command-line wallet already combines an initial scan with notifications about subsequent changes. The new interface is intended to offer more manageable queries, rather than imply that existing wallets cannot maintain a current balance. The pull request remains open. [5]
Finding a contract after its address changes
The related request for lookup by covenant ID has a more direct benefit for contract applications. A contract can move to a different address when its stored state changes. Looking only at the old address will not locate its new spendable coins.
A covenant ID gives the application a continuing identifier to ask about. A node interface using that ID could return the coins belonging to the covenant without requiring the app to reconstruct every address change itself. IzioDev stressed that following the covenant, rather than one fixed address, is the purpose of the requested lookup. [6], feature request)
That lookup is separate from the pagination change and remains an open request. IzioDev has urged getting the paginated interface finished so work can move on to it. Applications waiting for covenant-based lookup do not receive it merely because the earlier review is making progress. ([7]
Telegram sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
