TL;DR: 

• Kaspa targets two hard forks in 2026: Covenants++ is planned for early May, followed by the DAGKNIGHT hard fork with increased blocks-per-second targeted for the end of Q3 2026, with additional performance milestones discussed beyond that window.

• Kaspa’s North Star framed as Real-Time Decentralization: Yonatan Sompolinsky described Kaspa’s core objective as achieving Proof-of-Work security properties in real time, combining fast confirmations under healthy conditions with strong safety during network disruption.

• Programmability primitives mature on Testnet 12: Michael Sutton outlined how covenants, lineage, and zero-knowledge verification opcodes now enable persistent state machines on Kaspa while preserving its UTXO locality and native security guarantees.

• Based zk rollups with canonical KAS bridging demonstrated: A proof-of-concept implementation on TN12 showed native entry and exit between Kaspa’s L1 and a zk rollup without external custodians, alongside continued progress on vProgs execution infrastructure and DAGKNIGHT consensus research.

• vProgs execution framework advances toward production: Hans Moog shared multiple PRs introducing unified shared-state handling, execution node infrastructure, and a modular VM runner, with ongoing work focused on finalizing settlement back to Kaspa’s L1 and reliable state synchronization.

Kaspa Targets Two Hard Forks in 2026

Yonatan Sompolinsky responded to community questions regarding Kaspa’s 2026 hard fork timeline, clarifying that two separate upgrades are currently targeted for next year. In earlier commentary, Sompolinsky referenced performance milestones including “40–25 milliseconds targeted for the DK HF,” with benchmarking pending, alongside hopes that “vprogs v2 is ready by then,” and a “target date end of Q3 ’26.” He also noted that achieving 10-millisecond block intervals would likely require additional DAG-level adjustments and further node optimizations, describing this milestone as part of a 2027 hard fork objective.

After a community member asked whether differing dates implied multiple hard forks, Sompolinsky confirmed: “aiming for two HFs in 2026, cov++ beginning of May, DK+increased BPS end of Q3, God willing. Both are aggressive timelines, but realistic with the newly expanded devforce?”

Under this outline, the Covenants++ upgrade is targeted for early May 2026, while the DagKnight hard fork and increased blocks-per-second are aimed for the end of Q3 2026, with longer-term performance and consensus refinements projected beyond that timeframe.

Yonaton Frames Kaspa’s North Star as Real-Time Decentralization

Yonatan Sompolinsky reflected on what he described as years of “double-speaking” about Kaspa, emphasizing transaction speed when addressing mainstream audiences while shifting to security properties when speaking with crypto-informed listeners, including DAGKNIGHT’s resilience under network splits. He argued this is not a contradiction, but two expressions of the same underlying design principle.

Dr. Sompolinsky framed Kaspa’s direction around partial synchrony, meaning the network does not rely on fixed timing assumptions. As he put it, this allows the system to be “parameterless hence fast in peace times” while becoming “slow-yet-secure when the network/internet breaks.” In this view, Kaspa’s performance adapts to real-world conditions, remaining fast when connectivity is strong while preserving security when conditions degrade. He described the endpoint of this thinking as Real-Time Decentralization (RTD), defined as the ability to sample the consensus network in real time with very high granularity, and achieve all the good properties that proof-of-work gives us just in real-time.” Sompolinsky argued that real-time decentralization is unique to Proof-of-Work systems, stemming from PoW’s ability to continuously sample honest majority participation in real time rather than pre-selecting validators.

Throughout the post, Sompolinsky used what he explicitly called “absurds” to describe paradoxes that, while unconventional by typical crypto standards, define Kaspa’s identity and development philosophy. In his own words:

1. “Absurd #1: Kas funded like fair-launch, innovates like premined.”

2. “Absurd #2: Kaspa can only succeed if someone takes responsibility for something no one owns.”

3. “Absurd #3: Kaspa is impatient, but its development is research-disciplined.”

4. “Absurd #4: Kaspa sells speed to normies but wargrade money to cypherpunks.”

He also pointed to a final, lingering absurdity: a project that reached top-20 all-time highs while remaining largely unknown, concluding with a paraphrase of Wisława Szymborska: “I prefer the absurdity of open source with Kaspa to the absurdity of open source without it.”

Beyond consensus design, Sompolinsky addressed the oracle dilemma, arguing that as blockchains increasingly interact with real-world events, security depends not only on cryptography but on how quickly and reliably the network can establish a shared view of reality. Rather than introducing new trust assumptions, his proposal leans on Proof-of-Work’s honest-majority model, suggesting that miners can voluntarily attest to external events while leaving the base ordering protocol fully agnostic.

To illustrate what real-time decentralization could enable at the application layer, Sompolinsky outlined a high-level vision for an event-driven execution stack. In this model, programs can react continuously to public variables, real-world events are resolved through miner majority votes finalized in real time, and on-chain automation propagates those updates through shared state without manual triggering. Execution ordering is determined through advance priority auctions, allowing time-sensitive logic to activate deterministically as conditions change.

Returning to the central metaphor, Sompolinsky concluded that Kaspa’s North Star is best understood as a three-part system: optimistic speed under healthy conditions, pessimistic safety under adverse conditions, and first-principles research that defines the justified limits of both. Together, these elements form what he repeatedly described as Kaspa’s core instinct: disciplined impatience.

Michael Sutton Summarizes Smart Contracts on Kaspa

Michael Sutton published a technical overview describing how Kaspa has evolved from simple rules about who can spend coins into a platform capable of supporting more complex financial systems, without abandoning the core design principles of its UTXO model. He framed the work as system research, emphasizing that conceptual clarity has emerged through implementation rather than from a single top-down design, and noted that progress has been incremental rather than monolithic. All of the primitives discussed are implemented and currently running on Kaspa’s Testnet 12 (TN12).

Sutton summarized the model as a layered progression:

“UTXO scripts constrain spend authorization.

Covenants constrain next outputs.

Lineage authenticates which instance is ‘the real one’.

ZK verifies transitions by succinct proofs, without on-chain execution.”

At a basic level, Sutton explained that a UTXO script defines the rules for spending a specific coin. Those rules apply only to the transaction being made, as scripts can see only the inputs they are spending and are evaluated once at the moment of use. After a coin is spent, its prior rules do not automatically carry forward unless they are explicitly written into the new outputs. The only rule that the Kaspa protocol itself enforces over time is conservation of value, ensuring that KAS cannot be created from nothing and giving the asset its native provenance.

To enable rules that persist beyond a single transaction, Sutton pointed to the transaction introspection opcodes introduced in KIP-10, now active in TN12. These additions allow scripts to examine the transaction they are approving, including the outputs being created, rather than simply authorizing a spend in isolation. As Sutton put it:

“You may spend this input only if you create outputs that satisfy these constraints.”

He described this capability as the conceptual birth of covenants, where:

“Spending becomes conditional on preserving a policy across time.”

In practice, this works by enforcing rules one step at a time. A script constrains the next set of outputs and requires those same constraints to be carried forward, allowing policies to persist across transactions without breaking the UTXO model’s local, one-time evaluation.

To support more general state machines, Sutton pointed to additional capabilities introduced in KIP-17 on TN12 that enable the creation of structured commitments and their reliable verification over time. He then addressed a core challenge for non-KAS assets: unlike KAS, which benefits from a protocol-enforced conservation rule, other assets or covenant-based state do not automatically prove that they are authentic. As he illustrated:

“I can create a UTXO whose script claims ‘I am TokenX with supply 1,000,000.’”

To resolve this, KIP-20, now active on TN12, introduces consensus-tracked covenant IDs that tie a specific state machine to a recognized starting point and a valid history of transitions, allowing wallets and applications to distinguish genuine instances from look-alikes.

Sutton described zero-knowledge verification opcodes introduced in KIP-16 as the next layer in this progression. Rather than requiring all state and validation logic to be revealed and executed on-chain, these opcodes allow Kaspa’s base layer to verify compact proofs that a valid transition occurred. In Sutton’s words:

“L1 enforces correctness without re-executing the full computation in-script.”

He noted that a follow-up discussion will explore zk-based applications, canonical KAS bridging, and techniques that allow multiple ZK systems or vProgs to compose synchronously without waiting on base-layer messaging delays.

Canonical Bridging for Based Zk Rollups Implemented on Kaspa Testnet

Maksim Biriukov announced completion of an initial working implementation of a based zk covenant rollup with canonical KAS bridging built on Testnet 12 capabilities. In practical terms, this describes a system where users submit transactions directly to Kaspa’s base layer, execution happens off-chain using zero-knowledge proofs, and assets can move in and out through a native, verifiable bridge anchored to Kaspa’s L1. Canonical KAS bridging is a native, verifiable mechanism for moving KAS between Kaspa’s L1 and a rollup, with entry and exit enforced by on-chain rules rather than external custodians. The work is scoped as a proof of concept under the Covenants++ hardfork milestone roadmap, but Biriukov stated that “all significant challenges related to canonical bridging have been thoroughly addressed” and described the implementation as “already mature”.

The implementation includes a simplified, account-based execution model focused on three core actions: entry, transfer, and exit. Biriukov noted that the implementation departs from the earlier research design in several practical ways, focusing on stronger security guarantees and simpler asset flows. The system leverages covenant identifiers to prevent forgery, introduces a more direct claim-based mechanism for handling exits, and simplifies how funds move through the system by reducing reliance on centralized state-tracking UTXOs, improving overall manageability.

Kaspa’s founder, Dr. Yonatan Sompolinsky described it as: “very impressive max, the road to monolithic kaspa is in good hands :) “

The implementation builds on Sutton’s earlier January design discussion of canonical bridging as a core component of the L1<>L2 architecture. In that post, Sutton described the bridge as central to enabling based zk rollups on Kaspa, defining “based” systems as those where “all transactions are directly submitted by users to L1, with some of them carrying payload data containing L2 smart-contract calls.”

Under this model, L1 provides transaction ordering, final settlement, and data availability (meaning the transaction data needed for anyone to independently verify execution), while L2 handles execution and proof generation. The canonical bridge governs entry and exit between the layers, ensuring that asset movements and state commitments remain verifiable and protocol-consistent.

With covenant IDs, ZK verification opcodes, and bridging primitives now live on TN12, the proof-of-concept demonstrates an end-to-end implementation of a based zk rollup anchored directly to Kaspa’s L1, rather than a theoretical design specification.

Hans Moog Shares More Pull Requests

Hans Moog announced three new pull requests (PR’s) ready for review in the vProgs repository, marking a broader update to the emerging vProgs execution framework designed to extend programmability on Kaspa’s L1.

1. The first PR introduces SchedulerState, a unifying layer that ensures all parts of the framework interact with shared state in the same way, where “shared state” refers to data that persists across transactions and blocks and is accessed consistently by multiple execution components. Moog noted that the PR also addresses previously identified bugs.

2. The second PR builds on that foundation by introducing a node-framework, which Moog described as a generic platform for constructing execution nodes that ingest data from Kaspa’s L1 and produce state transitions, with eventual support for proof generation tied to vProgs execution.

3. The third PR introduces node-vprogs-cli, a runnable program that follows Kaspa’s L1 and executes transactions using a concrete virtual machine (VM), which defines a consistent execution environment that applies program rules to each transaction. Moog noted that the program is designed with compile-time modularity, allowing developers to swap storage backends and VM implementations at build time with minimal code changes by modifying backend.rs.

Moog noted that parts of the system are still unfinished, including the ability for a node to fully reconstruct past activity it did not observe in real time. He explained that the next phase of work focuses on securely connecting vProgs execution back to Kaspa’s L1, allowing execution results to be finalized on-chain and enabling nodes to reliably sync their state from it. He expects continued iteration between vProgs development and covenant integration as the design moves closer to production readiness.

New Kaspa.com Article on DAGKNIGHT

A new article published on kaspa.com outlines DAGKNIGHT, the next-phase evolution of Kaspa’s BlockDAG consensus that removes hardcoded network-latency assumptions from Proof-of-Work security, allowing the network to adapt to real-world conditions rather than relying on fixed assumptions. The design builds on the PHANTOM consensus paradigm, enabling efficient transaction confirmation under normal conditions while maintaining security during network disruptions.

Instead of relying on fixed assumptions about the network's tolerance for delay, DAGKNIGHT dynamically evaluates conditions as the network operates. In distributed systems, “latency” refers to how long it takes for messages to travel across the network, or the maximum delay the system can experience. By removing hardcoded assumptions about acceptable delay, the design allows transaction confirmations to adapt to real-world network conditions while preserving security under majority-honest hashpower.

By treating network delay as a variable the system observes rather than a fixed assumption, DAGKNIGHT strengthens security across a wider range of real-world conditions while preserving fast confirmations when the network is healthy. The article frames this as a step toward more robust real-time decentralization, aiming to unlock higher throughput and responsiveness without compromising the core security model. DAGKNIGHT further differentiates Kaspa as a Proof-of-Work network designed to scale with real-world network behavior rather than theoretical limits.

The First Kaspa Solana Bridge

The first Kaspa-to-Solana bridge was announced, powered by Dymension. In a post highlighting ecosystem expansion beyond Ethereum connectivity, Dymension wrote, “First Ethereum. Now Solana,” positioning the integration as the first KASPA<>SOLANA bridge.

The launch introduces cross-chain connectivity between Kaspa and Solana, expanding asset mobility beyond prior integrations and signaling continued experimentation around external bridging infrastructure within the Kaspa ecosystem.

As with other externally operated bridges, users should approach the integration with caution. Cross-chain bridges introduce additional trust assumptions, smart contract risk, and operational complexity that sit outside Kaspa’s core consensus and security model.

Alexander Brandenburger to Speak at SIUC Blockchain Event

Alexander Brandenburger announced that he will be speaking at Southern Illinois University Carbondale’s upcoming public “Blockchain & Cryptocurrency Event” on Thursday, April 2, 2026. Additional details about the event are expected to be shared soon.

Brandenburger is a vocal Kaspa enthusiast and the author of Money – The Big Picture, a walk-through of monetary theory that traces the evolution of hard money from Bitcoin and ultimately presents Kaspa as a candidate for next-generation sound money. His work frames Kaspa not as a departure from Bitcoin’s principles, but as a continuation shaped by advances in scalability and real-time settlement.