KIP-21 to vProgs Mapping

KIP-21 specifies the consensus plumbing that vProgs will plug into. This page maps abstract vProgs concepts – as described in the research proposals and yellow paper – to concrete KIP-21 infrastructure. It answers: what is already specified, what is partially addressed, and what remains future work?

Concept Mapping Tables

State Commitments

Concise Witnesses

L1 Sequencing Layer

Sovereign State Management

Off-Chain Computation

Synchronous Composability

Status Summary

+------------------+------------------------------------------+
|     STATUS       |              COMPONENTS                   |
+------------------+------------------------------------------+
|                  | SeqCommit(B) recurrence                  |
|                  | ActiveLanesRoot (SMT)                    |
|   IMPLEMENTED    | Lane tip hash chaining                   |
|                  | Two-anchor proof model                   |
|                  | MergesetContextHash                      |
|                  | MinerPayloadRoot                         |
|                  | SMT specification (256-depth, BLAKE3)    |
|                  | Reorg safety (SeqCommitDiff)             |
|                  | IBD bootstrapping                        |
|                  | Persistent witness store (optional)      |
+------------------+------------------------------------------+
|                  | Lane extraction (subnet-based, not       |
|   PARTIAL        |   yet vProg-based)                       |
|                  | Resource regulation (purge exists,       |
|                  |   per-vProg gas scales are future)       |
+------------------+------------------------------------------+
|                  | CD-specific lane update rules            |
|                  | Account-level read/write declarations    |
|                  | Cross-vProg atomicity                    |
|   FUTURE         | Per-vProg gas scales (STORM)             |
|                  | Proof stitching                          |
|                  | vProg deployment/vetting                 |
|                  | Re-anchoring to proven state             |
+------------------+------------------------------------------+

What Is Buildable Now

The following components are fully specified in KIP-21 and can be implemented today:

1. SMT Libraries

The sparse Merkle tree is fully specified:

• Depth: 256 levels, fixed
• Key derivation: H_lane_key(lane_id_bytes) with "SeqCommitLaneKey" domain tag
• Leaf encoding: lane_id_bytes || lane_tip_hash || le_u64(last_touch_blue_score)
• Internal nodes: H_node(left || right) with "SeqCommitActiveNode" domain tag
• Empty subtrees: Pre-computable EMPTY_{i+1} = H_node(EMPTY_i || EMPTY_i)

Build inclusion and non-inclusion proof generators now. The proof structure is fixed-shape, making it suitable for ZK-circuit integration.

The addressing scheme for the SMT uses the Blake3 hash of the lane ID as the lane key. This hashing ensures a pseudo-random leaf distribution within the tree, which is a fundamental architectural detail for maximizing SMT performance and cryptographic security.

Stateless Validation: Developers have clarified that validating vProg state transitions (KIP-21) will not require maintaining a full, stateful Sparse Merkle Tree (SMT). Instead, validation can be performed statelessly by providing proofs exclusively for the changed data. This design optimization is crucial for maximizing light client efficiency.

2. Lane Proof Systems

The two-anchor proof model is well-defined:

• Input: SeqCommit(B_start), SeqCommit(B_end)
• Prove: Lane inclusion under both ActiveLanesRoot snapshots (via SMT proofs)
• Prove: Compressed lane-diff witness between anchors
• Complexity: O(lane_activity), not O(chain_blocks)

3. Commitment Tree Traversal

The path from any SeqCommit(B) to any lane’s state is deterministic and fixed:

SeqCommit(B)
  -> right child: SeqStateRoot(B)
    -> left child: ActiveLanesRoot(B)
      -> SMT path by lane_key: leaf_hash for target lane

4. Witness Store Infrastructure

Content-addressed node store with reference-counted garbage collection:

node_hash -> (left_child_hash, right_child_hash)

• Reconstruct any historical witness from a header anchor
• GC: ref-count on insert, decrement on prune, delete at zero

5. Activity Digest Computation

Per-lane block activity is fully specified:

activity_leaf(tx) = H_activity_leaf(tx_digest(tx) || le_u32(merge_idx(tx)))

activity_digest_lane(B) = MerkleRoot(
  [activity_leaf(tx) for tx in LaneTxList(B, lane)]
)

6. Block Context Verification

Applications needing verifiable time or score data:

MergesetContextHash(B) = H_mergeset_context(
    le_u64(timestamp) || le_u64(daa_score) || le_u64(blue_score)
)

Committed in both SeqStateRoot(B) and inside each touched lane-tip update.

7. Initial Block Download (IBD) Implementation

The KIP-21 Initial Block Download (IBD) implementation (PR #933 in Rusty-Kaspa) ensures that new nodes can properly sync and validate the chain history containing smart contract data, serving as a foundational requirement for vProgs.

To further bolster sync performance, a significant optimization was recently merged into Rusty-Kaspa to batch UTXO writes during IBD. This drastically reduces sync times and strengthens the core protocol in preparation for the increased data demands of vProgs.

Complementing the node-level IBD improvements in Rusty-Kaspa, the vProgs repository has recently introduced its own performance benchmarks and details on vProgs-specific IBD optimizations. This active measurement signals a shift toward refining the verifiable programs implementation for real-world efficiency and scalability.

To further ensure a smooth transition for nodes joining the new vProgs-enabled network, a core fix has also been merged into Rusty Kaspa to address IBD behavior during the specific ‘pre-toccata’ sync phase.

8. Transaction Versioning and Forward Compatibility

KIP-21’s sequencing commitment design explicitly builds in forward compatibility by standardizing on the modern Blake3 hashing algorithm and committing to the transaction version. This optimization allows vProgs to efficiently filter and ignore legacy transactions without wasting guest program resources parsing older formats. By committing to the version, vProgs can also securely and easily ignore transactions from future protocol upgrades they do not understand, ensuring long-term L2 stability.

What Is Still Coming (Post-KIP-21)

The Forward-Compatibility Guarantee

The critical design property of KIP-21’s proposed architecture is its forward compatibility. The specification explicitly separates the outer machinery (commitment structure, SMT, lane proofs) from the inner machinery (lane-local update rules):

+-------------------------------------------------------+
|  OUTER MACHINERY (KIP-21 -- stable)                    |
|                                                        |
|  SeqCommit(B) chaining                                 |
|  ActiveLanesRoot SMT                                   |
|  Two-anchor proof model                                |
|  Lane tip hash structure                               |
|  Reorg safety (SeqCommitDiff)                          |
|  IBD bootstrapping                                     |
+-------------------------------------------------------+
                        |
                        v
+-------------------------------------------------------+
|  INNER MACHINERY (changes per phase)                   |
|                                                        |
|  Phase 1 (now): Subnet-based lane extraction           |
|    - lane_id = tx.subnetwork_id                        |
|    - Activity = transaction list per lane per block     |
|                                                        |
|  Phase 2 (future): vProg CD-based lane update rules    |
|    - lane_id = vProg identifier                        |
|    - Activity = account-state vertex transitions       |
|    - Cross-lane composability via concise witnesses    |
+-------------------------------------------------------+

When vProgs arrive, only the lane-local update rules change. The SeqCommit chain, SMT structure, proof model, and all outer machinery remain unchanged. This means:

• SMT libraries built now will work with vProgs
• Lane proof circuits designed now will need only inner-logic modifications
• Witness store infrastructure built now will serve vProg provers directly
• Tools built against SeqCommit headers will continue to work

Architecture Position

+-------------------------------------------------------------------+
|                    vProgs Application Layer                         |
|         (DeFi, DAOs, Privacy, Enterprise -- FUTURE)               |
+-------------------------------------------------------------------+
|              Synchronous Composability Layer                       |
|    (Cross-vProg atomicity, proof stitching -- FUTURE)             |
+-------------------------------------------------------------------+
|              CD-Specific Lane Update Rules                         |
|    (Account-state vertices, per-vProg state -- FUTURE)            |
+-------------------------------------------------------------------+
|           KIP-21: Partitioned Sequencing Commitment         <-- HERE
|   +----------------+--------------------+------------------+      |
|   | ActiveLanes    | MergesetContext     | MinerPayload     |      |
|   | SMT (lanes)    | Hash (clock)       | Root (miners)    |      |
|   +--------+-------+---------+----------+---------+--------+      |
|            +------------------+---------+                         |
|                    SeqStateRoot(B)                                 |
|                         |                                          |
|              SeqCommit(B) = H_seq(parent, state)                  |
+-------------------------------------------------------------------+
|        Toccata / Covenants++ (KIP-16, KIP-17, KIP-20)            |
+-------------------------------------------------------------------+
|           Kaspa L1 BlockDAG + DagKnight Consensus                 |
+-------------------------------------------------------------------+

KIP-21 sits at a critical junction: above the raw consensus layer and below the application-specific vProgs logic. It establishes the commitment and proving infrastructure that both the initial standalone vProgs and the eventual fully composable system will use.

Key Takeaway

KIP-21 specifies five foundational elements for vProgs:

1. The lane abstraction – vProgs will be modeled as lanes
2. The commitment structure – SeqCommit(B) chains through selected-parent ancestry
3. The proving model – two-anchor, O(activity) per lane
4. The SMT specification – exact hashing, keying, and proof structure
5. Forward compatibility – the outer machinery stays, only lane-local rules change

Everything above KIP-21 in the stack (CD rules, composability, gas model, application layer) builds on this foundation. Everything at KIP-21’s level and below (SMT, commitment structure, lane proofs, witness store) is buildable today.

Further Reading

• L1 Sequencing (KIP-21) – the full KIP-21 specification details
• Architecture Overview – how sequencing fits the four-pillar architecture
• Account Model & State – the account model that CD-specific rules will implement
• Execution Model – how provers use the two-anchor model
• KIP-21 specification
• vProgs Yellow Paper

Implementation Pragmatism

As the vProgs framework transitions from theory to code, developers are actively optimizing the KIP-21 implementation. Pragmatic engineering improvements—particularly storage-saving changes—are being prioritized over rigid adherence to the original KIP text. This flexible approach ensures the specification evolves organically alongside practical discoveries made during the build process.

Implementation Progress

A major technical milestone for Kaspa’s virtual programmability layer has been reached with the opening of a pull request in rusty-kaspa by developer @biryukovmaxim for the implementation of KIP-21 (vProgs). This marks the first concrete code implementation of the partitioned sequencing commitment, transitioning the specification from theory into active node software.

To ensure stability and reviewability for the upcoming hard fork, developers are proposing a phased rollout strategy for the KIP-21 mempool. The initial implementation will feature simple, conservative selection logic for a limited number of lanes, with more advanced optimizations planned for post-hard-fork releases. Additionally, the lane-limited block selection algorithm is being designed to handle a high number of concurrent lanes. The emerging consensus favors a purely fee-market-driven approach over enforced fairness, preventing gaming and maintaining economic efficiency.

Active development on vProgs tooling also shows significant progress in scaling infrastructure for the KIP-21 mempool rollout. This ongoing work is critical for smoothly integrating verifiable programs into the main Kaspa network and efficiently handling the new lane-based transaction types.

Active development on the vProgs-enabled testnet (TN12) is driving the deep re-engineering efforts necessary to activate the partitioned sequencing commitment (KIP-21, also referred to as Coven-PoV). Recently, a core protocol change was implemented that modified the hash of v1 transactions, underscoring the technical complexity of integrating the new sequence data into the consensus layer.

Furthermore, the covenant code for KIP-21 is undergoing rigorous open community review. This transparent auditing process has facilitated collaborative problem-solving, recently leading to the confirmation of minor bug fixes and important clarifications regarding consensus-path code prior to deployment.

Core developer Michael Sutton has announced that the technical review for the main KIP-21 (vProgs) pull request by Maxim Biryukov is almost complete. This critical milestone signals that Kaspa’s programmability layer is moving closer to the final stages before implementation.

Kaspa is rapidly approaching the consensus feature freeze for the vProgs (KIP-21) upgrade. The core implementation has been successfully unified into the toccata development branch, officially finalizing the sequence commitment hashing mechanism and locking in essential features like ZK opcodes and gas commitments.

Simultaneously, the node’s communication layer has been hardened; a bug affecting the GRPC deserialization of transactions was identified and quickly resolved (PR #958), improving the reliability of core RPC services.

A major pull request in Rusty Kaspa has introduced Toccata lane and gas limits directly into the consensus rules. This is a foundational step for KIP-21, defining the economic and capacity constraints for vProgs on the Kaspa L1. Alongside these consensus rules, dedicated mempool policies for vProgs are being implemented to ensure transactions are validated for lane and gas limits before being considered for a block, drastically improving network efficiency and security.

Building on these mempool policies, a new pull request (PR #963) introduces a foundational, minimum-viable solution for a combinatoric challenge in mempool transaction selection. This lays the groundwork for future policy optimizations essential for handling the complex transactions vProgs will enable.

Rigorous testing of the vProgs framework on an internal devnet recently revealed several Sparse Merkle Tree (SMT) issues, prompting developers to introduce a minor release delay to prioritize essential stability fixes. Highlighting this commitment to robustness, a critical bug fix addressing incorrect blue score calculations during Initial Block Download (IBD) has been successfully merged. This patch serves as a crucial stabilization step for the core KIP-21 (vProgs) implementation in Rusty Kaspa.

To ensure the security and stability of the upcoming vProgs release, developers have proactively hardened the Rusty Kaspa codebase by merging a significant pull request (PR #970) that addresses security vulnerabilities and replaces unmaintained dependencies.

Simultaneously, deep technical work is underway on the storage engine, where a core developer is refining the database access layer API to better support secondary indexes. This refinement is fundamental for efficiently managing vProgs state and data.

Further enhancing state management, developers introduced a vital optimization for the Sparse Merkle Tree (SMT) via PR #972. By bounding prune branch deletions per block, this update prevents potential resource exhaustion, significantly improving the performance and robustness of vProgs data structures.

Kaspa’s developer testnet, TN12, has been successfully relaunched with an updated genesis block and major updates from the Toccata branch. It now natively supports KIP-21 sequence commitments, marking a critical step that allows developers to begin large-scale testing of vProgs and smart contract features.

Rothschild, the virtual state machine processor for vProgs (KIP-21), is now running stably on Testnet 12, achieving approximately 74.5 transactions per second. This serves as a major milestone, demonstrating the tangible performance capabilities of the vProgs implementation ahead of mainnet.

In tandem, developers are actively hardening the vProgs testnet (TN12) by addressing critical node crash errors, such as InsufficientDaaWindowSize. Furthermore, continuous core protocol hardening in Rusty-Kaspa has resolved a genesis-related edge case with the pruning point, ensuring a rock-solid foundation for upcoming vProgs features.

As the implementation matures, the formal specification for KIP-21 is being restructured for enhanced clarity and precision. The new approach involves maintaining a more abstract formal specification, supplemented by a separate document detailing the specific implementation within Rusty-Kaspa.

The vProgs proposal (KIP-21) is also being actively updated to reflect the latest protocol design, specifically adjusting consensus parameters to align with the recently introduced ‘script units’ KIP. This meticulous process ensures the formal specification precisely matches the final implementation, demonstrating careful integration between different protocol upgrades.

As the Toccata activation approaches, developers are polishing the mempool logic by separating template-fit checks from standardness rules, making vProgs transaction validation more explicit and robust. The rollout includes a delayed mempool policy to ensure a safe, conservative transition around the activation boundary. Furthermore, Kaspa’s mempool has been upgraded to solve an advanced multi-dimensional knapsack problem, optimizing block templates across standard mass, gas, transient mass, and lane limits. This is supported by architectural decisions that split block limits into independent types, enabling easier non-consensus refinements. Following testnet discussions, developers also plan to remove the TRANSIENT_BYTE_TO_MASS_FACTOR post-fork to simplify mass calculations and provide greater flexibility for adjusting transient data limits.

As the vProgs framework approaches maturity, developers are preparing to merge the dedicated toccata branch into master. This major integration consolidates a vast array of features and fixes, serving as a key prerequisite to unblock further core protocol advancement. The scale of this engineering effort was recently highlighted when the rusty-kaspa repository reached its 1,000th pull request—a critical, complex codebase change that necessitated a non-squash merge to preserve its detailed commit history. Simultaneously, developers maintain an intense focus on core protocol hardening, successfully rebasing and merging a rapid succession of pull requests (including PRs #995, #997, #998, and #1003) to secure core logic and bolster CI stability ahead of the upcoming hard fork.

Recent development efforts (such as PR #1011) have also focused on hardening vProgs consensus rules by clarifying and rigorously testing seqcommit transaction validation contexts. This work ensures the network remains stable and can safely handle complex edge cases, such as chain reorgs, post-activation.

External Verification and Data Availability

When external systems or L2 rollups need to verify a complete view of all vProgs lanes to guarantee Data Availability (DA), developers have determined that it is computationally more efficient to rebuild the entire SMT directly from its leaves rather than processing individual inclusion proofs for each lane. This architectural decision optimizes how rollups will synchronize and verify global L1 state.