The people who run Maksim Biriukov's tic-tac-toe game on Kaspa cannot take the pot. His new book on vprogs, written around that game, is just as clear about what they can still do. They can stop, and if they all stop, money still inside the game waits until somebody starts it again.
Biriukov says the book follows the game "down to the machinery underneath", and he invites readers to ask him questions about it (announcement). It is the guide he promised when the game went live on testnet-10 (earlier post), and it runs to more than 16,000 words over eleven chapters and three appendices (the book).
Robbery and delay
Everything the operator can still do is some form of stalling (machinery chapter). It can stop running the game, stop making proofs or stop settling. It can also keep settling while leaving the newest moves out, so a player's move is never processed. Skipped moves show up as a stall that anyone can see, but nothing forces the operator to process them (building chapter). Safety, in Biriukov's words, "needs no operator". Keeping the game moving, which he calls liveness, needs one "until someone else takes over".
Someone else really can take over. The settlement script asks for a valid proof and no signature, so a valid proof from anyone moves the game forward (settlement script). Anyone can run the same open software against the same public moves and carry on where the last operator stopped. The catch is cost. Resuming means running the proving machinery, "real work at real cost", which makes a takeover "a capability, not a service anyone promises".
Money that a settlement has already set aside for a withdrawal is safer still. Its owner, or anyone acting for them, collects it with an ordinary Kaspa transaction, and no operator sits in that loop (claim script). The weak spot is everything before that point. There is no escape hatch yet, no way for a player to force a settlement through without running the machine themselves. Until there is one, a balance that has not been set aside for withdrawal waits for an operator.
Upgrades are where this bites hardest. New rules mean a new instance of the program, so players withdraw from the old one and deposit into the new one (Solana chapter). Someone still has to keep settling the old instance while everybody leaves, which is exactly when an operator has the least reason to stay.
Biriukov's practical advice is to "exit early if you plan to leave". The book's closing chapter puts the whole problem in one line. "Robbery and delay are different failures, and only the first is solved" (where things stand).
One pot, one bug
The other risk is the code itself. Every deposit sits together at one address, so the whole pile is exactly as safe as the code fixed into the game at launch, "bugs included" (based rollup chapter). A rule that pays the wrong person would drain it "through perfectly valid proofs", because a proof only shows that the rules were followed.
The book also warns about a shortcut. Developers testing on their own computers use a dev mode that makes stand-in proofs instead of real ones. A game set up in dev mode has no proof check in its script, so on a public network anyone could spend from it, and "no one would or should hold money in it" (zkVM chapter). The tic-tac-toe game on testnet-10 makes real proofs.
Who pays, and how long it takes
Biriukov will not guess what the system costs to run. "No published numbers yet, and this book won't invent them," he writes about cost and speed (where things stand).
Who pays is clearer. Players pay normal Kaspa fees for their own moves and deposits, and whoever sends a withdrawal claim pays for that one. The operator pays the fees for settlements and the computing behind the proofs. The tic-tac-toe game charges nothing on top, though a real app could take a fee from accounts to fund its operator (building chapter).
The missing fee shows up in two places. Anyone can post junk moves to the game, and the junk pays its own network fees and gets rejected. It still rides into the proving machinery, though, so heavy spam burns the operator's proving time until a fee exists. And because running the machine is pure cost for the tic-tac-toe game today, the idea that someone will restart a stalled game "depends on enthusiasm".
A withdrawal waits for the safety window the operator sets before settling, then for the proof, then for Kaspa to include the settlement. Collecting the money adds the claim's own confirmations. Measured figures will go into the project's guides once they exist.
Not Solana, not an Ethereum rollup
Developers who know Solana get a whole chapter, because the two look alike on the surface, with accounts, balances, signed transactions and work done in parallel (Solana chapter). The difference is who owns the rules.
On Solana "the runtime is the chain". The network decides how accounts work, what holding data costs and what makes a transaction valid, and every program lives inside those rules. In a vprog "the runtime is the program". The tic-tac-toe game ships its own rulebook, and the proof covers it along with everything else.
That freedom has a price. A rule can be anything a program can compute, such as a turn timer that ends a round or a pot that splits on a draw, but "nobody else guarantees your rules make sense". Programs cannot call each other yet, either. On Solana one program can use another inside a single transaction, while each vprog is its own sealed system. A design paper sketches cross-program calls, but none of it is built.
Ethereum readers get a checklist of their own. Every settlement carries a validity proof that every Kaspa node checks, and there is no sequencer, because Kaspa itself orders the moves.
One word needs care, though. The book calls the design a based rollup, and on Ethereum "based" also comes with forced inclusion, a path on the main network that makes a rollup process a transaction even if its operator refuses. This machine ships without one. Anyone can get a move onto Kaspa, because nobody guards the game's lane, but it can still sit there unprocessed.
Building on it
For app builders, the book boils the pattern down to "signed actions in, indexed state out" (building chapter). A player's browser builds and signs each move itself, with the same code the proofs check. To show the board and balances, the app reads an index, a service the operator runs.
That index is "convenience, not authority", in the book's words. It cannot move anyone's money, but it can show false information and lead a player to sign a bad move. In tic-tac-toe the damage is small, a move that fails when it is proven or at worst one game's stake. In a trading app, a swap built on misreported figures would go through against the real ones, and the user would take the loss.
Biriukov's answer is that actions should carry their own limits, such as the least a trade must return and a deadline, so a move built on bad information fails instead of costing money.
What the app shows is still the operator's claim, and moves made since the last settlement are not proven until the next one. Anyone who wants certainty can wait for that settlement or run their own node and replay the public moves. A lighter check of a single balance is possible in principle, but the game's server does not hand out the data it needs yet.
Nothing in the game is private, either. "Zero-knowledge here is verification technology, not privacy," the book says, so the moves, the game state and what each proof claims are all public (zkVM chapter).
Each vprog stands alone for now. In Biriukov's words, vprogs today lets a developer stand up "a small, self-contained chain for a single application, based on Kaspa" (sovereign apps chapter). Games, escrow and marketplaces where the market is the program fit that shape. A lending app and a trading app that share the same balances do not, at least not yet.
What works and what is missing
The book is specific about what already works (where things stand). The vprogs framework runs as working code with automated end-to-end tests. On testnet-10 the game has played a full match with real proofs, settled on the public network and paid out withdrawals that players claimed. The software also survives restarts, chain reorganisations and nodes that have dropped old block data.
Mainnet does not need another network upgrade. The features the game depends on, KIP-16, KIP-20 and KIP-21, are already live there. Biriukov writes that "what separates the demo from a mainnet deployment is operational work, not protocol activation" (based rollup chapter).
The missing pieces are just as specific. The vprogs code calls itself an early prototype whose APIs and architecture may change significantly (vprogs README). Programs cannot work together, RISC Zero is the only proof system it supports, there is no escape hatch and nobody has published measured costs or speeds.
"There is no token and no foundation," the book adds, and "at this stage the repositories are the project". The money inside stays KAS from deposit to payout, with no new coin standing in for it.
The game still runs on testnet-10 with test coins, so use a new testnet key made only for it (play the game). The book ends with an invitation to lose a game "knowing why the pot cannot be stolen, and what has to keep running so you can leave."
