Inside the Kaspa Virtual Block, the Head Every Node Computes

Kaspa runs at 10 blocks per second and lets blocks be created in parallel, so at any given moment there is no single "latest block" sitting at the tip of a chain. There is a growing pile of blocks that reference each other. Yet wallets still need one answer to "what is my balance", explorers need one answer to "what is the current state", and contracts need one answer to "which spending path is available right now". The answer in Kaspa is a block that is never mined: the virtual block. This is a technical deep dive into what the virtual block is, how a node rebuilds it on every update, and how Kaspa Forge derives its product state from it.

Why a BlockDAG needs a "current block"

In a linear blockchain, the head of the chain is obvious: it is the block with the most work on top of the previous one. Software hangs everything off it — balances, mempool validation, difficulty, timestamps.

A DAG removes that convenience. Miners publish blocks concurrently, and new blocks can reference several parents at once. At 10 BPS there are constantly multiple recent blocks that do not yet reference each other. If each application had to reason about this graph directly, every wallet, exchange and contract would need its own consensus code.

Kaspa's answer is a per-node abstraction: an imaginary block that references everything the node currently knows about. Call it the clerk analogy. The DAG is the mailroom — thousands of letters arriving per minute, some out of order, some referencing earlier letters. The virtual block is the clerk's single open ledger page, continuously rewritten from whatever is in the mailroom right now. Every question about "the current state of the world" is asked of that page, not of the mailroom.

What the virtual block actually is

Three properties matter.

It is local. Each node builds its own virtual from the blocks it has received. Two nodes with slightly different block sets have slightly different virtuals. This is not a bug; it is the honest consequence of a distributed system with latency. The nodes converge because gossip propagates blocks quickly over TCP.

It behaves like a block. The virtual has a selected parent, called the selected tip, chosen by the same GHOSTDAG algorithm that orders ordinary blocks. Starting from the selected tip and walking down "selected parent" links gives the selected chain. The selected chain is what determines the order of events in the DAG. Because the virtual's point of view changes as new tips appear, the selected chain can change too — that is a reorg.

Everything measured "from now" is measured from it. Blue score is the number of blue blocks in the node's past from the virtual's perspective. The difficulty adjustment window is counted backwards from the virtual. The transaction ordering that the node reports as "current" is the virtual's ordering.

Step by step: how a node rebuilds the virtual

blocks arriving via gossip (k-heavyhash PoW checked)
        │
        ▼
   DAG tips: every block with no children yet
        │
        ▼
  ┌─────────────────────────────────────────┐
  │  virtual = imaginary block at all tips   │
  │  selected parent = selected tip (GHOSTDAG)│
  └─────────────────────────────────────────┘
        │
        ├── selected chain  → event ordering
        ├── blue score      → counter of blue blocks
        ├── DAA score       → blue + merged reds → emission
        └── DAA window 2641 → difficulty

1. Blocks arrive. Peers relay block hashes and mempool transaction hashes to active peers; the node fetches what it is missing and validates proof-of-work and structure before adding anything to its DAG. 2. GHOSTDAG assigns order. Each block gets a selected parent. For any chain block C, its mergeset is the set of blocks in C's past but not in the past of C's selected parent (the mergeset includes the selected parent itself). The mergeset is sorted by increasing blue work, tie-broken by hash lexicographically. 3. The virtual is rebuilt. It now points at all current tips. Its selected parent becomes the new selected tip, and the selected chain is re-derived from it. 4. Counters move with it. Blue score, DAA score, difficulty window and the node's notion of the current UTXO state are all re-derived from this new virtual. 5. Repeat, continuously. Every accepted block moves the virtual. At 10 BPS this happens ten times a second on average.

Step 3 is where reorgs live. If the new virtual picks a different selected tip than before, the selected chain shifts a little. In a wide DAG small reorgs are frequent — but GHOSTDAG's security argument is that the chain is *robust*, meaning it stabilises very fast up to only a small suffix. Practically: the last few moments are always provisional, everything older is boringly stable.

Blue score, DAA score and the window behind them

These three counters are easy to confuse because they are all derived from the virtual's perspective.

• Blue score — the number of blue blocks in the node's past from the virtual's point of view. Blue means well-connected: a block that contributes to security rather than being a stray branch.
• DAA score — blue score plus the red blocks so far that were successfully merged and rewarded. This is the counter that controls the emission rate via the difficulty adjustment algorithm.
• DAA window — 2641 blocks, counting backwards from the virtual, including blue blocks and the red ones that fit in the window. It is what keeps the block rate at its target. (The wiki notes that blocks outside this window are ones where roughly 45 minutes passed between mining and publication — i.e. highly disconnected stragglers.)

There is also a 263-block past median time window. That is why block timestamps are a poor clock: median-based windows resist manipulation, which is exactly why covenants that need a reliable "not before" condition use DAA score as a programmable clock rather than wall-clock time.

Rewards are also decided from a chain block's virtual-like perspective: a chain block C iterates its mergeset in GHOSTDAG order, appends one coinbase output per blue block it merged (the i-th output pays the i-th blue block's miner), and pays itself for merged red blocks that fall inside its DAA window. A block that never ends up as a chain block produces a coinbase that is discarded after the DAG stabilises. For a miner or a payment watcher, "my block was found" is not the same as "my block's coinbase is in the settled order" — the virtual is what eventually tells you which.

How Kaspa Forge reads product state from the virtual

Every Kaspa Forge surface is a projection of the DAG as seen from a node's virtual, and our indexer is built around that fact.

• Kaspa Safe vault deposits each become their own covenant-locked UTXO. The vault's live state — how much is locked, whether a withdrawal is inside its delay, whether the alarm key path is available — is read from the UTXO set the virtual currently implies. The delay itself is expressed in DAA score, so it advances only as the DAG genuinely advances.
• Kaspa Escrow deals are on-chain contract state machines. The UI shows which spending path is currently open (refund, claim, dispute, timeout) based on the projected state at the virtual; the escrow contract, not our server, decides what is spendable.
• Deposit collateral behaves the same way: KAS is blocked by the covenant, and the return / claim / dispute paths are contract paths whose triggers read the same DAA-score clock.
• Marketplace listings never hold a buyer's funds — chat leads the parties into a separate escrow deal, and the listing page just renders indexed state.
• Desk computes wallet balances from the virtual's UTXO set. Nothing about this touches key material: keys stay on the device, and the virtual is a read model of the ledger, not a custodian.
• Boards posts, replies and tips are on-chain data. The index that renders them is rebuildable: if the virtual moves and a post drops out of the settled order, the projection is recomputed rather than patched.
• Arena Blackjack is a public mainnet beta where funds sit in Room/Game UTXOs and the player signs locally. The game state machine advances when the virtual accepts the signed transaction, while the fairness proof is verifiable independently of any of this.

The key engineering consequence: since the virtual is provisional near the head, nothing derived from it may be treated as permanent. Reorg-aware projections mean state can be rebuilt from the DAG rather than incrementally patched, so a small reorg costs a recompute, not a corrupted database.

Trade-offs and honest boundaries

"Confirmed" is not "final". The virtual moves, and small reorgs are normal in a wide DAG. Any product that shows virtual state — balances, deal status, game rounds — must handle the head being rewound a little. The mitigation is not to pretend it cannot happen; it is rebuildable projections and sensible confirmation expectations.

Two nodes, two virtuals. Momentary disagreement between nodes is inherent. For users this is invisible in practice, but for integrators it means your indexer's view is *your* node's view. Running your own node is the only way to own that view; Kaspa Forge runs its own infrastructure for exactly this reason, and you can point the open tooling at yours.

Mempool is not state. A transaction sitting in the mempool is not part of the virtual's UTXO state. It is also not immortal: relayed transactions are dropped after 60 blocks without inclusion, while transactions submitted over RPC are rebroadcast indefinitely until the node restarts. If a deal or deposit transaction is pending, the UI has to show *pending*, not *done*.

Pruning bounds history. The DAA score is what controls emission, but older DAG data is pruned. Historical queries ("what happened to this UTXO three weeks ago") require an indexer that kept the data — which is why our projections store what products need instead of relying on a pruned node.

PoW is still the root. Everything above is only meaningful because blocks carry real k-heavyhash proof-of-work and are gossiped between peers. The virtual block is bookkeeping; the energy spent by miners is the anchor that makes rewinding that bookkeeping expensive.

Product status, stated plainly: Arena Blackjack is a public mainnet beta. Dice is engineering work, its permanent production arm is off pending independent review. Duel, baccarat and Permissionless Tokens are roadmap items, not live services — they are not available to try, and this article describes no live surface for them.

For the protocol definitions behind all of this — virtual, blue score, DAA score, mergeset and reward rules — the Kaspa wiki developers knowledge base is the reference we work from.