How does Kaspa's blockDAG get fast blocks without orphans? · Jumpstart Blockchain
How does Kaspa's blockDAG get fast blocks without orphans?
Each Kaspa block references every tip it sees, so parallel blocks are merged, not orphaned. GHOSTDAG colours well-connected blocks blue and orders the DAG, supporting 10 PoW blocks per second since Crescendo.
In Bitcoin, two blocks found at nearly the same time can't both be kept: one wins and the other becomes an orphan (strictly, a stale block), and its work is wasted. Kaspa removes that rule. Each block points to every block its miner knows about that has no children yet, so parallel blocks are merged instead of discarded, and the ledger is a directed acyclic graph (a blockDAG) rather than a chain. The GHOSTDAG protocol then sorts that graph into a single order of transactions. That is what lets Kaspa run at 10 blocks per second on proof of work.
Why fast blocks break a chain
A new block takes time to reach every miner. While it propagates, other miners are still working on the old tip, and if one of them finds a block in that window, the network has two competing blocks at the same height. The share of blocks lost this way rises quickly as the block interval gets close to the propagation delay:
import math
defstale_rate(delay_s: float, interval_s: float) -> float:
# Probability that another block is found during propagationreturn1 - math.exp(-delay_s / interval_s)
for interval in (600, 150, 15, 1, 0.1):
print(f"{interval:>6}s blocks: {stale_rate(2, interval):.1%} stale")
# 600s: 0.3% 150s: 1.3% 15s: 12.5% 1s: 86.5% 0.1s: 100.0%
That's a rough model, but the trend is the point. Stale blocks hurt a chain in two ways: honest work is wasted, which lowers the hashrate an attacker has to beat, and large, well-connected miners hear about their own blocks first, so they lose fewer blocks and gain an edge. Bitcoin's 10-minute interval keeps this small. A chain can't simply run at one block per second.
The blockDAG
In Kaspa, a block header lists multiple parents, all the current tips of the DAG as its miner sees them. A block found in parallel isn't a competitor; the next block references both. Nothing honest is thrown away, and throughput is limited by bandwidth and validation rather than by the race.
That creates a new problem. If two parallel blocks contain conflicting transactions that spend the same coin, which one counts? A DAG needs a total order over all its blocks, and the order must be hard for an attacker to manipulate.
PHANTOM and GHOSTDAG: blue and red blocks
PHANTOM, from Yonatan Sompolinsky's research, starts from one observation: honest miners publish quickly and reference everything they see, so honest blocks are well connected. For any block, its anticone is the set of blocks that are neither in its past nor its future, the blocks created "in parallel" with it. Under normal network conditions, an honest block's anticone is small. An attacker mining a private chain produces blocks whose anticone, relative to the honest DAG, keeps growing.
PHANTOM picks the largest set of blocks in which every block's anticone within the set has at most k members. That set is the blue set; everything else is red. Finding the exact largest set is computationally hard, so Kaspa uses GHOSTDAG, a greedy version:
Each block chooses a selected parent: the parent with the most accumulated blue work.
It inherits that parent's blue set.
It walks the blocks it newly merges (its mergeset) and colours each one blue if adding it keeps every blue block's anticone within k, red otherwise.
Following selected parents back from the tip gives the selected chain, which behaves like Bitcoin's heaviest chain. An attacker's private blocks end up red because they can't be well connected to the honest DAG.
k is a security parameter tied to the block rate and an assumed maximum network delay: the more blocks per second, the more honest blocks are created in parallel, so k has to be larger. It is fixed in the consensus rules and was raised when the block rate went up.
From colours to a transaction order
Ordering works along the selected chain. For each chain block, the blocks in its mergeset are placed after everything in its selected parent's order, in a deterministic topological order that every node computes identically. Transactions are then processed in that order: the first spend of a coin is accepted, and a later conflicting spend is rejected.
Red blocks are not deleted. Their non-conflicting transactions are still accepted; red blocks just don't add to the blue work that decides the selected chain, and their miners don't earn the block reward. Red colouring demotes a block's influence rather than discarding its contents, which is the practical meaning of "no orphans".
Crescendo: 10 blocks per second
Kaspa launched in November 2021 at one block per second, with no premine. The node was rewritten in Rust (rusty-kaspa), and the Crescendo hard fork, activated in May 2025, raised the rate to 10 blocks per second. Consensus parameters that are counted in blocks, such as k, difficulty windows and finality depth, were rescaled so their duration in real time stayed sensible, and the per-block reward was divided so emission per second didn't change.
Bitcoin
Kaspa (post-Crescendo)
Structure
Chain
BlockDAG
Target block rate
1 per 10 minutes
10 per second
Parallel blocks
Discarded as stale
Merged, coloured blue or red
Fork choice
Most accumulated work
Most accumulated blue work (GHOSTDAG)
Proof of work
SHA-256d
kHeavyHash
Emission
Halving every ~4 years
Smooth monthly reduction ("chromatic" schedule)
kHeavyHash
Kaspa's proof of work, kHeavyHash, wraps a matrix multiplication step between two Keccak-family hashes. It was originally meant to be friendly to GPUs and relatively power-efficient. As with every proof-of-work coin of significant value, dedicated ASICs arrived and have dominated mining since 2023. The choice of hash doesn't affect GHOSTDAG, which works with any proof of work.
Confirmations and finality
With blocks arriving 10 times a second, counting blocks is the wrong unit. Kaspa tracks blue score (how many blue blocks are in a block's past) and DAA score, and wallets and exchanges usually express confirmation in terms of those, which in practice means seconds of accumulated work.
The intuition matches Bitcoin's: a transaction is safe once the honest DAG has piled enough blue work on top of it that an attacker with a minority of hashrate can't produce a heavier alternative. Kaspa's gain is that this work piles up continuously rather than in 10-minute steps, so a given level of assurance arrives in seconds instead of an hour. It is still probabilistic finality secured by hashrate, not the instant finality of a BFT chain. Nodes also enforce a finality depth beyond which they refuse to reorganise, and by default they prune old block data, so a normal node doesn't keep full history.
What's missing or in progress
Kaspa's layer 1 is a UTXO ledger with a Bitcoin-like scripting system. As of mid-2026 it does not run general-purpose smart contracts. Work in and around that gap includes:
KRC-20 tokens, an inscription-style convention interpreted by off-chain indexers, similar in spirit to BRC-20 on Bitcoin.
Layer 2 projects, including EVM-compatible based rollups that use Kaspa for ordering and data.
Planned consensus changes to add covenant-style script features and on-chain verification of zero-knowledge proofs, aimed at making those rollups trust-minimised.
DAGKnight, a successor to GHOSTDAG designed to adapt to actual network latency instead of relying on a fixed k.
Timelines for these have moved before, so check the current Kaspa Improvement Proposals and node releases before building on any of them.
Summary
Fast blocks in a chain waste work and favour big miners because parallel blocks become stale. Kaspa keeps parallel blocks by letting each block reference all tips, then uses GHOSTDAG to colour well-connected blocks blue, isolated ones red, and derive one transaction order from the selected chain. The result is 10 proof-of-work blocks per second with confirmations measured in seconds, while programmability remains a work in progress.
