Kaspa’s upcoming covenant-centric hard fork: What we know

What is Kaspa’s covenant-centric hard fork?

According to Terra’s thread,when We are preparing for the planned covenant-centered hard fork. Mainnet activation Upgrade expands on May 5, 2026 Layer 1 (L1) Programmability through the introduction of native assets and expanded convention functionality. It is also Verifiable programs (vProgs) Zero knowledge (ZK) integration.

Kaspa operates as a proof-of-work blockchain using the blockDAG architecture. the crescendo upgrade In May 2025, throughput increased to 10 blocks per second (BPS). Therefore, future hard forks will build on that foundation without changing the node requirements or consensus fundamentals.

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

What is the timeline for the hard fork on May 5, 2026?

Kaspa Convenant-centered hard fork countdown (as of writing) | Kas Live

According to Terah’s thread, several milestones are planned prior to mainnet activation.

• Testnet 12 (TN12) reset: Scheduled for early February 2026 to support testing of covenant and native assets.
• Sequencer commitment KIP: Expected around February 12, 2026. This proposal introduces a miner payload commitment to enhance real-time decentralization.
• SilverScript release: A high-level programming language for writing programs with Kaspa. Developed by Ori Newman and his contributors to simplify covenant development.
• Mainnet hard fork: May 5, 2026.

Post-hard fork upgrades include DAGKnight, which targets adaptive consensus and throughput above 100 BPS, and a complete deployment of vProgs.

How do native assets and covenants work in Kaspa?

Layer 1 native assets

The hard fork introduces native assets with support for: KRC20 token. These assets exist directly on L1 and can be transferred atomically.

Atomic transfers apply to:

• Normal inline convention
• Enforcement of ZK and Non-ZK Terms
• KRC20 token transfer

Inline terms generate instant proof within your wallet. There is no separation between transaction data and state transitions. This design supports atomicity and deterministic execution.

Extended Terms (Conventions++)

Kaspa’s terms system is inspired by Bitcoin’s research on programmable UTXO spending terms. Covenants++ extends this system to enable more expressive transaction rules.

Use cases include:

• Vault-style security controls
• escrow mechanism
• conditional transfer
• structured token logic

The system maintains a UTXO model rather than a fully account-based smart contract.

what is calculation $DAY (CDAG)?

Hard forks introduce computing. $DAY (CDAG). CDAG records all read and write declarations made by a program.

This structure is:

• Track resource usage
• Regulate dependencies between programs
• enforce gas contracts

This design is comparable to blockchain execution models such as Solana and Sui, but is fully implemented within Kaspa’s blockDAG environment.

CDAG plays a central role in realizing vProgs sovereignty.

What is a vProg and how is it different from a smart contract?

vProgs are sovereign programs that run outside of L1 while determining results on L1 through proofs.

Main properties:

• Sovereign enforcement: Each vProg defines its own throughput and dependency rules.
• Gas-based dependency control: A vProg cannot read the state of another vProg without paying gas for resource consumption.
• Non-atomic transfer: vProg, like native assets, is not transparent to L1. Transfers are asynchronous and non-atomic.
• wrapped $what Requirements: Non-inline covenants must be wrapped $what Through a regular bridge. Native L1 $what It cannot be used directly.

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

Who should build vProgs?

Based on community discussion, most regular application developers may not need vProgs.

However, vProgs may object in the following cases:

• app chain architect
• Team evaluating rollup style systems
• Project to build AI agents with large-scale on-chain state
• System designers comparing L1 contracts, L2 rollups, and hybrid models

vProgs combines integrated L1 sequences with externalized state and computation.

What role does Zero Knowledge (ZK) play?

The hard fork integrates ZK validation at L1 and extends previous proposals such as: KIP-16.

The supported features are:

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

The initial application is expected to run inline with the wallet generating proofs directly. Even the covenant-based ZK implementations developed by contributors such as Hans and Maxim are expected to run on commodity hardware. No special attestation infrastructure is required for initial deployment.

A standard laptop can generate proofs based on current assumptions.

Privacy-focused programs are technically possible even after a hard fork. However, privacy is not listed as a major focus on the roadmap.

How do Sparkle and vProgs relate?

Sparkle is an architecture proposed by Anton to combine computational DAGs and ZK proofs. Sparkle and vProgs both use CDAG and ZK components, but address different design issues.

A feature of vProgs is dependency regulation. Each program controls throughput and avoids any external dependencies. This model supports composability while maintaining isolation.

Does a hard fork affect security, MEV, or node requirements?

• Security budget: No direct impact is expected in the short term. Improvements depend on actual product adoption, not infrastructure changes.
• Node requirements: No changes.
• MEV Kickback Auction: Considering the current stage of ecosystem development, it is considered premature.
• STARK PoW Grinding: The discussion references the historical behavior of early Ethereum, where addresses with leading zeros reduced gas costs, resulting in the creation of the proof-of-work grind market. This mention was situational, not current functionality.

What does SilverScript add?

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

Its design goals include:

• Easy to read syntax
• Accessibility for new developers
• Compatibility with automatic tools

SilverScript is expected to lower the barrier to creating contract-based applications once native assets are up and running.

conclusion

Kaspa’s covenant-centric hard fork extends layer 1 functionality through native assets, extended covenants, and ZK validation. CDAG is introduced for structured dependency tracking, laying the foundation for sovereign vProgs. This upgrade enables programmable token issuance and atomic transfers while preserving existing node requirements and proof-of-work consensus.

The May 5, 2026 activation marks a technical step in Kaspa’s roadmap. This adds structured programmability at the protocol level and prepares the network for further upgrades such as DAGKnight or full vProgs deployment.

source:

• Hard fork centered around Kaspa Convenant: Kas.live countdown
• terra x thread: Upcoming milestones and covenant-centered hard forks
• case study: A formal backbone model for vProg computation. $DAY