Kaspa KIPs 16, 17, 20 and 21 are Active in the official specification repository. Pull request #45 merged on July 15, 2026 and replaced each proposal’s Testnet-10 implementation status with Active, aligning the documents with Toccata mainnet. The change records deployment status; it does not introduce another hardfork or new code.

Key takeaways

• Kaspanet KIPs PR #45 merged at 12:19:57 UTC on July 15, 2026.
• One commit changed the repository index and four KIP headers: five files, eight additions and eight deletions.
• KIP-16 covers OpZkPrecompile; KIP-17 covers covenants and scripting; KIP-20 covers covenant IDs; KIP-21 covers partitioned sequencing commitments.
• “Active” means the official proposal record now treats these specifications as deployed, not merely activated on Testnet-10.
• The PR is documentation-only. Toccata’s mainnet consensus activation had already occurred on June 30.
• Active status does not certify every application, wallet, SDK or proof system built on the features.

What exactly changed in KIPs pull request #45?

The pull request title is direct: “Mark kips 16,17,20,21 as active.” Its single commit changed the status column in the repository README.md and the status field near the top of each KIP document.

Before the merge, KIPs 16, 20 and 21 were labelled “Proposed, Implemented and activated in TN10” or an equivalent Testnet-10 phrase. KIP-17 was labelled “Implemented and activated in TN10.” After the merge, all four say Active. The repository index now shows the same status.

The diff did not modify opcode numbers, hashing rules, transaction fields, activation parameters or node software. It added eight lines and removed eight lines because each status string was replaced in both the index and specification headers. A reviewer approved the change, and it merged to the KIPs master branch.

This distinction prevents a common timeline error. July 15 is the specification-status milestone. It is not the date on which mainnet first began enforcing Toccata. Kasmedia’s Toccata launch record places activation on June 30 at DAA score 474,165,565.

What does KIP-16 make Active?

KIP-16, “New Transaction Opcodes for Verifiable Computation,” defines OpZkPrecompile at opcode 0xa6. A tag dispatches to a supported zero-knowledge verifier with proof-system-specific stack arguments.

The initial specification describes Groth16 under tag 0x20 and RISC0-Succinct under tag 0x21. Both bind a proof to defined public inputs or to a program image and journal relationship. This gives Kaspa scripts a native mechanism for verifying supported off-chain computation.

Active status does not mean arbitrary proof systems can be invoked. It does not make proof generation free, guarantee privacy or remove dependency risk from external cryptographic libraries. Developers must use the supported interface and current implementation.

What does KIP-17 make Active?

KIP-17, “Covenants and Improved Scripting Capabilities,” expands the information and operations available to Kaspa scripts. It defines transaction-introspection opcodes, byte concatenation and substring operations, signature verification from the stack, additional hashes, bitwise operations and numeric conversions.

The central application is a covenant: a UTXO script can constrain properties of the transaction that spends it. This allows controlled state transitions, such as requiring a successor output to preserve a script and carry an updated state value.

KIP-17 also raises certain script-engine ceilings after activation, while transaction mass and compute pricing provide practical limits. “More expressive” does not mean unmetered or compatible with every existing smart-contract environment.

What does KIP-20 make Active?

KIP-20, “Covenant IDs,” adds a consensus-tracked 32-byte identifier to covenant UTXOs and an optional binding to transaction outputs. A continuation output can carry the same ID when authorized by an input from that lineage. A genesis ID is derived from a unique outpoint and its authorized initial outputs.

The result is a stable application identity across UTXO transitions. Wallets and indexers can follow a covenant instance even though each spend replaces its outpoint. Consensus also prevents a third party from simply declaring an arbitrary output to be part of an existing covenant lineage.

The ID proves lineage under the protocol rule, not the truth of an off-chain claim. If an application labels a covenant as a dollar, security, ticket or collectible, its legal and economic meaning still depends on evidence outside the ID.

What does KIP-21 make Active?

KIP-21, “Partitioned Sequencing Commitment with O(activity) Proving,” changes how post-activation chain blocks commit to transaction sequencing state. Accepted transactions are grouped by subnetwork lane. Recently active lane tips are committed in a sparse Merkle structure, and the header retains a single recursive sequencing commitment.

The design goal is to let an application-lane prover work in proportion to relevant lane activity instead of consuming every transaction in a global stream. It also commits selected-parent context and mergeset miner payloads and defines inactivity purging so the active lane set remains bounded by recent activity.

KIP-21 provides commitment and witness foundations. It does not deploy a complete rollup, data-availability service or application by itself. Those systems must still define execution, proving, user access and failure handling.

Why is an Active specification status useful?

An accurate status label helps four audiences. Node implementers can distinguish deployed rules from research proposals. SDK and compiler developers can target the correct consensus surface. Auditors can cite a stable specification instead of a testnet label. Readers can reconstruct the rollout timeline without assuming that a proposal still awaits mainnet.

It also improves entity clarity for search and AI systems: “KIP-16 is Active” is now a claim directly supported by the official KIP header and repository index. The earlier Kaspa Toccata feature guide explains the user-facing relationship among the four documents, while this article records their formal repository status.

For market analysis, the status update should remain separate from price attribution. The Kaspa price after Toccata followed a volatile two-way path; neither the activation nor this later documentation merge proves a price effect.

What Active does not mean

Active does not mean immutable. Specifications can receive clarifications, corrections or companion documents, and implementations can issue maintenance releases. Anyone building consensus-sensitive software should pin and review the exact KIP and code revisions used.

It does not mean every ecosystem component supports every field. Wallets, exchanges, pools and indexers must preserve version-1 transactions, compute budgets, covenant bindings, covenant IDs and sequencing-proof data relevant to their role.

It also does not endorse every product invoking Toccata terminology. Users should verify code repositories, audits, contracts and operator disclosures independently. For readers engaging with the ecosystem outside technical infrastructure, KaspaBuy’s guide to finding Kaspa merchandise is a separate retail resource, not evidence about protocol adoption.

Frequently asked questions

Did PR #45 activate Toccata?

No. It updated specification statuses after activation. The PR contains documentation changes in the KIPs repository, not rusty-kaspa consensus code.

Are all four KIPs independent?

They have distinct scopes but complement one another. Covenants use introspection, covenant IDs give those applications lineage, ZK verification supports off-chain computation proofs, and partitioned commitments support lane-oriented proving.

Is Testnet-10 no longer useful?

No. The status change means the specifications are active on mainnet; test networks remain valuable for integration testing and future development without risking mainnet funds.

What was the authoritative status at publication?

At 12:49 UTC on July 15, 2026, the official kaspanet/kips master branch listed KIPs 16, 17, 20 and 21 as Active following the merge of PR #45 approximately 29 minutes earlier.

Source and verification note

This article is based on kaspanet/kips PR #45, merged July 15, 2026. The public diff changes README.md plus kip-0016.md, kip-0017.md, kip-0020.md and kip-0021.md; each specification header and the index now say Active. Technical summaries were checked against those four documents. The article reports repository state at publication and does not treat the status edit as a second activation event.