Kaspa developer Michael Sutton has published KIP-21, a draft protocol proposal that introduces partitioned sequencing commitments — a foundational change that makes Kaspa significantly more practical as a base layer for zero-knowledge applications.
What Is KIP-21?
Kaspa core developer Michael Sutton published KIP-21 on February 17, 2026 — a draft consensus proposal titled “Partitioned Sequencing Commitment with O(activity) Proving.” The proposal is currently open for review as a pull request against the official kaspanet/kips repository and represents one of the more technically significant protocol-level developments in Kaspa’s zk roadmap to date.
At its core, KIP-21 changes how Kaspa commits to transaction data at the consensus level, with the primary goal of making zk proof generation dramatically more efficient for application-specific use cases.
The Problem KIP-21 Solves
To understand why KIP-21 matters, it helps to understand how Kaspa currently handles sequencing commitments.
Every chain block on Kaspa today commits to all accepted transactions as a single global append-only list. This works well enough for base-layer consensus, but it creates a significant bottleneck for zero-knowledge proving systems that need to verify what happened on the base layer.
The issue is that zk provers working on a specific application — say, a Layer 2 rollup or a smart contract-style system running on a particular subnet — have to process the entire network’s transaction activity in every block, even if they only care about a small fraction of it. As Kaspa’s throughput scales, this cost grows proportionally with total network activity, not with the activity of the specific application being proven.
In practical terms, this makes building efficient zk applications on Kaspa increasingly expensive as the network grows — exactly the opposite of what a scalable base layer should do.
How KIP-21 Fixes It: Lanes
KIP-21 introduces the concept of lanes. Instead of committing to all transactions as one global stream, the protocol splits activity by application — each application subnet gets its own dedicated commitment track, or lane, with its own recursive tip hash.
A zk prover working on one specific application now only needs to process data relevant to that lane. Proof cost scales with lane activity, not global network throughput. Sutton describes this as achieving “O(activity) proving” — a significant efficiency improvement for application-specific proving workloads.
For the initial implementation, lanes are extracted from transaction subnetwork IDs, keeping the mechanism consensus-native and deterministic with current transaction structure. Future proposals may define finer-grained lane extraction, including account-level lanes, while reusing the same commitment infrastructure.
What Else KIP-21 Commits
Beyond the lane structure itself, KIP-21 also commits additional data that based zk systems require:
Per-block context. Each block commits to its timestamp, DAA score, and blue score as part of the sequencing state root. This gives zk provers a verifiable clock and height-like indices without requiring them to process full block headers separately.
Miner payloads from mergeset blocks. Coinbase payload bytes from all mergeset blocks — including blocks whose coinbase transactions are not accepted — are committed via a dedicated block-level path. This is relevant for Layer 2 designs that rely on miner signaling data or payout construction logic.
Inactive lane cleanup. Lanes that go untouched beyond a defined inactivity threshold are automatically purged from the active commitment set, keeping memory usage bounded as the number of subnets grows over time.
The Proving Model
KIP-21 is designed around a two-anchor lane proof model. A prover working on a specific lane provides two global anchors — a start and end sequencing commitment — along with lane-inclusion witnesses under both anchors, and a compressed lane-level transition proof between them.
The size of that transition proof is proportional to lane activity between the two anchors, not to the total number of chain blocks in between. This is the key efficiency gain: an application with modest activity on a high-throughput network pays only for its own footprint, not for the network’s global throughput.
For lanes that go inactive and later reappear, the proposal defines a reactivation proving pattern using non-inclusion checkpoints, allowing provers to demonstrate continuity without retaining historical lane tips for inactive periods.
What This Means for Kaspa’s ZK Roadmap
KIP-21 sits within Kaspa’s broader Covenants++ workstream, which includes KIP-16, KIP-17, and KIP-20. TN12, the experimental testnet for Covenants++, already includes those proposals along with the OpChainblockSeqCommit opcode that KIP-21 defines commitment semantics for.
The proposal is explicitly designed to remain forward-compatible with a future account-level lane model under the vProgs computation design (vProgs CD), meaning zk provers built over the current subnet-lane logic would continue to operate without replacement after a potential future upgrade.
In broader terms, KIP-21 represents the kind of foundational infrastructure work that determines whether Kaspa can practically serve as a base layer for zk applications — not just theoretically compatible with zero-knowledge proofs, but efficient enough to make building on top of it viable at scale.
Technical Summary
| Parameter | Detail |
|---|---|
| KIP Number | KIP-21 |
| Author | Michael Sutton |
| Status | Draft |
| Created | February 17, 2026 |
| Type | Consensus hard fork |
| Activation | Requires network-wide node upgrade |
| Lane extraction | Transaction subnetwork ID (initial) |
| Hash function | BLAKE3 with domain separation |
| SMT depth | 256-bit fixed depth sparse Merkle tree |
Current Status
KIP-21 is at draft stage. A pull request is open against the kaspanet/kips repository for community and developer review. As a consensus-level hard fork, adoption would require all nodes on the network to upgrade. No activation timeline has been announced.
The KIP and pull request are publicly available on GitHub for anyone wanting to review the full technical specification.
