Kaspa DAA Score, Pruning & Finality

Kaspa produces a block every second. At that rate, a question Bitcoin answers trivially — *"how old is this UTXO?"* — becomes genuinely hard. In a DAG there is no single chain, no single height. Kaspa's answer is the DAA score: a consensus-agreed clock that every node computes identically, used to schedule difficulty, measure UTXO age, and — in the covenants powering Kaspa Forge — enforce dispute windows and vault delays.

This article explains what DAA score is, how it relates to blue score and the difficulty adjustment window, what pruning means for a high-throughput blockDAG, and how GHOSTDAG provides fast practical finality. We close with how Kaspa Forge denominates escrow and vault timeouts in DAA score rather than wall-clock hours.

The Problem: Telling Time in a DAG

In Bitcoin, blocks form a single chain. Block height is unambiguous and timestamps are roughly monotonic. Covenant opcodes like OP_CHECKSEQUENCEVERIFY measure "relative time" in block intervals — straightforward.

Kaspa's blockDAG is different. Multiple blocks are produced in parallel; the GHOSTDAG protocol selects one as the selected parent of each block, forming a virtual "selected chain," but this chain can reorganise. The Kaspa wiki notes that the selected chain "stabilizes very fast up to a small suffix," but raw block count across the entire DAG includes red (non-blue) blocks that may or may not contribute to consensus. A naive "block height" metric is therefore non-deterministic across nodes.

Kaspa needs a deterministic, monotonically increasing counter that all honest nodes agree on. That counter is the DAA score.

Blue Score: the DAG's Backbone

The GHOSTDAG algorithm classifies every block as either blue (well-connected, contributing to security) or red (disconnected or arriving late). From the perspective of any chain block *C*, its mergeset is the set of blocks in *C*'s past but not in *C*'s selected parent's past. Blue blocks in the mergeset earn a coinbase reward from *C*; red blocks that fall inside the DAA window also earn a reward for the merging miner.

Blue score is local to a block's viewpoint, but for the selected chain it converges — two nodes that see the same selected tip will agree on its blue score.

DAA Score: Kaspa's Consensus Clock

DAA score is the quantity the difficulty adjustment algorithm reads to calibrate mining difficulty, and it is the metric that Silverscript covenants reference for time-based conditions (age >= delay). Think of it as "consensus time" — not wall-clock seconds, but a tick of the ledger's internal clock that every node computes identically.

Why not use timestamps? In a DAG with parallel blocks, miners' clocks disagree. Median-time-past (a window of 263 blocks, per the wiki) helps for coarse ordering, but a covenant that gates funds on "this UTXO must be 72 hours old" needs an exact, deterministic threshold. DAA score provides that.

The DAA Window: Difficulty Adjustment in a BlockDAG

Kaspa's difficulty adjustment algorithm uses a moving window of 2 641 blocks — the set of blue blocks plus qualifying red blocks counted backward from the virtual block's perspective. The wiki explains that blocks outside this window are ones "which at least 45 minutes passed between their mining and publication times — that is, they are highly disconnected."

The algorithm sums the work in that window, divides by the window's time span, and adjusts difficulty so the target block rate (currently ~10 blocks per second) is maintained. Because the window includes red blocks that were actually merged — not orphaned — the DAA score rises faster than blue score alone, reflecting the real throughput of the ledger.

At ~10 BPS the DAA score increments by roughly 864 000 per day. A 72-hour dispute window in Kaspa Forge's escrow contract translates to approximately 259 200 DAA-score units — a conversion the UI performs transparently when a user picks a preset.

Pruning: Shrinking the Ledger

A 10-BPS blockDAG produces orders of magnitude more data per day than Bitcoin. Without pruning, running a full node would eventually require terabytes of storage and hours to sync.

Pruning discards block bodies (transactions, witnesses) that are no longer needed for consensus, while retaining:

• the UTXO set — the current set of spendable outputs;
• a commitment to the full DAG structure — so a freshly synced node can verify it received the correct UTXO snapshot;
• recent blocks — within the pruning horizon, needed for block relay and the DAA window.

The boundary is called the pruning point. Blocks older than it can be safely dropped. A pruned node can still validate all new transactions and participate fully in consensus. It cannot, however, serve historical block data to new nodes syncing from scratch; that role falls to archival nodes.

Kaspa's active research includes the "Extended mass formula for mitigating state bloat" KIP (listed as in-development on the wiki), which aims to bound the growth rate of the UTXO set itself — a separate but complementary concern to block-data pruning.

For node operators, pruning is what keeps a Kaspa node feasible on commodity hardware: instead of unbounded growth, disk usage stabilises at roughly (UTXO-set size + pruning-window size).

Finality: How Fast Is "Done"?

GHOSTDAG's security guarantee is that the selected chain is robust: it can reorganise, but only in a short suffix. The deeper a block is in blue work, the more expensive it becomes to reverse.

In practice, Kaspa achieves fast practical finality:

• At ~10 BPS, a transaction included in a blue block that is 100 blocks deep (roughly 10 seconds of real time) has already accumulated significant blue work.
• The Kaspa payments integration in our stack uses a configurable confirmation threshold based on blue-score depth — the number of blue-score increments after inclusion.
• For covenant-based time locks (vault delays, escrow windows), finality is less about irreversibility and more about the deterministic age counter. Once the DAA score of a UTXO passes the threshold, the covenant's condition is satisfied — no ambiguity.

The key distinction from Bitcoin: finality is not about a magic number like "6 confirmations." It is about cumulative blue work above the block, which GHOSTDAG's structure makes both measurable and fast-growing.

How Kaspa Forge Uses DAA Score in Production

The connection between DAA score and our tooling is concrete and visible to every user of Kaspa Escrow and Kaspa Safe.

Escrow dispute windows

When creating a P2P deal in Kaspa Escrow, the buyer and seller choose a dispute window from six presets: 24 / 48 / 72 / 96 / 120 / 168 hours. Internally, the UI converts these to DAA-score increments based on the current block rate (~864 000 per day at 10 BPS). The on-chain covenant escrow.sil stores these as the disputeWindow and arbiterDeadline constructor parameters — both denominated in DAA units.

The contract enforces two time gates:

autoRelease:  mode == ACTIVE   && age >= disputeWindow  → funds to seller, keyless
timeout:      mode == DISPUTED && age >= arbiterDeadline → funds per timeoutTo, keyless

The age here is the UTXO's age in DAA-score units — the difference between the current DAA score and the score at which the escrow UTXO was created. Every node computes the same value.

Vault delays

The vault covenant (how the vault works) uses the same mechanism. When a vault owner initiates a withdrawal, the complete() path requires age >= delay — again in DAA units. The alarm key can cancel during this window. The inheritAuto() path works identically for inheritance: age >= inheritDelay with autoInherit == 1.

The watcher layer

Our backend polls the node via gRPC every 10 seconds. For escrow deals, it tracks each UTXO's DAA-score age and fires pre-alerts at 50% and 90% of the dispute window, plus a warning roughly 20% before the arbiter deadline. For vaults, it reminds the owner to check in at ≥80% of the inheritance delay.

None of this requires the server to hold keys. The watcher merely broadcasts keyless covenant paths (autoRelease, complete, inheritAuto) at the right DAA-score moment — the covenant itself enforces who receives the funds.

Why DAA score, not clock time

A natural question: why not timestamps? In a single-chain blockchain, median-time-past is a reasonable proxy. In a 10-BPS blockDAG, timestamp manipulation is easier (parallel blocks, miner clock skew), and consensus requires exact agreement. DAA score is computed identically by every node from the same DAG structure — no ambiguity, no drift, no attack surface around clock manipulation.

The trade-off is precision: a "72-hour" dispute window might last 70 or 75 real hours depending on hashrate fluctuations. At 10 BPS with Kaspa's relatively stable hashrate, the variance is small — and the determinism is worth it.

Trade-offs and Honest Limitations

• DAA score ≠ wall-clock time. If hashrate drops sharply (a large miner goes offline, for example), the DAA score increments more slowly and a "72-hour" window can stretch. The difficulty adjustment compensates, but there is a lag. Users choosing very short dispute windows should be aware of this.

• Pruning has costs. A pruned node cannot bootstrap new peers; archival nodes are still required for initial sync. The ecosystem depends on enough operators choosing to run archival infrastructure.

• Finality is probabilistic, not absolute. GHOSTDAG's robustness guarantee means deep reorgs are astronomically expensive, but "impossible" is not a word we use. For high-value transactions, waiting for more DAA-score depth is always prudent.

• Covenant age resolution is per-DAA-tick. There is no sub-DAA-score granularity. At 10 BPS each tick is roughly 100 ms — fine for dispute windows measured in days, but not for anything sub-second.

• Pruning point migration during protocol upgrades may require resyncing historical data on archival nodes. Operators should track release notes for hard-fork-related pruning-point changes.

---

FAQ

Q: What is the Kaspa DAA score? A: DAA score equals a block's blue score plus the cumulative count of red blocks that have been merged and rewarded. It is a consensus-agreed, monotonically increasing counter that controls the emission schedule and serves as the time metric in covenant scripts.

Q: How does pruning work in Kaspa's blockDAG? A: Pruning discards old block bodies beyond the pruning point while preserving the UTXO set and a commitment to the DAG structure. A pruned node validates all new transactions but cannot serve full history to syncing peers — archival nodes handle that.

Q: Why do escrow dispute windows use DAA score instead of hours? A: DAA score is deterministic: every node computes the same value from the DAG. Wall-clock time is not consensus-agreed in a parallel-block DAG. Kaspa Forge converts hour-based presets to DAA-score increments so the on-chain covenant enforces them exactly.

Q: How is finality different in Kaspa vs. Bitcoin? A: Bitcoin measures finality in block confirmations along a single chain. Kaspa's GHOSTDAG measures it by cumulative blue work in a DAG — deeper blue-work depth means exponentially higher reversal cost, and it grows faster because multiple blocks are produced per second.

Q: How many DAA-score units are in a day? A: At Kaspa's current rate of roughly 10 blocks per second, the DAA score increments by about 864 000 per day. This can drift slightly if hashrate shifts before the difficulty adjustment compensates.

Q: Can the DAA score decrease? A: No. DAA score is monotonically increasing. Even during a selected-chain reorganisation the new tip's DAA score is at least as high as the previous one — a consequence of GHOSTDAG's robust chain property.