When you play an online game for money, the company running it decides who won. The same company also holds the money until it pays out. You have to trust that it counts fairly and pays the right person.
A tiny game on Kaspa testnet works differently. Maksim Biriukov, a Kaspa developer, built a version of tic-tac-toe where two players put coins into a shared pot and the winner takes it. The game is as simple as it sounds. What is new is how the result is paid. The game runs on its own computer, but that computer cannot move the money just by saying who won. It has to send a mathematical proof that every move followed the rules, and the coins stay locked until that proof passes a check on Kaspa.
Biriukov calls it the first vprog with real execution and real settlement, and it has been running since 24 September (announcement). You can play it at vprogs-tt.izio.fr. It uses test coins, not real KAS.
What a vprog is
vprog is short for verifiable program. It is a program that runs on its own computers, not on Kaspa. Kaspa does not run the program and does not know its rules. The program works out what happens, and it proves its work to Kaspa.
Kaspa does three smaller jobs around it.
First, it puts the program's transactions in order. Users send their actions as normal Kaspa transactions with a label for the app, called a lane. Kaspa does not read what is inside them. It adds them to blocks like any other transaction and keeps a running fingerprint of each lane, which records exactly which transactions belong to that lane and in what order. This fingerprint is called a sequencing commitment and was added to Kaspa by the Toccata upgrade (KIP-21).
Second, it keeps the money locked. The coins sit in a covenant, a Kaspa address whose coins can only be spent under rules written into them in advance. Every Kaspa node enforces those rules, as it does for every transaction.
Third, it checks the proof, because the covenant's rules require it. The covenant uses a proof-checking instruction that Toccata added to Kaspa (KIP-16). It also compares the proof with the lane fingerprint recorded by Kaspa. That means the proof must cover exactly the transactions Kaspa recorded, in the same order, with nothing skipped or added (settlement covenant).
Why not run the program on Kaspa itself? Because every node in the network would have to repeat the work for every app, and that would make the network slow and expensive for everyone. A vprog does the heavy work once, on its own computers. Kaspa only has to check a short proof, which is fast.
vprogs, in plural, is also the name of the open-source toolkit developers are building for this kind of app. Its own description calls it an early prototype (vprogs toolkit, earlier kaspa.news coverage).
Why this game is a vprog
Every part of that description is in the tic-tac-toe game.
Each move is sent as a Kaspa transaction on the game's own lane, so the moves of every match are recorded on Kaspa in the order they happened (move format). The game's computer reads those moves from Kaspa and applies the rules. Anyone can run their own copy of the game software to follow along from the same moves (testnet setup).
The proof is made with a tool called RISC Zero, which shows that a program ran exactly as written. On testnet-10 the game uses real proofs made on a graphics card, not the quick practice proofs developers use on their own machines. The moves are proven in batches, and the batch proofs are joined into one.
That final proof goes to Kaspa in a settlement, a transaction that updates the game's covenant with the new results. Kaspa nodes accept the settlement only if the proof is valid and matches the recorded moves. So the operator can pay for the computers and run the game, but cannot pay a player who did not win. A valid proof for a result the rules do not allow cannot be made.
How a match works
One player creates a match and chooses the stake, meaning how much each player puts in, and how many rounds to play. A second player joins with the same stake (game rules code).
If a player does not already have enough in the game, the same transaction also sends test coins to a deposit address tied to the game's covenant. The game then adds that amount to the player's balance inside the game (create panel, deposit rules).
The game is normal tic-tac-toe. Three marks in a row wins a round. A full board with no line is a draw. The players swap X and O between rounds. If one player is too far ahead for the other to catch up, the match ends early. A player who leads 3-0 in a best-of-five has already won. A player who waits too long on their turn loses that round (match rules).
At the end, the winner gets both stakes added to their game balance. If the whole match is a draw, each player gets their own stake back (payout rules).
Getting the coins back into a normal Kaspa wallet takes two steps. The player asks to withdraw at least a minimum amount set by the game, and the game records that request (withdraw rules). After the next settlement has passed its check on Kaspa, a claim button appears, and the player collects the coins with their own Kaspa transaction. They pay the small network fee from their own coins, and the rules on the locked coins let them go only to that payout (how to play).
Why this could change things
Nobody needs a blockchain to play tic-tac-toe. The game works as a demonstration because everyone knows the rules, so the new part is easy to see. The real subject is a much older problem. Whenever an app holds other people's money, those people have to trust whoever runs it.
That trust has failed many times, in very real places.
In online games and betting, the operator decides who won and pays the winnings. Players see the result on a screen and have no way to check how it was reached. With a vprog, the operator could still run the game, but it could not pay out a result the published rules did not allow.
On crypto exchanges, customers hand over their coins and see a balance on a screen. In November 2022, FTX, then the third-largest crypto exchange with over a million users, collapsed when a rush of withdrawals exposed an $8 billion hole in its accounts (Bankruptcy of FTX). The balances customers saw were not backed by the money the exchange held. An exchange built as a vprog would keep the money locked on Kaspa, and coins could only leave after a proof showed that the balances allowed it.
On Kaspa itself, KRC-20 tokens show the same weakness. Their balances are worked out by separate software called an indexer, and nothing on Kaspa checks that calculation. When that software made a mistake in September, a bridge trusted the wrong balances and an attacker walked away with tokens (kaspa.news report). In a vprog, a wrong calculation cannot produce a valid proof, so the locked money does not move.
The same pattern fits many everyday services. A marketplace or freelance platform holds a payment until the work is delivered. A competition collects entry fees and pays prizes. A savings group collects money from members and pays it out in turns. A lottery draws a winner. Each of these needs a middleman today, and each could, in principle, be written as rules that are proven every time money moves. That matters most for people who cannot easily take a company to court when it cheats, because the company is in another country or the local courts are slow.
What makes the Kaspa version different
The idea of proving work away from the main network and checking the proof on it is not new. On Ethereum, systems called ZK rollups already do it. But many of them still depend on one company's computer to decide the order and timing of transactions (L2BEAT risk overview).
In a vprog, that job belongs to Kaspa. The app's transactions are placed in order by Kaspa miners, in the same blocks as every other transaction, and the proof has to follow the order recorded in the lane fingerprint. The app operator does the computing, but it does not control the queue.
The practical changes follow from that. Nodes do not replay every app, they only check short proofs, so a busy app does not slow the network for everyone. Developers can write their rules as normal programs in Rust, a widely used programming language, instead of squeezing them into a small Kaspa script with tight limits. And anyone can run the app's software, replay the recorded transactions and check that they get the same results.
The Kaspa features behind this arrived with Toccata, the upgrade that went live on mainnet at the end of June and brought covenants and the foundations for apps that prove their work to Kaspa (Toccata pre-release note, Toccata release). vprogs is a toolkit built on those features. It is not part of Toccata itself (developer note).
A proof also has a clear limit. It shows that the app followed its published rules. It does not show that the rules are fair or free of bugs, and someone still has to read them.
How developers can start
Yes, developers can already try this and build with it, and Biriukov is asking them to. The simplest start needs no setup at all. Play a match at vprogs-tt.izio.fr with a new testnet key and some testnet-10 coins.
The next step is the game code. Its README explains how to run the whole game on one computer. The game runs on a small private test network with its own coin faucet, and it uses fast practice proofs, so a normal computer is enough and no graphics card is needed. The setup needs Rust and Node.js, plus Docker or the RISC Zero tools to build the game's proof program. The guide lists every step, and some parts can be downloaded ready-made instead of built (how to run the demo).
The game is also a template. Its README says that everything except the game's own actions, accounts and rules comes from the vprogs toolkit and the Kaspa software (README). A developer who wants to build something else can keep that frame and replace the tic-tac-toe rules with their own. The game's own code sits in a separate folder from the parts that come from the toolkit.
Running on testnet-10 with real proofs is a bigger step. It needs a computer with an NVIDIA graphics card to make the proofs and a testnet-10 node to connect to. A guide in the game code explains that setup step by step (testnet setup). The vprogs toolkit also includes its own example settlement flow for testnet-10.
More help is planned. Biriukov says he will write a guide to the parts of the system he considers most important and run a workshop on building apps with vprogs. He has not given dates for either.
What is not ready yet
The game only runs on testnet-10, a practice network where coins have no value. To play, you paste a private key into the page. The page keeps it in memory and forgets it when you reload. Only use a new testnet key made for the game, never a key that holds real KAS.
The code is also still changing. Biriukov says a stack of changes still needs to be reviewed and merged, and the look of the page was never a priority. The vprogs toolkit describes itself as an early prototype whose design may still change a lot, and the game is built on a working branch of it rather than a finished release. Anything built today may need rewriting later. A two-player board game also cannot show how the system handles many users, fees or the cost of making proofs at a large scale.
For now, Biriukov's invitation to developers is simple. Play the game, read the code and build your own vprog.
