A coin, balance, object, order, vault, game position, or app-specific state item that can be named and updated.
Roadmap architecture
Kaspa vProgs explained
vProgs are the later Kaspa app architecture for programs that prove richer logic while sharing Kaspa ordering. The model is simple: split app state into named resources, run independent work in parallel, and prove the result without asking Kaspa L1 to execute every app step.
Status: vProgs are prototype and roadmap work. Toccata is released and scheduled for mainnet activation; full vProgs and native Kaspa DeFi are not live mainnet behavior.
One sentence
The mental model
vProgs turn app execution into a flow of resource-level dependencies: conflicting work waits on the same resource, while independent work keeps moving through the system.
A transaction declares which resources it reads and writes, so the scheduler knows what can run together.
The app can produce proofs or journals that let later layers verify what happened without replaying everything on L1.
Scheduling
Why resource lanes exist
In a global account-style system, many app actions compete for the same shared state. vProgs push the design toward individually addressable resources. If Alice touches resource A and Bob touches resource Z, those actions do not have to wait for each other. If both touch resource A, their order still matters and the scheduler serializes that part.
The scheduler builds a dependency graph from declared read/write metadata. Each resource acts like a small lane. A transaction attaches to the lanes it touches, waits for the values it needs, runs when its dependencies are ready, and then passes updated values forward. The result is a computational DAG: independent branches keep executing while congested resources only slow the work that actually conflicts.
The Hans Moog vProgs walkthrough is not a raw "more TPS" claim. The narrower claim is that independent app state can keep moving while one resource or market is busy.
Layer map
What the prototype repo shows
The public kaspanet/vprogs repository describes itself as an early-development Rust framework for based computation on Kaspa. Its README maps the framework into layers: core types, storage, state, scheduling, transaction runtime, and node integration. The workspace also includes L1 and ZK crates for bridge/types, ABI, transaction prover, batch prover, VM, and RISC Zero backend work.
| Layer | Plain job | Why it exists |
|---|---|---|
| Core | Shared types such as resources, transactions, and access metadata. | Every layer needs the same basic language. |
| Storage | Read and write app state to disk. | The app needs persistence without making storage know app semantics. |
| State | Define what is stored and how versions or rollbacks work. | Execution needs a clear model for resource state. |
| Scheduling | Track resource access and orchestrate parallel execution. | Independent resource lanes should run without one global lock. |
| Runtime | Define what a transaction or program does when it executes. | Different VMs or app runtimes can plug into the scheduling model. |
| Node | Put the layers together into a concrete runnable system. | A framework needs an integrated runnable surface. |
| ZK / L1 | Produce proofs and connect app results back to Kaspa evidence. | The app needs verification and settlement boundaries. |
Toccata connection
What comes before full vProgs
Toccata is the near-term hard-fork track. Its release and KIP work target covenant-style spending rules, covenant IDs, ZK proof checks, and sequencing commitments. Those pieces give app builders concrete handles for UTXO state constraints, app-state identity, selected computation proofs, and app-local sequencing anchored to Kaspa evidence.
Michael Sutton's Argent repo adds early tooling evidence. It experiments with actor-style state machines that generate Silverscript for multi-contract covenant systems. It is prototype work to study. Audit, production, and activation claims need separate evidence.
That still does not make full vProgs live. Toccata can support simpler covenant apps, proof-gated flows, sequencing commitments, and standalone based-app foundations. Full app-to-app composition is the later target: one combined action touching several app states and succeeding or failing as a unit.
Covenants, spend constraints, asset rules, proof checks, and lane-friendly commitments.
One app anchors its state to Kaspa ordering, commitments, proofs, settlement, or exits.
Later app architecture for richer logic and cross-app atomic composition.
Copy boundary
Claim wording
| Use | Avoid | Reason |
|---|---|---|
| vProgs are roadmap architecture for app programs that prove richer logic while sharing Kaspa ordering. | Treating vProgs as activated Kaspa smart contracts. | The public repo is explicit prototype evidence. Mainnet activation needs separate mainnet evidence. |
| Toccata gives Kaspa a path to L1 app rules and based-app foundations. | Toccata means full Kaspa DeFi is live. | Activation, wallets, liquidity, audits, custody, and app usage are separate evidence. |
| Independent resource lanes can execute without waiting on unrelated congested state. | Kaspa apps have unlimited throughput. | Parallelism depends on workload shape and declared resource conflicts. |
| ZK proves a statement about chosen public inputs. | A proof automatically proves prices, bridge truth, or real-world events. | External facts still need anchors such as a light client, oracle, reporter set, or challenge process. |
Builder filter
When this architecture applies
Use the vProgs mental model when a product has many independent pieces of state, many users touching the same app, or a proof requirement that belongs outside a simple covenant spend. Examples include trading state, auctions, games, coordination markets, app-specific ledgers, and proof-backed settlement flows.
Start with payments, receipts, vault rules, refund paths, allowance caps, or controlled assets before reaching for vProgs. A good Kaspa app chooses the smallest state model that can honestly do the job.