Two fewer ways to get a contract wrong

IzioDev has added two safeguards to the Argent compiler that application developers previously had to enforce themselves. Michael Sutton merged the change on 14 September, closing a gap discussed in the Kaspa Core R&D Telegram chat a few days earlier. Elsewhere in the discussion, Aglovale put a revised method of checking spendable coins through development-network tests, while D-Stacks and Max143672 continued debating how a wallet can keep its balance up to date when its records arrive in pages ^{[1] [2] [3]}.

A helper shouldn't call the shots

Argent is a language and compiler for applications whose contracts work together. One contract can coordinate a transaction while others participate as helpers. Those helpers are supposed to approve the coordinated action, rather than quietly take a different path of their own.

The distinction matters because recognising the right contract does not, by itself, establish which function that contract will run. A transaction could put an ordinary function in a position intended for a helper. That function might create a separate continuation of the contract, or exit without creating one, while the coordinator still treats it as a cooperating participant. The earlier Argent work described the extra checks needed to rule out these arrangements but left their implementation to application authors (previous coverage).

The new compiler code adds those checks to the contracts it generates. One requires the coordinator to authorise all continuing outputs in its contract group, blocking an extra continuation outside that approval. The other restricts where certain ordinary functions can appear, preventing them from occupying a helper position. Independent transactions can still be batched where the rules allow it (compiler changes).

For someone building an application, the gain is having these structural checks supplied by the compiler instead of having to remember and reproduce them correctly. The change also includes tests for rejecting the unwanted arrangements and retaining permitted ones (merged change).

Sutton identified a further improvement after the merge. The transaction-building software could check these conditions earlier and tell the developer what went wrong, rather than waiting for the generated contract to reject the transaction with a general verification error. That would make a failed construction easier to diagnose. Argent remains under development and still needs further audit and hardening before it is ready for general use ^[4] (project status).

The experiment that doesn't get a vote

Aglovale is investigating a different part of the system, the compact cryptographic summary a node maintains of all unspent coins. These coins are recorded as unspent transaction outputs, usually shortened to UTXOs. Payments consume some outputs and create new ones, so the summary has to keep changing with them.

Kaspa uses MuHash for that job. Aglovale has built an experimental alternative called LtHash and wired it into a separate development version of the node. Part of the motivation is research into cryptography that could withstand future quantum computers, alongside measuring the cost of maintaining the summary ^[5].

The experiment runs in shadow mode. MuHash continues to supply the commitment used in validation, while LtHash processes the same coin data alongside it. The software can then compare its continuously updated LtHash result with a fresh calculation over the coin set. Agreement helps check whether the implementation has kept up with the node correctly. It does not establish that the cryptographic construction is secure (experimental implementation).

The design changed after feedback in the chat. Max143672 suggested another hashing construction, and Aglovale acknowledged that an earlier comparison had not tested the method he thought it had. After further benchmarks, he revised the design and reported on 15 September that it was running alongside MuHash on two development-network nodes ^{[6] [2]}.

Aglovale reports lower costs for several accumulator operations, but the alternative also stores a larger state. The code is unaudited, its security parameters still need cryptographic review, and the shadow mode refuses to run outside devnet. It has no role in deciding which blocks pass validation (research and measurements).

The last page isn't the finish line

The discussion returned to a problem covered in the previous roundup. Fetching spendable coins in pages would let software handle a large set without asking for everything at once. But payments keep happening while a wallet works through those pages. It needs to know where to resume without overlooking newer activity or repeatedly fetching records it already has ^[7].

D-Stacks proposed working between checkpoints. A wallet would choose an upper boundary, finish fetching the records within that range, then move the boundary forward for the next pass. Grouping addresses in a request could also reduce the work imposed on the node ^{[8] [9]}.

Max143672 questioned how easily wallet developers would understand that model. When addresses are read at different stages of network activity, they do not all have equally recent information. Starting another pass from the oldest point can mean requesting known data again. Tracking each address separately would give the client a clearer view of how far that address had caught up ^{[10] [11]}.

D-Stacks replied that the proposed interface already permits single-address requests. A wallet could use those, group addresses, or retain a simpler paginated version of its existing lookup. Max143672 accepted that a library could help, but said the flexibility requires context that had not been obvious even during the discussion ^{[12] [13] [3]}.

There is also a limit to what the checkpoints mean. The DAA score used to mark network progress can help describe how recent a result is. D-Stacks cautioned against treating it as a payment-confirmation security measure, recalling that exchanges integrating Kaspa had been advised not to make that assumption ^[14].

The paginated lookup remains an open proposal. By 19 September, the discussion had also raised a useful possibility for wallets with frequent activity, checking an address expected to receive a payment more often than quieter addresses. D-Stacks suggested that approach as something clients could explore using the interface's flexibility (proposal) ^[15].