Kaspas Upcoming Covenant-Centric Hardfork: What We Know

Table of Contents

What Is Kaspas Covenant-Centric Hardfork？What Is the Timeline for the May 5, 2026 Hardfork？How Do Native Assets and Covenants Work on Kaspa？What Is the Computational $DAG (CDAG)？What Are vProgs and How Do They Differ From Smart Contracts？What Role Does Zero-Knowledge (ZK) Play？How Does Sparkle Relate to vProgs？Will the Hardfork Affect Security, MEV, or Node Requirements？What Does SilverScript Add？ConclusionSources:Frequently Asked Questions

What Is Kaspas Covenant-Centric Hardfork？

According to Terahs thread,Kaspa is preparing a covenant-centric hardfork scheduled for mainnet activation on May 5, 2026. The upgrade expands Layer 1 (L1) programmability by introducing native assets and extended covenant functionality. It also lays the groundwork for verifiable programs (vProgs) and zero-knowledge (ZK) integrations.

Kaspa operates as a proof-of-work blockchain using a blockDAG architecture. Its Crescendo upgrade in May 2025 increased throughput to 10 blocks per second (BPS). Thus, the upcoming hardfork builds on that foundation without changing node requirements or consensus fundamentals.

Core developers describe the release as a scoped upgrade. It focuses on enabling native token issuance, programmable spending rules, and ZK verification on L1.

What Is the Timeline for the May 5, 2026 Hardfork？

Kaspa Convenant-centric Hard Fork Countdown as of the time of writing | Kas.live

Several milestones precede the mainnet activation, according to Terahs thread:

• Testnet 12 (TN12) Reset:Scheduled for early February 2026 to support covenant and native asset testing.
• Sequencer Commitment KIP:Expected around February 12, 2026. This proposal introduces miner payload commitments to strengthen real-time decentralization.
• SilverScript Release:A high-level programming language for writing programs on Kaspa. Developed by Ori Newman and contributors, it simplifies covenant development.
• Mainnet Hardfork:May 5, 2026.

Post-hardfork upgrades include DAGKnight, targeting adaptive consensus and throughput above 100 BPS, and the full deployment of vProgs.

How Do Native Assets and Covenants Work on Kaspa？Native Assets on Layer 1

The hardfork introduces native assets, including support for KRC20 tokens. These assets exist directly on L1 and can be transferred atomically.

Atomic transfers apply to:

• Regular inline covenants
• ZK and non-ZK covenant executions
• KRC20 token transfers

Inline covenants generate immediate proofs within the wallet. There is no decoupling between transaction data and state transition. This design supports atomicity and deterministic execution.

Extended Covenants (Covenants++)

Kaspas covenant system is inspired by Bitcoin research on programmable UTXO spending conditions. Covenants++ extends this system to allow more expressive transaction rules.

Use cases include:

• Vault-style security controls
• Escrow mechanisms
• Conditional transfers
• Structured token logic

The system maintains a UTXO model rather than full account-based smart contracts.

What Is the Computational $DAG (CDAG)？

The hardfork introduces the Computational $DAG (CDAG).CDAG records all read and write declarations made by programs.

This structure:

• Tracks resource usage
• Regulates dependencies between programs
• Enforces gas commitments

The design is comparable to execution models in blockchains such as Solana and Sui, but implemented in full form within Kaspas blockDAG environment.

CDAG plays a central role in enabling vProgs sovereignty.

What Are vProgs and How Do They Differ From Smart Contracts？

vProgs are sovereign programs that execute outside L1 while settling results on L1 through proofs.

Key properties:

• Sovereign execution:Each vProg defines its own throughput and dependency rules.
• Gas-based dependency control:A vProg cannot read another vProgs state unless it pays gas for the resource consumption.
• Non-atomic transfers:vProgs are not transparent to L1 in the same way as native assets. Transfers are asynchronous and non-atomic.
• Wrapped $KAS requirement:Any non-inline covenant must use wrapped $KAS through a canonical bridge. Native L1 $KAS cannot be used directly.

This design separates computation and state from L1 while preserving shared sequencing and settlement.

Who Should Build vProgs？

According to community discussions, most regular application developers may not need vProgs.

However, vProgs may appeal to:

• Appchain architects
• Teams evaluating rollup-style systems
• Projects building AI agents with a large on-chain state
• System designers comparing L1 contracts, L2 rollups, and hybrid models

vProgs combine unified L1 sequencing with externalized state and computation.

What Role Does Zero-Knowledge (ZK) Play？

The hardfork integrates ZK verification on L1, extending earlier proposals such as KIP-16.

Supported capabilities include:

• Groth16 proof verification
• Trustless bridges to L2 systems
• Potential privacy-oriented applications

Initial applications are expected to run in-line, with wallets generating proofs directly. Even covenant-based ZK implementations developed by contributors such as Hans and Maxim are expected to run on commodity hardware. No specialized prover infrastructure is required for early deployments.

A standard laptop can generate proofs under the current assumptions.

Privacy-focused programs are technically possible after the hardfork. However, privacy is not listed as a primary focus of the roadmap.

How Does Sparkle Relate to vProgs？

Sparkle is an architecture proposed by Anton for combining computational DAGs and ZK proofs. While both Sparkle and vProgs use CDAG and ZK components, they address different design questions.

The defining feature of vProgs is dependency regulation. Each program controls its throughput and avoids arbitrary external dependencies. This model supports composability while preserving isolation.

Will the Hardfork Affect Security, MEV, or Node Requirements？

• Security Budget:No direct impact is expected in the short term. Improvements depend on real product adoption rather than infrastructure changes.
• Node Requirements:No changes.
• MEV Kickback Auctions:Considered premature given the current stage of ecosystem development.
• PoW Grinding for STARKs:Discussions reference historical behavior on early Ethereum, where addresses with leading zeros reduced gas costs, which in turn led to proof-of-work grinding markets. The mention was contextual rather than a current feature.

What Does SilverScript Add？

SilverScript is a high-level language designed for Kaspa programs. It aims to simplify covenant and program development.

Its design goals include:

• Readable syntax
• Accessibility for new developers
• Compatibility with automated tooling

SilverScript is expected to lower the barrier for writing covenant-based applications once native assets go live.

Conclusion

Kaspas covenant-centric hardfork expands Layer 1 functionality through native assets, extended covenants, and ZK verification. It introduces CDAG for structured dependency tracking and lays the foundation for sovereign vProgs. The upgrade preserves existing node requirements and proof-of-work consensus while enabling programmable token issuance and atomic transfers.

The May 5, 2026, activation marks a technical step in Kaspas roadmap. It adds structured programmability at the protocol level and prepares the network for further upgrades, including DAGKnight and full vProgs deployment.

Sources:

• Kaspa Convenant-centric Hard Fork: Countdown on Kas.live
• Terah X Thread: Upcoming Milestones and Covenant-centric Hard Fork
• Kaspa Research: A formal backbone model for the vProg computation $DAG