Covenant Stack

Covenants are spending conditions that UTXOs carry forward. Instead of only checking who can spend a coin (via signature), a covenant enforces how the coin must be spent – where funds go next, when they can move, and what the next transaction must look like. In Kaspa, covenants are the consensus layer that both Silverscript (local-state contracts) and vProgs (shared-state programs) build on top of.

This page covers the full KIP stack from the Crescendo foundation through the Toccata hard fork (Covenants++), the five milestones toward vProgs, and the current testing status on TN12.

Two-Phase KIP Stack

Kaspa’s covenant infrastructure is built across multiple KIPs, activated in two hard fork phases:

+-------------------------------------------------------------------+
|              TOCCATA HARD FORK -- ~June 5-20, 2026                 |
|   +------------+-------------+------------+--------------------+   |
|   | KIP-16     | KIP-17      | KIP-20     | KIP-21             |   |
|   | ZK verify  | Auth/Cov    | Covenant   | Lane SeqCommit     |   |
|   | opcodes    | opcodes     | IDs        |                    |   |
|   +------------+-------------+------------+--------------------+   |
+-------------------------------------------------------------------+
|              CRESCENDO HARD FORK -- Activated                      |
|   +------------+-------------+------------+--------------------+   |
|   | KIP-9      | KIP-10      | KIP-13     | KIP-15             |   |
|   | Storage    | Intro-      | Transient  | SeqCommit          |   |
|   | mass       | spection    | mass       | recurrence         |   |
|   +------------+-------------+------------+--------------------+   |
+-------------------------------------------------------------------+
|           Kaspa L1 BlockDAG (10 BPS) + DagKnight                   |
+-------------------------------------------------------------------+

Phase 1: Crescendo Hard Fork (KIP-14) – Activated

The Crescendo hard fork increased Kaspa from 1 BPS to 10 BPS and activated the foundational covenant KIPs:

Crescendo also enabled transaction payloads for native (non-coinbase) transactions, allowing arbitrary data in the payload field – the preliminary mechanism for L2 smart contract data availability.

KIP-10: Transaction Introspection (The Foundation)

KIP-10 is the bedrock – it gave Kaspa scripts the ability to inspect the spending transaction. Without this, no covenants are possible.

Opcodes Introduced

Transaction-level:

Input/Output query:

Enhanced arithmetic: 8-byte integer support (previously 4-byte), enabling precise financial calculations.

What Introspection Enables

With introspection, a script can:

• Verify that outputs go to specific addresses
• Enforce minimum output amounts
• Require that change returns to the same contract
• Validate that transaction structure matches expected patterns

Example: Threshold Covenant

A UTXO that can only be spent by adding value (threshold covenant):

OP_IF
   <owner_pubkey> OP_CHECKSIG
OP_ELSE
   // Verify output goes to same script address
   OP_TXINPUTINDEX OP_TXINPUTSPK
   OP_TXINPUTINDEX OP_TXOUTPUTSPK OP_EQUALVERIFY
   // Verify output value >= input value + threshold
   OP_TXINPUTINDEX OP_TXOUTPUTAMOUNT
   <threshold_value> OP_SUB
   OP_TXINPUTINDEX OP_TXINPUTAMOUNT
   OP_GREATERTHANOREQUAL
OP_ENDIF

Phase 2: Toccata Hard Fork (Covenants++) — ~June 5–20, 2026

The upcoming hard fork, officially named “Toccata,” extends covenants with four major KIPs. Feature freeze is April 15, 2026.

KIP-16: ZK Verification Opcodes

KIP-16 bridges covenants and vProgs:

• Adds opcodes for verifying ZK validity proofs on L1
• External execution environments submit proofs; L1 validates cryptographically
• Supports Groth16 and RISC Zero STARK proof systems
• Combined with KIP-17, enables “ZK covenants” – UTXOs whose spending conditions include ZK proof verification

See ZK Verification for the full ZK stack architecture.

To ensure the absolute integrity of these zero-knowledge proofs leading into the vProgs feature freeze, a critical, consensus-breaking fix for the ZK opcode (PR #957) is currently being integrated from upstream RISC Zero.

KIP-17: Extended Covenant Opcodes

KIP-17 adds the auth and covenant binding system that Silverscript’s declaration macros compile to:

Auth Binding (OpAuth*):

• Per-input authorization
• Default for 1:N patterns (one input, multiple outputs)
• Tracks authorization groups per input

Cov Binding (OpCov*):

• Shared covenant context across multiple inputs
• Required for N:M patterns (multiple inputs and outputs)
• Covenant ID derived from OpInputCovenantId

State Validation:

• validateOutputState(outputIndex, newState) – verifies that an output’s scriptPubKey is P2SH paying to the same contract code with updated state
• readInputState() – reconstructs prior state from transaction context

These opcodes make stateful UTXO contracts possible – a covenant can carry state forward across transactions.

Recent progress in the covenant infrastructure includes the solidifying of serialized covenant binding integration, a cornerstone feature for managing state within Kaspa’s upcoming smart contract capabilities.

KIP-20: Covenant IDs (Native Lineage)

Before KIP-20, proving that a UTXO descended from a specific covenant required recursive lineage proofs – expensive and complex. KIP-20 introduces native covenant IDs at the protocol level:

• Each covenant UTXO carries an ID tracking its lineage
• The protocol enforces lineage without script-level recursion
• Enables OpInputCovenantId and OpCovOutputCount
• Critical for Silverscript’s groups = single enforcement (ensuring a covenant has exactly one continuation)

KIP-21: Partitioned Sequencing Commitment

KIP-21 replaces the monolithic sequencing commitment with lane-based partitions:

• Each application lane maintains its own recursive tip hash
• Enables O(activity) ZK proving per application
• Forward-compatible with vProg lane families

See L1 Sequencing (KIP-21) for the full specification.

Additional Covenants++ Features

The hard fork also introduces:

• Native assets – first-class asset support on L1
• CDAG – structured dependency tracking for vProgs
• Miner payload commitments – coinbase payload data committed under SeqCommit(B)

Preparation for the Toccata activation is actively underway at the protocol level. A recent update (PR #952) introduces a specific consensus rule change to set the coinbase transaction version to 1. This foundational adjustment ensures the block structure is ready to support the new data requirements for vProgs and Covenants++.

KIP-15 + KIP-21: Sequencing Commitment Evolution

The sequencing commitment has evolved across both hard forks:

KIP-15 (Crescendo): Introduced recursive sequencing commitments:

SeqCommit(B) = hash(SeqCommit(parent(B)), AcceptedIDMerkleRoot(B))

This secured transaction ordering for L2 use but was monolithic – all transactions committed in one stream.

KIP-21 (Covenants++): Partitions the commitment into lanes, replacing the single AcceptedIDMerkleRoot with a layered structure:

SeqCommit(B) = H_seq(SeqCommit(parent(B)), SeqStateRoot(B))

SeqStateRoot(B) = H_seq(ActiveLanesRoot(B),
                        H_seq(MergesetContextHash(B),
                              MinerPayloadRoot(B)))

Together, these provide the anchoring infrastructure that ZK provers use to verify state transitions against L1.

Covenant Families and Template Selectors

KIP-20 Covenant IDs track lineage, but in multi-contract applications a single covenant ID is shared across an entire covenant family – a group of cooperating contracts that form one logical application.

Within a family, contracts are distinguished by injected template selectors – fields baked into each contract that declare its specific role. For example, in a chess application the family might contain Player, Mux, Worker, and Settle contracts, all sharing the same covenant ID but carrying different template selectors.

This creates a two-layer identity system:

Contracts carry peer template fields (player_template, league_template, mux_template) so they can verify they are interacting with the correct role within their family.

Inter-Covenant Communication (ICC)

Because Kaspa’s UTXO model has no global state or central virtual machine, two covenants cannot simply “call” each other. ICC solves this isolation.

The Mechanism: Cross-Family Authorization

ICC is a cross-family authorization pattern that relies on the atomic nature of blockchain transactions. Instead of traditional function calls, covenants communicate via shared transaction authorization (plain-text messaging in the UTXO context).

How it works:

1. A single transaction is created that includes an input from Covenant Family A and an input from Covenant Family B.
2. Because transactions are atomic (all inputs validate or the entire transaction fails), Covenant A does not need to re-execute Covenant B’s logic.
3. Covenant A’s script inspects the transaction and says: “I see that an input from Covenant B is included in this same transaction. I will authorize my part of the state change, provided Covenant B also successfully authorizes its part.”

Example: Native Asset Ownership

A user owns a Native Asset managed by an Asset Covenant, and has a Player Covenant (their durable identity).

To spend the asset:

• The transaction includes the Asset UTXO (Input 1) and the Player UTXO (Input 2).
• The Asset Covenant logic: “Allow this asset to be spent IF the Player Covenant is also an input in this transaction.”
• The Player Covenant logic: “Authorize myself to be spent IF the user provides the correct cryptographic signature.”

Because the transaction fails instantly if the user cannot sign the Player Covenant, the Asset Covenant effectively “knows” the user is authenticated – without containing any complex authentication logic itself.

Transaction (atomic -- all-or-nothing):
  Input 1: Asset Covenant    → checks: "Is Player Covenant present?"
  Input 2: Player Covenant   → checks: "Is user signature valid?"
  Output 1: Asset Covenant   → (updated asset state)
  Output 2: Player Covenant  → (recreated identity state)

Why ICC Matters

ICC enables deeply fragmented applications. Instead of monolithic smart contracts, developers build highly specialized, lightweight UTXOs that interact securely. Two independent state machines can confidently agree on a shared outcome simply by participating in the same atomic transaction.

Multi-Contract Flows (MCF)

MCF is the core architectural pattern that enables complex applications on the UTXO model. Instead of one heavy contract containing all logic, the logic is split across multiple specialized contracts within a covenant family.

Pattern 1: Multiplexing (Mux)

A single entry contract (the mux) owns shared state, authenticates user intent, commits a pending state, and selects a specific worker based on a selector. The worker performs one narrow job and returns state back to the mux.

User → Mux (shared state, authentication, routing)
         ↓ selector
       Worker A (narrow validation, e.g. verify pawn move)
         ↓
       Mux (updated state)

Pattern 2: Role Systems

Different contracts handle different episodic roles within the application lifecycle:

Chess Demo: MCF in Practice

The chess game built with SilverScript demonstrates both MCF patterns:

• Covenant family: All chess contracts share a single covenant ID
• Multiplexing: The mux contract owns the board state and routes each move to the correct worker (one per piece movement rule)
• Role system: League handles registration, Player contracts hold identity/funds/score, Game contracts track the episodic match state
• ICC: Player covenants authorize moves by co-signing transactions with Game covenants
• Workers: Each worker validates a single type of chess move (e.g., pawn advance, castle, en passant), keeping individual scripts small and bounded

This architecture keeps every individual contract lightweight while enabling complex multi-party, stateful game logic entirely on L1.

Five Milestones to vProgs

Michael Sutton’s Covenants++ milestones gist outlines a phased path from covenants to full vProgs:

Milestone 1: Inline ZK Covenant (WIP)

Users submit covenant actions with ZK proofs as unified units:

• State transition function f(state, action) -> new_state delegated to ZK prover
• State hashes opaque to L1 – passed only to verification opcodes
• Challenge: blake2b is ZK-unfriendly; L1-side parent validation proposed for user proofs
• Uses Tier 1 ZK stack (Noir / Groth16)

Milestone 2: Based ZK Covenant with Inefficient SeqCommit

Shift from inline to “based rollup” style:

• Users submit actions via payloads targeting specific programs
• Provers aggregate multiple user actions into single proofs
• Proving scales as O(global DAG activity) – inefficient but functional
• Requires ZK-friendly Blake3 for seqcommit (adopted in KIP-21)
• OpChainblockSeqCommit opcode reads seqcommit from chain-block headers

Milestone 3: Canonical Kaspa Bridge – COMPLETE

The canonical bridge enables sovereign vProgs to settle on L1:

• Script engine access to Blake3-hash all transaction outputs for ZK public arguments
• Sovereign exit/settlement mechanism for standalone vProgs
• Solves the “many to const” bridging problem

Status: Completed February 19, 2026. Maxim Biryukov demonstrated a full ZK Covenant Rollup PoC including deposits via delegate script, L2 transfers, withdrawals via permission tree, both STARK and Groth16 proof generation + on-chain verification, sequence commitment chaining, sparse Merkle tree for L2 account state, and full on-chain script verification.

Milestone 4: Native Asset Canonical Bridge

Extends the bridge to native assets:

• Requires Inter-Covenant Communication (ICC) protocol
• Cross-family authorization via shared transaction co-signing (see ICC section above)
• Enables native asset deposits and withdrawals through the canonical bridge

Milestone 5: Optimal SeqCommit (KIP-21)

Reduces proving from O(global activity) to O(vProg activity):

• Degenerate CD tracks program/subnet vertices instead of account-level fine-grained vertices
• This is what KIP-21 delivers
• Enables the standalone vProgs deployment (Phase 1)

Beyond the Milestones

vProgs-Based Rollup (VBR):

• Single ZK covenant on L1 represents entire VBR state
• Enables L2-internal synchronous composability
• Follows vProg programming model: global registration, account-based execution, read-write declarations
• Runtime: hmoog/kas-l2 repository

Full vProgs Specification (End Goal):

• Synchronously composable sovereign vProgs
• Extended Computation DAG with per-account modeling
• CD-based scope gas calculations
• Global vProg state index
• Transaction v2 structure
• Data witness verification
• Global vProg code registry

Milestone Progress Diagram

+-------------------------------------------------------------------+
|   Milestone 1: Inline ZK Covenant                    [WIP]         |
|   (User proves own transaction)                                    |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   Milestone 2: Based ZK Covenant                     [WIP]         |
|   (Prover aggregates; O(DAG activity) proving)                     |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   Milestone 3: Canonical Bridge                      [COMPLETE]    |
|   (KAS deposits/withdrawals via ZK proofs)                         |
|   Completed: Feb 19, 2026                                          |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   Milestone 4: Native Asset Bridge                   [IN PROGRESS] |
|   (ICC protocol for native assets)                                 |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   Milestone 5: Optimal SeqCommit (KIP-21)            [IMPLEMENTED] |
|   (O(vProg activity) proving via lane partitions)                  |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   vProgs-Based Rollup (VBR)                          [FUTURE]      |
|   (L2 syncompo via single ZK covenant)                             |
+-------------------------------------------------------------------+
                              |
+-------------------------------------------------------------------+
|   Full vProgs Specification                          [FUTURE]      |
|   (Syncompo, CD, registry, tx v2)                                  |
+-------------------------------------------------------------------+

ZK Stack Selection

The ZK strategy was finalized in January 2026, establishing three tiers that map to the milestone progression:

Key decisions:

• Noir for inline ZK: Fast enough for per-transaction proving, even on mobile
• Cairo for rollups: Sierra bytecode provides provable metering and safety for user-submitted logic
• BLAKE3 for commitments: ~40% better than BLAKE2s in SP1/RISC Zero (the primary proving tier)

See ZK Verification for full details.

Proof System Debate: An active architectural discussion is underway regarding the baseline zero-knowledge proof system. Developers are weighing whether to implement industry-standard Groth16 (G16) proofs immediately to accelerate ecosystem growth, or to prioritize Post-Quantum (PQ) cryptography from the outset to ensure long-term security. This decision is crucial for future-proofing Kaspa’s smart contract capabilities.

Testing: TN12

Testnet-12 is the experimental testnet for the Covenants++ hard fork.

Timeline

Features on TN12

The February 9 reset included:

• Covenant IDs (KIP-20) – native lineage tracking
• Blake3-based sequencing commitment opcode (OpChainblockSeqCommit)
• ZK verify precompiles + opcodes for Groth16 and RISC Zero
• KIP-17 covenant opcodes (auth/cov binding)
• Silverscript compiler (experimental)
• Native asset testing

Opcode numbers agreed January 17, 2026: 0xcf-0xd3 for covenant ID ops, 0xd4 for seqcommit.

Developers have clarified that the covpp-reset2 development branch is where the newest vProgs features are actively being built, keeping it distinct from the current tn12 Toccata testnet branch. This directs integrators to the correct environment for experimenting with cutting-edge capabilities. As the vProgs feature set stabilizes, developers plan to officially rename this branch to “toccata”, aligning the codebase directly with the next major hard fork.

Developers are actively planning a reset of Testnet 12 (TN12) to deploy the latest vProgs-enabled node software, marking a new phase of public testing for KIP-21.

How the Stack Fits Together

The complete architecture from base layer to application:

+-------------------------------------------------------------------+
|              Full vProgs (Syncompo, CD, Registry)                   |
|                        END GOAL                                    |
+-------------------------------------------------------------------+
|              vProgs-Based Rollup (VBR)                              |
|              (L2 syncompo via single ZK covenant)                  |
+-------------------------------------------------------------------+
|    Milestone 5           |    Milestone 3-4                        |
|    KIP-21 Optimal        |    Canonical Bridge                     |
|    SeqCommit             |    (KAS + Native Assets)                |
+-------------------------------------------------------------------+
|    Milestone 2: Based ZK Covenant                                  |
|    (Provers aggregate; O(DAG activity) proving)                    |
+-------------------------------------------------------------------+
|    Milestone 1: Inline ZK Covenant                                 |
|    (User submits proof + action as one unit)                       |
+-------------------------------------------------------------------+
|                TOCCATA HARD FORK -- ~June 2026                     |
|   +------------+-------------+------------+--------------------+   |
|   | KIP-16     | KIP-17      | KIP-20     | KIP-21             |   |
|   | ZK verify  | Auth/Cov    | Covenant   | Lane SeqCommit     |   |
|   | opcodes    | opcodes     | IDs        |                    |   |
|   +------------+-------------+------------+--------------------+   |
+-------------------------------------------------------------------+
|    Silverscript (compiles to KIP-10/17/20 covenant scripts)        |
+-------------------------------------------------------------------+
|                CRESCENDO HARD FORK -- Activated                    |
|   +------------+-------------+------------+--------------------+   |
|   | KIP-9      | KIP-10      | KIP-13     | KIP-15             |   |
|   | Storage    | Intro-      | Transient  | SeqCommit          |   |
|   | mass       | spection    | mass       | recurrence         |   |
|   +------------+-------------+------------+--------------------+   |
+-------------------------------------------------------------------+
|           Kaspa L1 BlockDAG (10 BPS) + DagKnight                   |
+-------------------------------------------------------------------+

Further Reading

• Architecture Overview – how the covenant stack fits the four-pillar architecture
• Silverscript – the language that compiles to covenant scripts
• ZK Verification – KIP-16 verifier opcodes
• L1 Sequencing (KIP-21) – partitioned sequencing commitment
• Covenant++ Milestones (Sutton gist)
• KIP-14: Crescendo Hardfork
• KIP-10: Transaction Introspection
• ZK Rollup PoC (Biryukov)