Updated: 7/28/2026

GHOSTDAG

How PHANTOM GHOSTDAG orders Kaspa's blockDAG - block coloring, blue score and blue work, chain blocks, the VSPC, and the virtual block.

The BlockDAG left a problem open: parallel blocks have no inherent order, and conflicting transactions need one. PHANTOM GHOSTDAG (paper) is the rule that supplies it - Kaspa’s consensus protocol. It colors blocks by connectivity, builds a backbone chain through the DAG, and uses that backbone to order every block and transaction.

Block coloring

GHOSTDAG classifies all structurally valid, PoW-valid blocks as blue or red. Color generally indicates how well connected a block is in the DAG. A block’s color then dictates its role in consensus, security, and block rewards.

Blue blocks are well-connected blocks, likely mined by honest nodes - the shape honest blocks naturally take, since honest miners point at everything they see. A block is blue if the number of blue blocks in its anticone is within the k parameter bound. Blue blocks count toward blue score and blue work, and the block’s miner is paid.

Red blocks are poorly connected blocks. A block is red if the number of blue blocks in its anticone exceeds k. Red blocks are valid (they meet PoW requirements) and are merged into the DAG, but consensus penalizes their creation: rewards go to the miner of the merging blue block, or in some cases are not paid at all.

The intuition: an attacker mining in secret cannot reference the honest blocks being published in the meantime, so secret blocks end up badly connected - red - and lose consensus weight.

The k parameter and k-clusters

A k-cluster is a subset of the DAG in which no block has an anticone larger than k within that subset - a set of blocks where nearly every pair has a clear ordering relationship. The k parameter bounds the anticone size allowed for inclusion. The blue set is the set of blue blocks in the maximum k-cluster: the largest well-connected subset of honest blocks in the DAG.

Blue score & blue work

Blue score is the number of blue blocks in a block’s past, calculated as the selected parent’s blue score plus the number of blue blocks in the block’s mergeset. Stored in the header, it can be thought of as the weight of a block’s history within the honest portion of the DAG. It feeds several mechanisms, including confirmation counting and DAA score.

Blue work is the cumulative proof-of-work (sum of difficulty values) of all blue blocks in a block’s past; red blocks are excluded. Tip selection and parent selection are based on blue work.

Reference: Blue Score & Blue Work (KaspaCom)

Selected parent

Blocks are mined referencing all known DAG tips, so a block often has multiple parents. The parent with the highest blue work is chosen as the selected parent.

Chain blocks and the VSPC

Chain blocks are a dynamically chosen subset of blocks forming a backbone through the DAG - formally the Virtual Selected Parent Chain (VSPC). Each chain block merges a set of other blocks into the backbone: its mergeset, the blocks in its past but not in its selected parent’s past. Chain-block status is dynamic, so the VSPC is too.

The VSPC plays the primary role in block and transaction ordering. Walk the backbone, merging as you go, and every block - and therefore every transaction - gets one agreed position. A DAG plus GHOSTDAG behaves like a chain that never wastes a block.

Technically, chain blocks merge blocks (not transactions); transactions inherit their containing block’s acceptance status. A transaction’s accepting block is the chain block that merged it into the VSPC - see Confirmations & Finality.

Virtual, sink, selected tip

The virtual block is a conceptual, non-existing block that points to all DAG tips known by the local node as its parents - an un-mined “next block”. Virtual is not a full block template (it holds no transactions), but its GHOSTDAG data is inherited by the block template given to miners.

The sink is the selected parent of virtual - effectively the same block as the selected tip, the last block of the VSPC.

GHOSTDAG’s k parameter is fixed in advance from an assumed worst-case network latency. DAGKnight is the proposed parameterless successor.

Further reading

  • PHANTOM GHOSTDAG research paper (link).
  • Kaspa 101 - Part 1 by Michael Sutton (link).
  • Kaspa — What are We Actually Doing Here? by Shai Wyborski (link).
  • How Increasing the Throughput Harms Bitcoin’s Security by Ori Newman (link).
  • Scaling Bitcoin with BlockDAG by Ori Newman (link).
  • Kaspa GHOSTDAG 101 video on YouTube (link).
  • Understanding GHOSTDAG Series by Shai on KasMedia. While outdated, still contains some excellent information.