Kaspa client developer coderofstuff opened a proposal on 4 September that would give DAGKnight a dedicated testing network, with that consensus design turned on for the new testnet and left off on mainnet. The change is still in review and does not launch a public testnet. It would let developers test the design on a separate history without altering mainnet payments (open DAGKnight testnet proposal).
Adapting confirmation to network conditions
Sending value on a proof-of-work network is not finished the moment a block appears. Recipients wait until later work has piled on, because that work makes it costly to rewrite the payment. How long that wait feels depends on more than how quickly blocks are found.
Many permissionless protocols assume, in advance, a worst-case bound on how slowly messages travel between nodes, then hard-code a matching parameter. Confirmation then follows that pessimistic bound even when the network is healthy and messages move quickly (DAGKnight protocol paper).
DAGKnight, designed by Yonatan Sompolinsky and Michael Sutton, tries to drop that in-protocol latency bound so confirmation can respond to observed network conditions. When traffic is moving well, confidence can arrive sooner than a fixed worst-case setting would allow, while still targeting security against a large share of mining power.
Clients still have to choose a conservative assumption about recent network delay. The design is not assumption-free, and it does not guarantee instant finality. Faster confirmation is an intended property of the protocol, not a measured result of this proposal.
A dedicated test network
The proposal adds a distinct starting block for testnet 13. That genesis is its own identity, labeled for DAGKnight, not a copy or migration of mainnet coins (testnet-13 genesis).
In the proposed settings, DAGKnight is on for that network and off for mainnet, the existing testnet-10, and other default networks (network activation settings). A separate test history keeps the experiment away from live payments and away from the public testnet already used for other work. The first iteration does not list DNS seed nodes that computers normally use to find peers.
Activation is treated as an explicit per-network rule. Previously, whether DAGKnight ran could depend on whether optional processing pieces were present. The proposal checks a network setting as headers are processed, so the same software can keep the design off on mainnet while turning it on for the dedicated testnet.
Still preparation
This proposal does not announce a launch date, and it does not show a public testnet already running. Automated checks on the change completed, including tests and a Linux release build. That is evidence the checked code compiled and passed those jobs.
The author notes that further wiring may still be needed beyond this change. A newly added DAGKnight integration test is still a placeholder (placeholder DAGKnight integration test). Some remaining activation integration still has to be finished (remaining activation work). Mainnet remains off in these proposed settings.
