GHOSTDAG Mechanics

What this page explains#

This page explains selected parent, mergesets, blue/red classification, blue score, and blue work as connected mechanics. This page sits in Consensus, GHOSTDAG, And blockDAG. It gives the topic a plain-language handle first, then shows the working idea, the mechanism, the source trail, and any limits that still matter. This category explains how Kaspa reasons about many blocks without pretending the graph itself is enough. The flow moves from graph shape, to GHOSTDAG classification and ordering, to virtual state and accepted transaction evidence.

The writing follows a simple Kaspa documentation pattern: answer the practical question first, then link outward for details. The closest public sources for this page are RK-GHOSTDAG, RK-GHOSTDAG-ORDERING, RK-GHOSTDAG-MERGESET, RK-HEADER-MODEL, PAPER-GHOSTDAG. Local notes can help choose what to explain, but public-facing references resolve to upstream websites, repositories, papers, release pages, or docs.

How to think about it#

The practical model starts by naming the layer that owns the topic: wallet use, node operation, consensus, transaction validation, Toccata script behavior, tooling, or research. From there, the page shows which public source can support the explanation and where the explanation becomes incomplete.

For GHOSTDAG Mechanics, the model is built around these anchors: selected parent is chosen among parent candidates using source-defined ordering and tie-break behavior; mergesets describe what a block brings in besides its selected parent path; blue/red classification is a consensus classification, not a moral label; blue score and blue work communicate progress under the consensus view and are checked against header fields; small diagrams are conceptual and omit the full Rust validation pipeline. This model is useful, but it does not encode every constant, branch, error type, or edge case. Those details belong in the source path and the source notes.

How it works#

1. selected parent is chosen among parent candidates using source-defined ordering and tie-break behavior. In Kaspa's blockDAG, a block can carry several parents, but many downstream calculations still need one selected-parent path as an anchor. That anchor does not erase the other parents. It gives the node a route for interpreting mergesets, accumulated work context, and later virtual-state consequences. A review therefore asks which parent candidates existed, which one became selected, and what the remaining parent relationships contributed.

2. mergesets describe what a block brings in besides its selected parent path. A mergeset is the part of the DAG brought into view by a block beyond the selected-parent path. It matters because Kaspa is not merely following a single chain tip; it is deciding how parallel work is incorporated. When explaining mergesets, keep the graph relationship, ordering consequence, and transaction consequence separate so app pages do not treat every visible block as immediate accepted state.

3. blue/red classification is a consensus classification, not a moral label. Blue/red vocabulary belongs to consensus classification, not user reputation or transaction success. Blue score and blue work are progress signals inside the consensus view. They are useful for understanding chain progress and ordering context, but wallet, indexer, and app pages still need accepted-transaction or UTXO evidence before claiming a spend has taken effect.

4. blue score and blue work communicate progress under the consensus view and are checked against header fields. Blue/red vocabulary belongs to consensus classification, not user reputation or transaction success. Blue score and blue work are progress signals inside the consensus view. They are useful for understanding chain progress and ordering context, but wallet, indexer, and app pages still need accepted-transaction or UTXO evidence before claiming a spend has taken effect.

5. small diagrams are conceptual and omit the full Rust validation pipeline. A protocol diagram is a teaching scaffold, not a substitute for validation logic. For GHOSTDAG pages, the diagram can show parents, selected parent, mergeset, blue/red classification, and a later virtual-state consequence, but it omits constants, traversal order, storage access, error handling, and test coverage. The page should say exactly what the diagram leaves out before readers reuse it.

This mechanism section separates graph structure, GHOSTDAG classification, selected-parent context, ordering consequences, and virtual-state effects. A diagram or summary can orient the reader, but implementation paths and KIPs carry high-risk claims.

How to check it#

When using this page for consensus explanation, identify whether the claim is about graph shape, GHOSTDAG classification, selected-parent context, virtual-state processing, or transaction consequences. Diagrams are orientation aids; source paths and KIPs carry the high-risk behavior claims.

Related Pages#

• phantom-and-ghostdag
• consensus-blockdag-ghostdag
• selected-parent-and-mergesets