Olaf Weller, who leads the open Kaspa Privacy Initiative, has finished the first working test of the machinery that private KAS payments would need. On testnet, ordinary Kaspa transactions queued instructions for a small app. A program outside the network carried them out and produced a mathematical proof of its work, and a Kaspa node checked that proof before releasing any coins. When the program tried to settle while leaving one instruction out, the node refused (feasibility report).
Nothing in this test is private yet. Every balance, owner and amount was public, and everything ran with test coins only. What it shows is that Kaspa can already do the ordering and the checking that a private payment pool would rely on, so the project can now turn to hiding who paid whom.
Why anyone wants private KAS
Every Kaspa payment is public. Anyone who learns one of your addresses can follow what arrives, what leaves and where it goes. That's useful for checking the network, and awkward for a person paid a salary in KAS or a shop whose takings anyone can count.
Other networks answered this in different ways. Zcash and Monero are separate coins built around privacy. Litecoin added an optional private side area. On Ethereum, privacy apps hold users' tokens inside a contract. The Kaspa Privacy Initiative, which kaspa.news first reported when it launched, wants something specific. People would choose privacy only when they want it, and the money inside would stay ordinary KAS. The project says plainly that there is no new token and none planned (project README).
Who does which job
A private pool can't run entirely inside Kaspa, because private payments need heavy calculation that ordinary nodes don't do. So the work is split, and each job has a clear owner.
Kaspa does the ordering. A rule called KIP-21, part of the Toccata upgrade, gives each app a lane. A lane works like a numbered ticket queue. Users send ordinary Kaspa transactions tagged for that app, and the network keeps a running fingerprint of everything accepted into the queue, in order (KIP-21).
A program run by the project does the calculation. It reads every ticket in the queue, applies the app's rules and produces a zero-knowledge proof. That's a short piece of maths showing the work was done correctly, which anyone can check quickly without redoing the work. The test used RISC Zero, an existing proof system.
Kaspa does the checking. The coins sit under a covenant, a Kaspa script that sets rules for how coins may move. Before it releases anything, the covenant makes the node verify the proof and confirm that it matches the queue's fingerprint. This is the same settle-by-proof pattern behind vprogs, which kaspa.news explained in its tic-tac-toe article. Weller reports that Michael Sutton pointed the project towards this design. The project's notes record that as advice relayed by Weller, not as an endorsement from Sutton (discussion notes).
What happened on testnet
A test user deposited 10 test-KAS into the pool. The project then stopped its program and rebuilt the pool's state in a clean folder, using only the public queue and without its saved copy of the balances. After that the user asked to withdraw 4 KAS.
The settlement went through, and the payout landed. kaspa.news checked both transactions on the testnet API. The settlement was accepted by the network. The payout sent the user 4.5 KAS, the 4 KAS asked for plus a 0.5 KAS deposit the app had held for the withdrawal permission. It left exactly 6 KAS in the pool's reserve, matching the user's remaining balance.
Then came the test that matters most. The project built a second settlement that skipped the withdrawal but claimed the same end point in the queue, together with a real proof of that shorter calculation. The proof was valid for the work it described. The node still rejected the settlement with the error ZK Integrity: Verification failed, because the work it described wasn't the work the queue required. That rejected transaction never reached the chain, so it can't be looked up. The rejection comes from the project's own records.
Why the skipped step matters
Picture a pool run by an operator you don't fully trust. The danger isn't only theft. An operator could quietly drop your withdrawal and carry on settling everyone else, claiming the books are complete. In this design the queue's fingerprint holds the operator to the full list. A settlement that skips an accepted instruction can't claim to be complete, however good its maths.
That protection has limits, and the report spells them out. An operator can still settle only an early, honest part of the queue and leave later instructions waiting. It can also stop working altogether. The design stops cheating, but it doesn't force anyone to keep going, and it doesn't stop a miner from leaving a transaction out of the queue in the first place.
The private part is still ahead
The next goal is a full private payment. Alice deposits test-KAS, pays Bob privately, and Bob withdraws (work plan). That needs private notes, which are hidden records of who owns what inside the pool. It also needs nullifiers, which are public stamps that mark a note as spent without revealing which note it was. Both are familiar from Zcash.
The early work shows where the cost lies. In the latest step, the project proved a tiny three-step test of the checking logic on a rented data-centre graphics card. That one proof took just over four minutes (results). An earlier attempt on four ordinary processor cores ran for its full one-hour limit without finishing. A real private payment will be heavier than that test, so speed and cost are the open questions to watch.
What this test doesn't prove
The whole experiment ran on one testnet node operated by the project. The proofs depend on specific versions of the proof system and on upstream Kaspa code that is itself still experimental.
The project's reviews were done with the help of AI tools, and its README says so directly. It describes them as AI-assisted review, not an independent human security audit, and asks for outside Kaspa and zero-knowledge experts to look at the work (README). Recovery after every operator disappears, lost data after old history is pruned, and fair exits for many users at once are all still unsolved.
So this isn't a privacy tool anyone should send real KAS to. It's a working test showing that Kaspa can order and check the work such a tool would need. The code and every report are public, and Weller is asking for technical feedback on the next step.
