Kaspa apps still have some big holes. If a vprog's operator stops, users can't force their money out. Wallets can't tell two tokens with the same name apart. The contract tools don't warn builders about some expensive mistakes, and nobody has worked out who pays for the proofs. Builders and core developers are arguing about all of this right now, in the R&D chat and on X, and none of it is solved yet.
When the operator stops
In a vprog the operator can't steal. Kaspa releases coins only after a proof shows the app followed its rules. A bug in those rules could still pay the wrong person, but the operator can't just take the money.
What the operator can do is stop, and there is no escape hatch yet. A user can't force their money out without running the whole system themselves (vprogs book). Coins that were already turned into a withdrawal are safe, and only their owner can claim them. Everything else waits for the next proof.
That proof doesn't have to come from the operator. Anyone who follows the app can step in and send proofs, as Michael Sutton and Maksim Biriukov explained on X this month. The hard part is data. To make a proof you need the app's current state. If nobody shares it, the only way to rebuild it is to replay the app's transactions from an archive node, Biriukov wrote. A saved copy of the state also works, but someone has to keep it and share it.
On Ethereum, rollups use an escape hatch for this, a way for any user to leave with their money whatever the operator does (L2BEAT). Building one is more work than adding a withdraw button. It must accept only the latest balances, never an older one that was already spent, and it must still work after the operator's servers are gone.
Apps can't call each other yet
On Solana one program can call another inside the same transaction. That's how a trade can pass through another app's pools in one step (Solana docs). Vprogs can't do this. Each app keeps its balances to itself. Apps that read and call each other are planned under the name Full vProgs, but that is future work (Kaspa docs), and the vprogs code is still an early prototype that may change a lot (vprogs).
So a game, an escrow or a marketplace inside one app works today. Two apps sharing the same balances, which is how most DeFi on Ethereum and Solana works, has to wait.
Two tokens with the same name
Kaspero Labs deployed two KCC-20 tokens with the same name, ticker and picture. The only difference was the covenant ID, a long string that no normal user reads. Then it asked wallets and indexers how they plan to tell the two apart.
IzioDev, one of the KCC-20 authors, replied that an alias can be tied to the covenant ID. Even without one, he expects users to look at platforms the community trusts to see, and ideally verify, that a deployment is the right one, and wallets can make that easier by "showing the links upfront". Easy wallet screens and checking for yourself don't rule each other out.
Another reply suggested a name service for covenant IDs, like the ones that already exist for Kaspa addresses. Sutton liked it. He wants every new covenant linked to a shared name service when it launches, using something like KCC-23, the draft standard for token names and logos. The name would work like an X handle, something short that people can check easily. Manyfest, who wrote KCC-23, saw the catch. If anyone can register names without paying, spammers will take them all. If registering costs money, it's a worse public service. Maybe the payment could go to miners or to a fund, Manyfest wrote.
Sutton wants more than names. Earlier this month he wrote in the R&D chat that he expects every covenant that keeps state to publish a proof of how it started, if its builders want the public to trust it, and explorers to show that proof for each covenant, with its code and its starting state, the way Etherscan shows Ethereum contracts.
None of this exists yet. KCC-20 is still in Last Call, its final review, and KCC-23 is still a draft (KCC repository). Wallets also need the new way to load coins page by page, which is merged into Rusty Kaspa but not in a release yet (our report).
The compiler won't catch the expensive mistakes
SilverScript has a 1.0 release but is still marked experimental, and no audit has been published (SilverScript). Argent, the language on top of it for apps made of several contracts, has no release yet and still needs an audit (Argent).
Ross Ku found out what that means while building KOB, an order book made of SilverScript contracts with Argent on top, and he posted his notes in the R&D chat, as notes rather than bug reports, since he might be using Argent the wrong way. In one test, a simple "top up" step let whoever built the transaction send the tokens somewhere else, and the compiler gave no warning. In another, one payment counted for two orders at once, and the person building the transaction kept about 10 test KAS. He fixed it himself with a rule that gives every order its own payout. KOB has had no external audit.
The cause is a check in Argent called co_spent. It shows that another contract is part of the transaction, not that this contract agreed to the exact change (Argent docs). Sutton, who started Argent, replied that this is the builder's job. Whoever gives a contract control over tokens has to make sure that contract checks the whole operation. Matching payments to orders is the app's own logic, he wrote, "not something you'd expect from a compiler to know".
A few days later IzioDev suggested that Argent could force every part of an app to handle this check, as a guard for builders. Sutton asked whether that was "overprotecting devs" and said complex contracts need "responsibility, auditing and testing". He then sketched a middle ground, where an app declares which contract it trusts and the compiler adds the missing check. In the end he said he still wasn't convinced it's the compiler's job and that it fits better in an automatic audit tool, "kind of a clippy but for logical/financial and blockchain-specific checks", which could still ship with the compiler. Clippy is the Rust tool that warns programmers about risky code. A tool like that for Kaspa contracts doesn't exist yet, and Argent hasn't added a warning since.
Who pays for the proofs
Kaspa can already check a proof before it releases coins, and the Python SDK has a testnet example that does it (example). What's missing is the money side. Making proofs costs money, and today the operator pays unless the app charges a fee. Biriukov's demo app charges nothing, so whether someone else would keep it running "depends on enthusiasm", his book says (vprogs book). No cost numbers for vprogs have been published yet (status).
When several people make proofs for the same app, they also have to agree who proves what. Biriukov expects that will need its own network between provers, and it isn't built.
Privacy is still research
Proofs on Kaspa today show that work was done right. They don't hide anything. In a vprog the actions, the balances and what each proof says are all public. The private payment test pool also kept balances and amounts in the open. Private payments need their own way to prove you own coins without showing them and to stop the same coin being spent twice, and that isn't ready.
Until these parts exist, anyone building on Kaspa has to handle them in their own code.
Telegram sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
