vProgs, short for verifiable programs, are applications that run outside Kaspa and use cryptographic proofs to show that their work is correct. Their larger goal is to let independent apps work together in a single transaction, without making every Kaspa node run or store every app.[1]
The distinction between the goal and the implementation matters. The vProgs architecture is described in a draft research paper. The vprogs code is an early prototype, not a finished mainnet system: its README, as of 8 October 2026, says the repository “is in early development / prototype phase” and that “APIs and architecture may change significantly”.[1][2]
How they work
The design separates ordering, execution and verification:
- Kaspa orders the actions. It provides the shared sequence of transactions and makes their input data available. It does not execute the applications’ own logic.[1]
- The application runs the code. A vProg’s computers maintain its accounts and calculate how transactions change them. Each program alone authorizes changes to its own accounts.[1]
- Proofs establish correctness. The program periodically commits its state to Kaspa using zero-knowledge proofs, cryptographic evidence that its computation followed the required rules.[1]
“Zero-knowledge” does not mean that every vProg is automatically private. In the architecture explained by Yonatan Sompolinsky on 26 October 2025, raw transaction data is published on-chain, while the program’s full state is held locally by the nodes following it.[3]
The supporting Kaspa features are distinct from the full vProgs system. The ZK verification precompile, which lets scripts check execution proofs, and the partitioned sequencing commitment, which records app-specific transaction ordering, are already part of Kaspa: both proposals were marked Active, meaning in force on the network, in July 2026. Having these building blocks does not make the entire research architecture complete.[4][5][1]
What they aim to add
The first aim is more computation without making every node repeat it. Applications perform their work outside the base network and submit proofs for verification. The draft describes this as a way to expand Kaspa’s computational capacity while dividing the storage and execution burden among applications.[1]
The second is independence for each application. A vProg owns its accounts and maintains its own state. Its nodes do not normally need to maintain every other program’s complete state.[1][3]
The third, and more ambitious, aim is synchronous, atomic composability. This means that one transaction can touch accounts belonging to several programs, with the combined action succeeding or failing together. In his vProgs MasterClass, from 1:31, Michael Sutton explains the balance: programs remain separate, but can interact because they share Kaspa as their sequencer, the network that establishes transaction order.[6][1]
Why connecting independent apps is difficult
An app may need another app’s latest result before it can process a transaction. Simply waiting for each other’s proofs could introduce long delays. The proposed solution is on-site execution: an app’s own nodes can calculate the external work they depend on, using the required data, rather than relying entirely on another operator.[1]
That creates another problem: one app could impose too much work on another. The research therefore measures each transaction’s computational scope, the chain of earlier calculations needed to validate it, and proposes limits on that burden.[1]
A useful detail from Sutton’s formal model, published on 17 August 2025, is that frequent proofs act as “a history compression mechanism.” A fresh proof gives other programs a nearer verified starting point, reducing how much earlier work they must reconstruct.[7]
For the technical foundation, read the draft vProgs yellow paper.[1] For the designer’s spoken explanation of independent programs working together, watch Michael Sutton’s vProgs MasterClass from 1:31.[6]