Wallets still have to catch up before Kaspa feels easy to use

Max143672, IzioDev and explorer builder supertypo have been arguing over a node change still under review that would let wallets and explorers fetch spendable coins in pages. Michael Sutton merged an Argent update that tracks Silverscript v1 and records extra compiler checks that generated code does not yet apply. A separate proposal would let a contract store an ECDSA owner in a form a wallet can show before the coins move.

Wallets and explorers still need a consistent way to page spendable coins

On 11 September, developers argued over a proposed lookup that would let a wallet or explorer ask for those coins in pages instead of requesting every record at once ^[1]. The records are unspent transaction outputs, leftover pieces of earlier payments that still belong to an address. Software has to fetch that set before it can display a balance or build a send.

Max143672 said the resume point between pages has to keep one consistent picture across calls. If a client walks several addresses in a single scan, later addresses can be read after the network has moved on, while addresses already passed stay at the earlier stage. Newer outputs on those earlier addresses never appear in the remaining pages ^[2].

Addresses that sort late in the list can then show the freshest coins. Addresses that sort early keep older data. Anyone treating the whole reply as current to the newest point the scan reached would be wrong ^[3].

IzioDev said that mismatch was a known tradeoff, accepted for flexibility, and that he was willing to reopen it if it harms the consumer ^[4]. They agreed that different retrieval layouts suit different consumers. Wallets need a complete set of spendable coins for one owner, so address-first retrieval fits them. Indexers and explorers follow the chain as it advances, so ordering by network progress fits them ^{[5] [6]}.

Explorer builder supertypo asked for a cheap count of outputs on an address, and for users to page through those outputs the way they already page through transactions ^[7]. He said the existing vspcv2 path already does the job for staying current on transaction details. What he still wants on that path is a subscription, so a client can be told about new activity instead of asking again and again ^[8]. Watching only the window in which outputs were created would not, by itself, follow every spend. A spend removes a coin from the spendable set, and creation-range polling does not automatically see that removal.

The node change that would expose paged lookups remains under review. D-Stacks said the last round of comments still needs a reply, including a look at a new database iterator ^[9].

Argent records extra contract checks that generated code still leaves to authors

On 10 September, Michael Sutton merged an Argent update that tracks Silverscript v1 and writes down how a leader contract and its delegates are meant to share one transaction ^{[10] [11]}. Argent is language and tooling for applications with interacting stateful contracts. Silverscript v1, covered separately when Ori Newman published it, is the readable language that compiles into the script a node actually runs (Silverscript v1). Merging the guide does not implement the extra checks it names.

Several inputs that belong to the same continuing contract can join one transaction. Some of those inputs are helpers. They are supposed to approve a coordinated move and then create no further output of their own. Checking that the helper slot holds the right actor contract does not prove which of that actor's functions will run. An ordinary spend path on the same actor can sit where a delegate was expected. It can start another continuation of the coins, or it can finish and exit while the leader still treats the slot as a cooperating helper ^[12].

Application authors currently have to notice that themselves. The merged guide names two extra compiler rules that would move the check into generated contracts. One would make the coordinator authorize every continuing output in the coordinated group, so a substitute helper cannot leave another continuation of its own. The other would apply only to eligible ordinary entries of delegate-capable actors. Those paths create no continuation and could otherwise be batched. The rule would require them to occupy the first input position, so they cannot take a later helper slot. Both rules are marked as not implemented. IzioDev volunteered on 9 September to write that compiler work ^[13].

ECDSA owners still need a displayable form contracts can choose

A contract that stores an ECDSA owner as a hash cannot show that owner's address while the coins sit unspent. The public key appears only when the coins move. Schnorr already has a direct public-key form wallets can display. A proposal would keep the owner field at 32 bytes and encode the extra parity bit in the scheme identifier so software can rebuild the address without extra data in the spend.

supertypo said Tangem uses ECDSA and that he wants that form in a system he is building. He made clear he was describing his own integration goal, not announcing Tangem covenant development ^{[14] [15]}. IzioDev asked whether there is demand that justifies extra script size for contracts that choose to accept the scheme ^[16]. Sutton suggested measuring that cost, then later proposed putting the two direct ECDSA schemes in an optional reserved group so a contract or even a wallet can choose them without imposing the extra script on everyone ^{[17] [18]}. The proposal remains open. Hardware that signs with ECDSA still needs an ownership record a wallet can show before the coins move.

All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.