How Coinbase Rewards Work in Kaspa's BlockDAG

In Bitcoin, block rewards are straightforward: the miner of block *N* collects the coinbase of block *N*. One block, one reward, one recipient. Kaspa's blockDAG breaks this simplicity — multiple blocks are produced in parallel, each one potentially *merging* other blocks into the shared history. The protocol needs a clear rulebook for who gets paid, when, and by whom.

This article traces that rulebook from first principles. If you've read our GHOSTDAG ordering explainer, you already know how parallel blocks get linearly ordered. Here we go one layer deeper: into the economic machinery that converts that ordering into actual payouts.

The selected chain and why it matters for rewards

Every block in the DAG has a selected parent — the single "favorite" parent chosen by the GHOSTDAG algorithm. Follow selected-parent links downward from the virtual block (the node's current view of the DAG tips) and you trace the selected chain. This chain plays a special role: it determines the canonical ordering of events, and only blocks *on* this chain produce valid coinbase transactions.

Why discard non-chain coinbases? Because in a wide DAG, the selected chain can shift (called a *reorg*). GHOSTDAG guarantees these reorgs stabilize quickly and only affect a small suffix. Basing rewards on the selected chain means the payout distribution converges to a single agreed-upon truth even when dozens of blocks are mined in parallel.

Mergesets: the group photo at each chain block

Think of a mergeset as a group photo taken at a specific point along the selected chain.

         [E]   [F]         ← tips (parallel blocks)
        / \   / \
      [C]──[D]             ← non-chain blocks, merged by A
        \ /
        [B]                ← selected parent of A (chain block)
         |
        [A]                ← earlier chain block

Here block *B* is a chain block. Its mergeset contains *C*, *D*, *E*, *F* — every block that *B* absorbs into the canonical history that wasn't already absorbed by *A*. The mergeset is what *B* "takes responsibility for" at this step of the chain.

Blue and red: who's well-connected?

Within every mergeset, each block gets classified as blue or red:

• Blue — the block was well-connected when it was mined. Plenty of other blocks reference it in their past. Blue blocks strengthen the DAG's security and earn direct rewards.
• Red — the block was poorly connected. It still gets merged into history, but it earns less favorable treatment.

A critical invariant from the protocol: every blue block is automatically inside the DAA window. Red blocks may or may not be. This distinction is what determines whether a red block generates any reward value at all.

The DAA window: the protocol's recency filter

The DAA (Difficulty Adjustment Algorithm) window is 2,641 blocks wide. In the context of rewards, it acts as a recency filter. As documented in the Kaspa wiki, blocks outside this window are considered highly disconnected — roughly 45 minutes or more had elapsed between their mining and their publication. These blocks lose all reward eligibility.

At Kaspa's current 10 blocks per second, 2,641 blocks correspond to roughly 4.4 minutes of DAG depth — though the exact real-time equivalent fluctuates with hashrate and DAG width. The window counts by block weight (blue work), not by wall-clock timestamps.

The reward algorithm, step by step

Here is where the pieces come together. When a chain block *C* constructs its coinbase transaction, it runs the following logic:

Step 1 — Calculate the subsidy. Based on the current DAA score (the running count of all blocks merged and rewarded so far), *C* looks up the emission schedule to determine the per-block coinbase subsidy.

Step 2 — Sort the mergeset. Blocks in the mergeset are sorted by GHOSTDAG order: increasing blue work, with block hash as the tiebreaker. This deterministic ordering ensures every node computes the same reward distribution independently.

Step 3 — Iterate and distribute. *C* walks through the sorted mergeset:

for each block B in mergeset (GHOSTDAG order):
    if B is blue:
        coinbase_output[i] → B.miner_address  (subsidy + B's tx fees)
        i++

# The last output always goes to C itself:
coinbase_output[i] → C.miner_address  (C's subsidy + Σ red-in-DAA subsidies)

Step 4 — Non-chain blocks are discarded. If *C* is later found not to be on the selected chain (due to a reorg), its entire coinbase is ignored by all nodes. This is the consensus rule that keeps rewards stable even during DAG reorganizations.

The result is a coinbase with exactly |MergesetBlues| + 1 outputs: one per blue block's miner, plus one final output paying the chain block's miner (which aggregates the chain block's own subsidy and all subsidies from red-in-DAA-window blocks).

A concrete example

Imagine chain block *C* has a mergeset of four other blocks:

mergeset = [A, B, D, E]   (sorted by GHOSTDAG order)

A: blue, in DAA window    → A's miner receives 1 subsidy + A's fees
B: blue, in DAA window    → B's miner receives 1 subsidy + B's fees
D: red, in DAA window     → reward folded into C's output
E: red, outside DAA window→ no reward generated

C itself                  → C's miner receives C's subsidy + D's subsidy

Coinbase outputs: 4 (= |2 blues| + 1). Miners of *A* and *B* each receive one subsidy plus transaction fees from the transactions they accepted. Miner of *C* receives two subsidies (its own, plus *D*'s). Miner of *E* receives nothing — that block was too disconnected. Miner of *D* also receives nothing directly; the value of *D*'s mining work accrues to *C*'s miner instead.

This design creates a clear incentive: mine blocks that will be well-connected, and publish them promptly. Delayed or poorly propagated blocks risk becoming red, and if they're red enough to fall outside the DAA window, their mining work generates no reward for anyone.

How Kaspa Forge uses DAA score

The DAA score and the blue-score mechanism don't just determine who gets paid — they're also the protocol's native clock. Instead of relying on block timestamps (which miners can manipulate within certain bounds), Kaspa's covenant-enabled tools measure elapsed time in DAA score increments.

This matters for the tools built on Kaspa Toccata:

• Kaspa Safe uses UTXO age — measured in DAA score — to enforce vault withdrawal delays. When you set a delay on your vault, the covenant doesn't check a wall clock; it checks whether the UTXO has aged by enough DAA score increments. The alarm key's cancellation window works the same way. See how the vault works.

• Kaspa Escrow defines dispute windows and arbiter deadlines in DAA scores. A 72-hour dispute window on a goods deal translates to a specific DAA score delta, making the timeout resistant to timestamp manipulation by any party.

• Payment acceptance in Kaspa-based commerce relies on blue-score progression as confirmation depth. The confirmation threshold — how many blue-score increments to wait — is a direct application of the same metric that underlies the reward algorithm.

Trade-offs and honest limitations

Red-block punishment is intentional but has a cost. By redirecting red-block rewards to the chain block miner (or voiding them entirely for blocks outside the DAA window), Kaspa incentivizes well-connected mining. The trade-off: miners with poor network connectivity lose reward potential even when they find valid blocks. This is a deliberate security choice — it encourages dense connectivity and faster DAG convergence — but it means miners in high-latency environments face an inherent disadvantage.

Non-chain coinbases are discarded after stabilization. During normal operation, nodes may temporarily accept a non-chain block's coinbase as valid. Only when the DAG stabilizes (the selected chain commits) does consensus converge on which coinbase actually pays out. For miners tracking revenue in real time, a block's reward isn't fully confirmed until it sits on or is clearly merged by the selected chain.

DAA-window time ≠ wall-clock time. The 2,641-block window roughly corresponds to minutes of real time at 10 BPS, but the exact duration varies with hashrate changes and DAG width. Covenant timeouts in Kaspa Safe and Kaspa Escrow are therefore *protocol-time* timeouts — perfectly consistent within the protocol, but they don't map to exact human-clock durations. A "24-hour" vault delay might resolve a few percent faster or slower depending on network conditions. For most practical purposes the difference is negligible; for time-critical financial planning, it's worth knowing.