DAGKnight is a proposed proof-of-work consensus protocol that improves on GHOSTDAG by removing a fixed assumption about network delay. Its goal is to let confirmations respond to the network’s actual conditions, rather than a delay limit chosen in advance. [1][2] It was co-authored by Yonatan Sompolinsky and Michael Sutton. [2]
What GHOSTDAG does
A blockchain must agree on an order for transactions, even when miners produce blocks at nearly the same time. Sompolinsky explains the progression this way: Bitcoin selects one chain, while GHOSTDAG works with a DAG, a graph of blocks that can include parallel branches. GHOSTDAG orders that graph using a well-connected group of blocks called a k-cluster. [3][4]
The parameter k controls how much disconnection that group allows. Blocks can be disconnected simply because miners created them before learning about each other’s work. GHOSTDAG chooses k in advance to accommodate an assumed upper limit on network delay. [4][2]
That fixed assumption creates two limitations:
- Confirmation speed: Against large attackers, confirmations cannot safely proceed faster than the delay assumption allows, even when the network is operating much faster. [5]
- Resilience: If block propagation becomes slower than the assumed limit, the protocol’s security guarantee no longer holds under that assumption. [2]
What DAGKnight changes
Instead of starting with a fixed k, DAGKnight searches for the smallest k for which the largest qualifying cluster contains a majority of the graph. In Sompolinsky’s explanation, GHOSTDAG maximizes a cluster for a given k; DAGKnight first finds the minimum k that allows that cluster to capture a majority. [4]
This lets the protocol adapt to the structure of arriving blocks rather than rely on developers having chosen the right delay parameter beforehand. Contributor coderofstuff explained on 1 March 2026 that nodes calculate k from their view of the current tips, the newest ends of the block graph, taking account of the maximum delay an adversary can cause. [6]
The intended benefit is faster safe confirmations when conditions permit, with resilience when communication deteriorates. In his essay introducing the work, Sompolinsky described DAGKnight as responsive to the network’s actual adversarial latency while resilient to attackers controlling 49% of the mining power. That is a protocol security claim under its assumptions, not a promise that every transaction becomes safe immediately. [1]
“Actual delay” does not mean today’s fastest response
An important qualification is that DAGKnight does not make it safe to set confirmation timing from whatever smooth network behaviour a client happens to observe. An attacker could cooperate temporarily and disrupt communication later. [7]
Sompolinsky distinguishes observed delay from actual worst-case delay under an attack. In his explanation, clients still need a defensible assessment of that worst case when deciding how long to wait. The consensus protocol’s adaptive k and a client’s confirmation policy are related, but they are not the same thing. [7]
What it does not mean
DAGKnight does not inherently require more blocks per second. In his interview published on 8 August 2026, Sompolinsky explicitly separated block rate from the consensus change: GHOSTDAG could run at a higher rate, and DAGKnight could run at the same rate as its predecessor. The central improvement concerns delay assumptions and confirmation responsiveness. [8]
A lesser-known point from his “Kaspa where to (Part II)” essay: increasing block production indefinitely need not shorten confirmations. More blocks and larger headers can themselves increase communication delay. [1]
Development and further reading
DAGKnight is not live on mainnet, and no activation date has been announced. The work happens on a separate dagknight branch of the Rusty Kaspa code. On 28 February 2026, coderofstuff reported testing an early version on a small private development network and described separate devnet, testnet and mainnet-candidate stages [6]. On 6 September 2026 the branch gained the settings for a dedicated DAGKnight test network, testnet 13, with DAGKnight switched off on mainnet [9]; launching that public test network is still an open task [10].
For the original motivation, read Sompolinsky’s essay above. [1] For his spoken explanation of the central algorithm, watch his Bitcoin Takeover interview from 3:46:19. [4] His explanation from 6:33:20 covers the crucial worst-case-delay qualification. [7]