📢 #Dagknight Dev Update @michaelsuttonil has shared a brief update on DAGKnight development: “heavy wip. 6 milestones defined. first 2 are: incremental algos (pseudo code and analysis showing incrementality also under worst-case scenarios) testnet (unlike devnets, this means no security relaxation) both are progressing very well” So six milestones have now been defined. We know the first two. 1. Incremental algorithms Kaspa’s DAG is constantly growing as new blocks arrive. DAGKnight needs to process that new information continuously and efficiently. This milestone focuses on the algorithms, pseudocode and analysis required to show that DAGKnight can operate incrementally, including under worst-case scenarios. Simply put: DAGKnight needs to keep up with a live, continuously changing DAG. The reference to “worst-case scenarios” seems to indicate that the analysis extends beyond normal network operation into more difficult conditions. ⛏️For Miners, 🧑‍💻Makers and 🤖Machines, this is foundational engineering work. DAGKnight needs an implementation that can continuously process an evolving DAG while maintaining the properties established by the protocol. Specific performance characteristics will become clearer as more of the work is published. 2. DAGKnight Testnet The second milestone takes DAGKnight into a distributed testing environment. Michael adds an important detail: “unlike devnets, this means no security relaxation” Devnets provide developers with a flexible environment for building and experimentation. A DAGKnight testnet would operate without relaxing the security requirements DAGKnight is designed around. Simply put: run DAGKnight across a real distributed network while keeping its intended security assumptions intact. For Makers, this provides an environment for implementation, experimentation and testing. For Miners and Machines, it provides an opportunity to observe DAGKnight operating across a distributed network under realistic security constraints. For 🏪Merchants and 🏢Movers, the longer-term relevance comes from DAGKnight’s core objective: confirmation confidence that adapts to observed network conditions. The practical implications for applications and confirmation policies will become clearer through implementation and testing. 🧍‍♂️🧍‍♀️For everyday Kaspa users, nothing changes yet. These are development milestones. They show DAGKnight progressing from consensus research toward working network software. Milestone 1: Make DAGKnight work incrementally as the DAG grows, including under worst-case conditions. Milestone 2: Put DAGKnight on a testnet without relaxing its intended security requirements. So,2 of 6milestones defined, with both reportedly progressing very well. Kaspa devs: help us unpack this further. What exactly falls under “worst-case” incrementality? What will distinguish the DAGKnight testnet technically? What will developers be able to test, measure or build once these milestones are reached? And we’d love any insight into what might be behind milestones 3 through 6.