Kaspa’s Upcoming Covenant-Centric Hardfork: What We Know

Desk of Contents

What Is Kaspa’s Covenant-Centric Hardfork?What Is the Timeline for the Might 5, 2026 Hardfork?How Do Native Belongings and Covenants Work on Kaspa?What Is the Computational $DAG (CDAG)?What Are vProgs and How Do They Differ From Good Contracts?What Function Does Zero-Data (ZK) Play?How Does Sparkle Relate to vProgs?Will the Hardfork Have an effect on Safety, MEV, or Node Necessities?What Does SilverScript Add?ConclusionSources:Ceaselessly Requested Questions

What Is Kaspa’s Covenant-Centric Hardfork?

In accordance with Terah’s thread,Kaspa is getting ready a covenant-centric hardfork scheduled for mainnet activation on Might 5, 2026. The improve expands Layer 1 (L1) programmability by introducing native belongings and prolonged covenant performance. It additionally lays the groundwork for verifiable packages (vProgs) and zero-knowledge (ZK) integrations.

Kaspa operates as a proof-of-work blockchain utilizing a blockDAG structure. Its Crescendo improve in Might 2025 elevated throughput to 10 blocks per second (BPS). Thus, the upcoming hardfork builds on that basis with out altering node necessities or consensus fundamentals.

Core builders describe the discharge as a scoped improve. It focuses on enabling native token issuance, programmable spending guidelines, and ZK verification on L1.

What Is the Timeline for the Might 5, 2026 Hardfork?

Kaspa Convenant-centric Exhausting Fork Countdown as of the time of writing | Kas.stay

A number of milestones precede the mainnet activation, based on Terah’s thread:

Testnet 12 (TN12) Reset: Scheduled for early February 2026 to help covenant and native asset testing.
Sequencer Dedication KIP: Anticipated round February 12, 2026. This proposal introduces miner payload commitments to strengthen real-time decentralization.
SilverScript Launch: A high-level programming language for writing packages on Kaspa. Developed by Ori Newman and contributors, it simplifies covenant growth.
Mainnet Hardfork: Might 5, 2026.

Publish-hardfork upgrades embrace DAGKnight, concentrating on adaptive consensus and throughput above 100 BPS, and the total deployment of vProgs.

How Do Native Belongings and Covenants Work on Kaspa?

Native Belongings on Layer 1

The hardfork introduces native belongings, together with help for KRC20 tokens. These belongings exist instantly on L1 and might be transferred atomically.

Atomic transfers apply to:

Common inline covenants
ZK and non-ZK covenant executions
KRC20 token transfers

Inline covenants generate rapid proofs throughout the pockets. There isn’t any decoupling between transaction information and state transition. This design helps atomicity and deterministic execution.

Prolonged Covenants (Covenants++)

Kaspa’s covenant system is impressed by Bitcoin analysis on programmable UTXO spending circumstances. Covenants++ extends this technique to permit extra expressive transaction guidelines.

Use instances embrace:

Vault-style safety controls
Escrow mechanisms
Conditional transfers
Structured token logic

The system maintains a UTXO mannequin fairly than full account-based good contracts.

What Is the Computational $DAG (CDAG)?

The hardfork introduces the Computational $DAG (CDAG). CDAG information all learn and write declarations made by packages.

This construction:

Tracks useful resource utilization
Regulates dependencies between packages
Enforces gasoline commitments

The design is corresponding to execution fashions in blockchains equivalent to Solana and Sui, however applied in full kind inside Kaspa’s blockDAG setting.

CDAG performs a central function in enabling vProgs sovereignty.

What Are vProgs and How Do They Differ From Good Contracts?

vProgs are sovereign packages that execute outdoors L1 whereas settling outcomes on L1 by proofs.

Key properties:

Sovereign execution: Every vProg defines its personal throughput and dependency guidelines.
Fuel-based dependency management: A vProg can’t learn one other vProg’s state until it pays gasoline for the useful resource consumption.
Non-atomic transfers: vProgs usually are not clear to L1 in the identical means as native belongings. Transfers are asynchronous and non-atomic.
Wrapped $KAS requirement: Any non-inline covenant should use wrapped $KAS by a canonical bridge. Native L1 $KAS can’t be used instantly.

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

Who Ought to Construct vProgs?

In accordance with group discussions, most common utility builders could not want vProgs.

Nevertheless, vProgs could attraction to:

Appchain architects
Groups evaluating rollup-style programs
Tasks constructing AI brokers with a big on-chain state
System designers evaluating L1 contracts, L2 rollups, and hybrid fashions

vProgs mix unified L1 sequencing with externalized state and computation.

What Function Does Zero-Data (ZK) Play?

The hardfork integrates ZK verification on L1, extending earlier proposals equivalent to KIP-16.

Supported capabilities embrace:

Groth16 proof verification
Trustless bridges to L2 programs
Potential privacy-oriented purposes

Preliminary purposes are anticipated to run in-line, with wallets producing proofs instantly. Even covenant-based ZK implementations developed by contributors equivalent to Hans and Maxim are anticipated to run on commodity {hardware}. No specialised prover infrastructure is required for early deployments.

A regular laptop computer can generate proofs underneath the present assumptions.

Privateness-focused packages are technically doable after the hardfork. Nevertheless, privateness isn’t listed as a main focus of the roadmap.

How Does Sparkle Relate to vProgs?

Sparkle is an structure proposed by Anton for combining computational DAGs and ZK proofs. Whereas each Sparkle and vProgs use CDAG and ZK elements, they tackle totally different design questions.

The defining function of vProgs is dependency regulation. Every program controls its throughput and avoids arbitrary exterior dependencies. This mannequin helps composability whereas preserving isolation.

Will the Hardfork Have an effect on Safety, MEV, or Node Necessities?

Safety Funds: No direct impression is predicted within the quick time period. Enhancements rely upon actual product adoption fairly than infrastructure adjustments.
Node Necessities: No adjustments.
MEV Kickback Auctions: Thought of untimely given the present stage of ecosystem growth.
PoW Grinding for STARKs: Discussions reference historic conduct on early Ethereum, the place addresses with main zeros lowered gasoline prices, which in flip led to proof-of-work grinding markets. The point out was contextual fairly than a present function.

What Does SilverScript Add?

SilverScript is a high-level language designed for Kaspa packages. It goals to simplify covenant and program growth.

Its design targets embrace:

Readable syntax
Accessibility for brand spanking new builders
Compatibility with automated tooling

SilverScript is predicted to decrease the barrier for writing covenant-based purposes as soon as native belongings go stay.

Conclusion

Kaspa’s covenant-centric hardfork expands Layer 1 performance by native belongings, prolonged covenants, and ZK verification. It introduces CDAG for structured dependency monitoring and lays the inspiration for sovereign vProgs. The improve preserves present node necessities and proof-of-work consensus whereas enabling programmable token issuance and atomic transfers.

The Might 5, 2026, activation marks a technical step in Kaspa’s roadmap. It provides structured programmability on the protocol degree and prepares the community for additional upgrades, together with DAGKnight and full vProgs deployment.