vProgs (Verifiable Programs) are Kaspa's native Layer 1 smart contract system. Unlike traditional smart contracts that execute on-chain inside a VM, vProgs execute off-chain and submit zero-knowledge proofs to the Kaspa L1 for verification. This fundamental architectural difference gives Kaspa a unique position in the blockchain landscape: combining the speed and simplicity of a PoW UTXO chain with the expressive power of general-purpose computation.
vProgs are the culmination of Kaspa's multi-year programmability roadmap. Building on the foundation laid by the Toccata hard fork (native Groth16 ZK verification, covenants with SilverScript, and native assets), vProgs add a full smart contract layer where programs are:
vProgs operate within Kaspa's existing UTXO model. Each vProg instance is associated with a covenant-enforced UTXO that encodes the program's verification logic. When a user wants to invoke a vProg, they spend the UTXO and provide a ZK proof attesting to correct execution, producing new UTXOs representing the output state.
Execution happens entirely off-chain. The prover (which could be the user's wallet, a dApp backend, or a dedicated proving service) runs the vProg logic, generates execution traces, and produces a Groth16 ZK proof. Only the proof: not the execution trace or intermediate state: is submitted to the network.
Kaspa L1 contains a native Groth16 verifier (introduced in Toccata). When a vProg proof is submitted in a transaction, the verifier checks its validity. If valid, the transaction produces the program's output UTXOs. If invalid, the transaction is rejected: no state change occurs.
vProg transactions are sequenced by Kaspa's DAG consensus: the same PHANTOM/ GhostDAG protocol that orders regular KAS transfers. There is no separate sequencer, no mempool priority auctions, and no centralized ordering. vProg transactions compete fairly with all other transactions for DAG inclusion.
| Feature | Kaspa vProgs | Ethereum Smart Contracts |
|---|---|---|
| Execution Location | Off-chain (prover's machine) | On-chain (every validator runs the code) |
| Verification | ZK proof (single check per invocation) | Re-execution (every node re-runs every opcode) |
| State Model | UTXO (stateless proof, no global state) | Account (global state trie) |
| Computational Cost | Paid by prover off-chain; L1 fee is minimal (proof size only) | Paid by all validators; cost proportional to gas used |
| Composability | Atomic via concise witnesses (Merkle proofs); no synchronous calls | Synchronous (contract A calls contract B within same tx) |
| Languages | Noir, Rust (RISC Zero/SP1), Cairo | Solidity, Vyper, Yul |
| Turing Completeness | Yes (constrained by proof generation time, not on-chain gas) | Yes (constrained by block gas limit) |
| Gas Model | Sovereign gas pricing (STORM constants); no global gas wars | Global gas market; congestion drives up fees for everyone |
Kaspa vProgs are organized into three tiers based on their capabilities and execution model:
Simple ZK-proof verification embedded directly in covenant scripts. Use cases include private payments (prove you have sufficient funds without revealing the amount), atomic swaps with private conditions, and verifiable credentials. Proof times: ~1 second.
Full vProg applications with off-chain execution and on-chain verification, but without shared writable state between instances. Each invocation is self-contained: it reads L1 state (via concise witnesses), executes, and writes back to L1. No cross-program shared memory. Proof times: 10 — 30 seconds.
Full shared-state rollups built on vProg infrastructure. Multiple user operations are batched into a single vProg execution, with the rollup maintaining its own internal state tree. The vProg verifies the state transition and submits only the state root + ZK proof to L1. Proof times: variable, depending on batch size and computation.
vProgs support multiple ZK proving frameworks, giving developers the freedom to choose the best tool for their application:
| Operation | Proof Time | Notes |
|---|---|---|
| Inline ZK (private payment) | ~1 second | Simple circuit, minimal computation |
| Based ZK App (DEX swap) | 10–30 seconds | Moderate circuit depth, state reads via Merkle proofs |
| Based ZK Rollup (batch of 100+ ops) | 1–10 minutes | Depends on batch size, state transition complexity, and proving hardware |
vProgs achieve composability through concise witnesses: Merkle inclusion proofs that allow a vProg to cryptographically verify the existence and state of any UTXO, native asset, or covenant output on Kaspa L1. Because Kaspa is a UTXO-based chain with a well-defined state model, any vProg can produce a proof that references any other L1 state without needing synchronous calls.
Atomic composability is achieved by constructing transactions that spend multiple vProg UTXOs simultaneously. For example, a swap transaction can atomically spend a vProg UTXO representing user A's funds and another representing user B's funds: if either spend fails, neither succeeds. This is the UTXO equivalent of atomic swaps, generalized to arbitrary vProg instances.
One of the most innovative aspects of vProgs is the sovereign gas model. Unlike Ethereum, where all transactions compete for a single global gas pool, vProg users set their own gas parameters using STORM constants:
Because ZK verification on L1 is computationally cheap (a fixed cost per proof, regardless of what the off-chain program did), there are no global gas wars. Your vProg transaction fee depends only on the size and complexity of your proof, not on what everyone else is doing.
| Phase | Milestone | Timeline | Status |
|---|---|---|---|
| Toccata | Foundation — native assets, covenants, Groth16 ZK verification | June 2026 | Completed |
| Phase 1 | Standalone vProgs — Based ZK Apps without shared state | 2026 H2 | 🔄 In development |
| Phase 2 | Full composable vProgs — Based ZK Rollups with shared state and cross-program composability | 2027 | 🔮 Planned |
Several tools and resources are available for developers looking to build on vProgs: