Kaspa Development Milestones Revealed – 2025 – 2026

Raw Thoughts Re Kaspa’s Next Big Upgrade(s)

Original Post Link
You don’t end on a crescendo, and it is no secret that several anticipated upgrades are waiting on the sidelines for Kaspa. Primarily, the Dagknight (DK) protocol and the ZK L1<>L2 bridge. These two major endeavors may look independent, but I see strong merit in bundling them into a single hardfork (reasons below). I also argue this bundled effort is the right window to incorporate the foundational L1 changes needed to support ongoing research into MEV‑resistance and oracle‑voting.

A word on deferring DK to this point. I acknowledge that per past statements we expected to be post‑DK by now. Context for the long delay: (1) after the Rust rewrite, moving from 1→10 bps (blocks/sec) was too natural a follow‑up to ignore, and I dove into ~1‑year of work there. (2) Strong community push for smart contracts; in the absence of formal committees planning the next phase we reasoned that prioritizing smart contract enablement would let a builder community form around the Kaspa app layer, and that unleashing this potential (and its ripple effects) would let us refocus on L1 perfection without bottlenecking ecosystem growth.

This post provides a bird’s‑eye overview of active + upcoming Kaspa R&D efforts and sketches their relation graph.

DK: Dagknight is a ’22 ordering‑protocol research paper by myself & @hashdag; it evolves GHOSTDAG (GD). A (mostly written) follow‑up post will deep‑dive DK across: – practical benefits / applications of its abstract “no a priori delay bound” property – a breakdown into four main components → raw development phases – broader system / consensus implications – applied research for efficient incremental algorithms (notably the cascade voting procedure) – protocol (and paper) relaxations / simplifications – “resistance to Internet chaos”: practical limits + engineering caveats

ZK: In the past year, there has been an ongoing publicly visible effort to establish the landscape of ZK over Kaspa. The results of these efforts can mostly be viewed in Kaspa’s research forum under the L1<>L2 category. Kaspa’s approach is to support based ZK rollups, where “based” means the ZK layers / rollups / dapps fully commit to L1 sequencing—so L1 serves all three roles: sequencing, data availability, settlement. The base mechanisms to support this are largely established. The main area still under heavy research is atomic / synchronous composability (multi‑rollup transactions that land atomically). Explaining the vision and mapping current research there deserves its own dedicated post.

Why bundle DK + ZK: Their technical complexities barely overlap, so development can proceed in parallel and merge cleanly. That’s the engineering case. There is also a safety case: we (strongly) conjecture DK yields faster practical convergence of total DAG ordering. Under normal operation the delta is likely inconsequential; under powerful attack attempts DK’s convergence could be much faster—possibly by orders of magnitude. Faster convergence of total order is especially valuable for smart‑contract systems that are highly order‑sensitive. This further strengthens the case for linking the two upgrades.

Additional elements that should ship with them are support for reverse MEV auctions and oracle voting mechanisms (two of @hashdag’s ongoing research efforts with @yaish_aviv and @elimmea respectively; see his recent Sydney/HK talks), seizing the opportunity to address some of DeFi’s hardest problems using Kaspa’s unique structure. Once full smart contracts are live we will inevitably inherit the MEV + oracle weak spots seen elsewhere. By making a few minimal, high‑leverage consensus changes now, we can “apply the remedy before the blow”. Engineering cost here is negligible relative to DK + ZK while ecosystem upside is large. Here is how we can approach each:

MEV. Proposed approach: reverse auctions in which miners offer kickbacks to users for transaction‑ordering (or bundle) rights. Kaspa’s parallel 10 bps DAG already produces intra‑round competition; formalizing a kickback path captures that value for users instead of private orderflow brokers. L1 requirements are small: add a canonical kickback route and a deterministic auction‑ordering rule in consensus (how to rank conflicting bids; details are still open afaik). Game‑theoretic refinements can follow post‑fork, but a base path should exist in my opinion.

Oracles. The strategy for oracles is to leverage Kaspa’s high bps to enable a robust, real-time attestation network, with data aggregated from numerous miners each round. From an L1 perspective, the main consideration is whether to tie this system to PoW for greater security/sybil resistance. The practical step would be to add miner voting mechanics at the consensus level. This is a low-cost, preparatory change that provides significant future flexibility for L2 oracle designs.

Overall I expect dk/zk branches to begin landing soon in rk’s main repository. Looking forward to this turning into a beautiful decentralized open source coding voyage

Indepth interview With Michael Sutton (July-2025)

Kaspa Core R&D Milestones Broken down into Project Summaries, Problems Solved & User Benefits

Based strictly on Michael Sutton’s July 2025 X post, this document breaks down the four primary R&D upgradesthat are being considered for bundling into Kaspa’s next hardfork. Each section includes: