Kaspa vProgs authenticated state trees became a concrete prototype in PR #24, which replaced a placeholder state commitment with a versioned Sparse Merkle Tree and connected it to scheduling, rollback, proof generation, and a unified ZK batch-processing interface. The merge improved internal consistency, but remained early-development framework code rather than a Kaspa mainnet feature.

Key takeaways

• vProgs PR #24 added a persistent, versioned Sparse Merkle Tree with proof generation, pruning, and rollback.
• Domain-separated hashes distinguish internal nodes from leaves, reducing ambiguity between structurally different data.
• The prover began reading roots and proofs from the scheduler’s persisted store instead of maintaining a second in-memory state tree.
• Batch processing committed either a successful state transition or a structured error through one ABI path.
• The PR merged into a vProgs feature branch, and the repository described itself as an early prototype whose APIs could change substantially.

What changed in Kaspa vProgs PR #24?

The official vProgs PR #24 merged 34 commits into feat/zk-batch-processor on March 22, 2026. GitHub records 3,003 additions, 1,621 deletions, and 98 changed files. The scope covered state commitments, persistence, scheduling, rollback, proof construction, the ZK batch ABI, wire formats, and end-to-end tests.

The central change was replacing an earlier placeholder with a proper versioned Sparse Merkle Tree, or SMT. An SMT maps keys into a fixed logical tree and compresses empty regions, allowing a compact root to commit to a large state. A proof can show that a key-value commitment is present, absent, or changed without sending the entire database.

The vProgs repository described the project as a Rust framework for transaction scheduling, execution, storage, and provable computation on Kaspa. It also warned that the code was in an early development and prototype phase.

How did the authenticated state tree work?

PR #24 introduced a core/smt crate with shortcut leaves, versioning, stale-node tracking, pruning, and rollback. It used separate hash prefixes for internal nodes and leaves: 0x00 and 0x01. This domain separation makes the role of each hashed object explicit rather than relying only on byte concatenation.

The tree was backed by RocksDB column families for live and stale SMT nodes. Inverted version encoding supported efficient lookup of the latest relevant version. These are implementation choices for the prototype; they are not claims that every future vProgs implementation must use the same database layout.

An authenticated root is useful only if every component agrees on it. PR #24 stored the state root in state metadata and tied scheduler commits to tree updates. Rollback invoked the tree’s rollback path, aligning application state, persistent state, and the commitment exposed to proof logic.

Why did vProgs remove the parallel proof tree?

Before the merge, proof code maintained a separate in-memory SMT. PR #24 removed that duplicate implementation and made the prover call Tree::prove() and Tree::root() against the scheduler’s store.

Two state trees create a synchronization hazard: execution can update one while proof generation observes another. A single persisted tree narrows that failure surface and gives state execution, rollback, and proof construction one commitment source. It does not automatically prove the implementation is bug-free; it makes the consistency model easier to reason about and test.

This state model complements, but is distinct from, transaction-level rules such as Kaspa transaction introspection opcodes. Introspection constrains UTXO transactions; vProgs explores an execution and proof framework above that base.

What did unified ZK batch verification mean here?

The merge concentrated batch verification in Abi::process_batch. A guest receives host data and a journal, applies a verification function, and commits a StateTransition. A successful transition includes the program image identifier and previous and new roots; a failed batch commits a structured error code instead of relying on a panic.

The wire format was simplified so proof leaves carried keys and value hashes, while a leaf_order permutation related sorted proof leaves to scheduler resource indices. The proof API could calculate a previous root from its own leaves and recompute a new root through a supplied value function.

“Unified” therefore described a common state and verification pipeline inside the vProgs prototype. It did not mean that every application proof was already verified by Kaspa Layer 1, nor that unlimited batches had been benchmarked or deployed.

What tests did the pull request report?

The PR author reported that workspace checks and tests passed, including a stateful counter end-to-end scenario that advanced from zero to one to two. The test covered state continuity and SMT leaf verification. The description also listed a full proof flow using rebuilt RISC Zero guest binaries.

Those are valuable regression signals, but they are maintainer-reported results attached to the merge. The source does not provide an independent cryptographic audit, adversarial benchmark, production workload, or long-running fault test.

What were the main technical and security limits?

Authenticated trees protect integrity only under their hashing, encoding, key derivation, persistence, and rollback assumptions. Bugs in state-diff construction, proof ordering, stale-node pruning, guest code, or journal interpretation can still invalidate an application. ZK proofs also prove a particular program execution; they do not prove that the program’s business rules are safe.

The large 98-file change increased review surface. Developers needed fixed test vectors, rollback and crash-recovery tests, malformed-proof tests, deterministic encoding checks, and independent review before treating the framework as production infrastructure. The repository’s prototype warning was the correct readiness signal.

Related developer tooling, including the SilverScript debugger guide, can improve inspection without replacing protocol review or application threat modeling.

Did this merge establish a roadmap date or KAS price signal?

No. PR #24 proved that a substantial prototype design was merged into a feature branch. It did not announce mainnet activation, a stable vProgs release, application adoption, throughput guarantees, or a deployment deadline. Engineering progress can be relevant to a roadmap, but it cannot by itself justify a KAS price forecast.

Frequently asked questions

Is a Sparse Merkle Tree a blockchain?

No. It is a cryptographic data structure that commits to keyed state. vProgs used it inside a broader scheduling, storage, and proof framework.

Did PR #24 add vProgs to Kaspa mainnet?

No. It merged into the feat/zk-batch-processor branch of an early-development repository, not the Rusty Kaspa consensus client.

What does rollback protect?

Rollback lets the framework return committed state and its authenticated tree to an earlier version when execution is reverted. Correctness still depends on atomic storage and complete recovery testing.

Did the tests amount to a security audit?

No. Tests exercise selected expected and failure paths. An independent audit evaluates broader assumptions, adversarial inputs, cryptographic integration, and operational behavior.

Source and verification note

This article is based on merged kaspanet/vprogs PR #24, its GitHub merge metadata, changed-file record, test claims, and the project’s prototype-stage README. Exact architecture descriptions refer to the March 22 merge into feat/zk-batch-processor. The sources do not establish mainnet deployment, API stability, an independent audit, production scale, application adoption, or a KAS price outcome.