In brief
A direct explanation of Kaspa and the concepts that make its guide different from a linear-chain-only introduction.
First Contact#
Kaspa is a proof of work cryptocurrency network. The unusual part is how its consensus learning path handles blocks that appear close together. Instead of explaining the network only as a single chain of blocks, this guide introduces a blockDAG, then explains how GHOSTDAG gives that graph an ordering path and how virtual state turns ordered consequences into accepted transaction and UTXO evidence.
Working Model#
In a linear-chain mental model, competing blocks are easy to describe as one winner and one discarded branch. That model is too small for Kaspa. A better first model is: miners still perform proof of work, nodes still validate blocks and transactions, but the consensus layer keeps relationships among multiple blocks visible before ordering consequences are processed.
This does not mean every observed transaction is final just because a wallet or explorer saw it. The evidence path still matters: transaction construction, RPC submission, mempool admission, block-template selection, mined block, virtual selected-parent-chain processing, acceptance data, UTXO diff, and indexer/API observation are separate stages.
Mechanics#
Kaspa's core guide can be read as four connected mechanics.
The first mechanic is proof of work: miners search for valid blocks under network rules. The second is blockDAG structure: blocks can reference parent relationships in a graph rather than forcing a single immediate branch view. The third is GHOSTDAG and virtual processing: consensus code orders consequences and derives accepted data. The fourth is UTXO state: spendable coins are represented as outputs that later transactions consume.
Implementation Or Source Path#
For orientation, start with the Kaspa documentation home and Kaspa overview. For research background, read the PHANTOM/GHOSTDAG paper. For current implementation, follow Rusty Kaspa source paths for GHOSTDAG and virtual processing.
Expanded Concept Path#
This page should leave the reader with a sequence, not just a definition. Kaspa starts from proof of work, so miners still search for valid blocks under network rules. The guide then introduces blockDAG because the educational problem is not only "who mined a block"; it is also "how does the network reason when multiple nearby blocks exist?" GHOSTDAG enters as the consensus topic that works over that graph. Virtual state enters when the guide needs to explain accepted consequences. UTXO enters when the guide explains where spendable value lives and how transactions change that state.
The practical result is a layered map. Wallets construct and sign transactions. Nodes validate, relay, and expose interfaces. Mempools handle candidate transactions under policy. Miners work on block templates. Consensus processing handles blockDAG and virtual-state consequences. Indexers and explorers expose observations that must be understood as observations.
The page is not trying to prove every branch of consensus. It gives the path into the proof: Kaspa documentation orientation for the public explanation, the PHANTOM/GHOSTDAG paper for research background, and Rusty Kaspa implementation/source paths for current behavior where the claim is technical.
