BlockDAG, Not Blockchain: How Kaspa's GHOSTDAG Orders Parallel Blocks

Kaspa's blockDAG is one of the most consequential design choices in proof-of-work today. Instead of forcing miners into a single chain where only one block can win each slot, Kaspa lets multiple blocks coexist — referenced, accepted, and rewarded simultaneously. The consensus algorithm that makes this safe is called GHOSTDAG.

If you've seen the term but aren't sure how ordering works when there's no single chain, this article walks through it step by step. We'll start from the problem GHOSTDAG solves, trace through the algorithm's mechanics, and finish with how Kaspa Safe and Kaspa Escrow depend on the DAG's fast, parallel block production.

Why a Single Chain Can't Go Fast

In Bitcoin, miners race to extend one chain. If two miners find a block at roughly the same time, only one survives — the other becomes an orphan, its transactions return to the mempool, and the miner's work is wasted. This is the fundamental bottleneck: increasing the block rate raises the orphan rate, which centralizes mining toward better-connected nodes and negates the speed gain.

Kaspa sidesteps this by accepting parallel blocks. If two miners each produce a block that references the same set of parents, both blocks enter the DAG. The question then becomes: how do you establish a canonical ordering so that every node agrees on which transactions came first?

That's GHOSTDAG's job.

How GHOSTDAG Orders the DAG

The algorithm proceeds in three conceptual steps whenever a new block arrives.

Step 1 — Pick a Selected Parent

Every block in the DAG has one or more parent blocks (the blocks it explicitly references). GHOSTDAG chooses exactly one of these as the selected parent — the parent that belongs to the "heaviest" chain, measured by cumulative blue work.

The starting point is the virtual block — a synthetic, node-local block that points at all current tips (newest blocks with no children yet). The virtual's selected parent is whichever tip has the most cumulative blue work. Following selected-parent links downward produces the selected chain, Kaspa's equivalent of Bitcoin's longest chain. But unlike Bitcoin, this chain coexists with all the other accepted blocks flanking it.

Step 2 — Classify: Blue or Red

Once a chain block C is established, GHOSTDAG examines C's mergeset: all blocks in C's past (reachable from C) that are *not* in the past of C's selected parent. These are the new blocks that C is absorbing into the canonical order for the first time.

Each block B in the mergeset gets classified:

• Blue — B is well-connected. Enough other blocks in C's past also reference B. Blue blocks contribute to security and receive full mining rewards.
• Red — B is too disconnected. It was mined late relative to the consensus around the selected chain. Red blocks are still accepted (their transactions still count), but they don't contribute to blue-work security. A red block that falls entirely outside the DAA window is effectively ignored for difficulty and reward calculations.

Think of it this way: blue blocks are the mainstream — the blocks that most of the network saw and built upon. Red blocks are stragglers — valid, acknowledged, but not part of the security spine. Crucially, neither category is discarded. Both carry transactions. In Bitcoin's orphan model, those transactions would have been thrown back into the mempool.

Step 3 — Sort the Mergeset

GHOSTDAG orders C's mergeset by increasing blue work, with hash as a lexicographic tiebreaker. This produces a deterministic total order for every block in the mergeset, and by extension, for every transaction included in those blocks. Every node, everywhere, arrives at the same order — that's what makes it consensus.

The selected chain is what determines the sequence of events. As the Kaspa wiki explains: chain blocks have a special role because we recursively accept their point of view. The mergeset of each chain block is sorted once, deterministically, and that ordering is final.

Confirmations, Blue Score, and the DAA

The concept of "confirmation" in Kaspa differs from Bitcoin's.

A transaction's confirmation depth is measured by how many blue blocks (and merged red blocks) have been layered on top of it. Because Kaspa currently produces blocks at roughly 10 per second, a transaction that lands in the DAG is buried under tens of blue blocks within seconds — not minutes.

The DAA (Difficulty Adjustment Algorithm) uses a moving window of 2,641 blocks. This window counts blue blocks plus red blocks that were successfully merged and rewarded. The DAA score — essentially blue score plus rewarded-red count — is the number that governs the emission schedule and serves as the time unit for on-chain time-locks.

A practical consequence: if you set a time-lock of N DAA units, it resolves in roughly N÷10 seconds. A 18,000-unit delay is about 30 minutes. A 315,000,000-unit delay (roughly one year) is one year. The granularity is two orders of magnitude finer than Bitcoin's block-height time-locks.

How Kaspa Forge Uses the DAG in Production

The DAG's properties aren't academic — they shape every time-dependent mechanism in the Kaspa Forge stack.

Kaspa Safe: Time-Locks Measured in DAA Score

Kaspa Safe is a non-custodial on-chain vault for KAS, built on Toccata covenants (vault.sil). When a user creates a vault, they choose a withdrawal delay and an inheritDelay, both specified in DAA units. Here's a typical withdrawal:

1. The user signs an initiate transaction with their hot key. The vault transitions from VAULT to UNVAULTING; the destination address is locked into the covenant's state. 2. The UTXO's age starts ticking in DAA units. Our watcher process polls every 10 seconds and checks whether age >= delay. 3. Once the threshold is met, anyone (including the watcher) can broadcast the keyless complete transaction, which sends funds to the locked destination. The covenant enforces the destination — the server cannot redirect.

Because DAA ticks at ~10 per second, a vault delay of 18,000 units resolves in about 30 minutes — fine-grained enough for practical theft protection, fast enough for usability. An inheritance delay of ~315,000,000 units works the same way: if the owner doesn't checkin to reset the UTXO's age, the heir path opens automatically. The alarm key adds another layer: during the UNVAULTING window, a separate cancel key can reset the vault to VAULT state. Because the DAG propagates blocks so quickly, a cancel transaction lands in the next available block — typically within 100 milliseconds.

Kaspa Escrow: Dispute Windows and Auto-Release

Kaspa Escrow uses the same DAA-score time-locking for peer-to-peer deal contracts. The disputeWindow parameter — configurable per deal from 24 to 168 hours in DAA units — determines how long a buyer has to file a dispute before the seller's auto-release fires.

If no dispute is filed within the window, the watcher broadcasts the keyless autoRelease() path. If a dispute *is* filed, the UTXO transitions to DISPUTED state and a separate arbiterDeadline timer begins — another DAA-scored time-lock that ultimately triggers a keyless timeout path if the human arbiter fails to respond.

The DAG's fast block production means these windows advance with high resolution. A dispute window of 2,592,000 DAA units (72 hours at 10 BPS) resolves to the second, not the block. This granularity is what makes fine-grained P2P commerce practical on Kaspa without custodians.

Chat Anchoring and Payments

The Escrow deal chat anchors each message as a ciph_msg transaction in the BlockDAG. The transaction ID serves as a tamper-evident timestamp — because parallel blocks are accepted (not orphaned), the anchor lands in the DAG immediately rather than waiting for "the next block."

Our payment gateway also relies on the DAG's fast UTXO confirmations. The gateway watcher polls getUtxosByAddresses and confirms payments based on blue-score depth — a configurable threshold, fast to settle because blocks arrive at roughly 10 per second.

Trade-offs and Honest Limitations

No consensus design comes without trade-offs.

Reorgs still happen. The selected chain can shift — GHOSTDAG calls these "small reorgs." They're frequent but shallow; the protocol guarantees the chain stabilizes quickly up to a small suffix. For time-lock covenants measured in thousands of DAA units, these micro-reorgs are negligible. For single-block-depth assumptions, they matter.

Red blocks are second-class. A transaction included in a red block is accepted, but red blocks don't contribute to blue-work security and receive reduced (or no) rewards. Miners in poorly connected geographies risk higher red rates — a mild centralization pressure, though far less severe than Bitcoin's orphan problem.

DAA-score time-locks assume stable BPS. Our covenant delays are specified in DAA units and resolved against a roughly constant block rate. A significant, sustained change in Kaspa's BPS would shift the wall-clock interpretation of these delays. At the current ~10 BPS, the mapping is straightforward — but it's an assumption, not a guarantee.

Smart contract compute budgets are tight. Kaspa's Toccata covenants operate under a compute budget (20 for standard vault transitions, 30 for migration paths, 40 for escrow contracts). This limits the complexity of on-chain logic — a deliberate design choice that keeps validation fast but restricts what covenants can express. The developers knowledge base has further context on current opcode capabilities and the Toccata roadmap.

Kaspa Safe is in beta; the vault contract (v3) has not undergone an external security audit. The v4 contract and audit are on the roadmap. The code is open-source and has self-tests against the node's VM, but open-source is not the same as audited. Use it with that understanding.

The DAG gives Kaspa its speed. GHOSTDAG gives that speed a deterministic order. And that order — measured in DAA ticks, resolvable in seconds, enforceable on-chain — is what makes the Kaspa Forge stack work.