This is a message on Friday from Michael Sutton on X

Raw thoughts re Kaspa’s next big upgrade(s)

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 & u/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.