Kaspa DAA: How the 2641-Block Window Keeps 10 BPS Stable

At ten blocks per second, Kaspa produces roughly 864,000 blocks per day. Bitcoin produces 144. This speed is what makes Kaspa practical for sub-second payments and responsive covenant contracts — but it also means the network's difficulty adjustment algorithm has to work fundamentally differently from Bitcoin's. A two-week retarget cycle would be absurd at this cadence; difficulty would lag hashrate changes by days.

Kaspa's Difficulty Adjustment Algorithm — the DAA — solves this with a 2641-block sampling window that recalculates target difficulty on virtually every new block. This article explains how that window is constructed, how it distinguishes well-connected blocks from stale ones, and how the resulting DAA score becomes the consensus clock that Kaspa Safe, Escrow, and Deposit rely on for on-chain time-locks.

Why a BlockDAG Needs Its Own DAA

Bitcoin's difficulty adjustment retargets every 2016 blocks — roughly two weeks. At one block every ten minutes, that window covers enough statistical variance to keep block times near the ten-minute target. The algorithm is simple and battle-tested, but it assumes a single chain where blocks arrive one at a time.

Kaspa's BlockDAG produces multiple blocks in parallel. At 10 BPS, 2016 blocks pass in about three and a half minutes. A naive retarget on such a short window would oscillate wildly: a brief hashrate dip would crater difficulty, attracting miners back and overshooting in the other direction. The protocol needed an algorithm that:

• samples enough blocks to smooth variance, but few enough to react within minutes;
• works on a DAG where blocks have multiple parents, not a single chain;
• distinguishes well-connected blocks from stale or disconnected ones.

The result is documented in the Kaspa wiki's Developers Knowledge Base and implemented in the protocol's difficulty.go source.

The Virtual Block: Where the Window Starts

Every Kaspa node maintains a virtual block — not a real mined block, but a synthetic reference pointing at all current DAG tips. The virtual has a selected parent (the tip chosen by the GHOSTDAG protocol), and walking down the chain of selected-parent links gives the selected chain.

The DAA window counts backward from the virtual's perspective along this selected chain. Because the virtual updates every time a new block arrives, the window is always fresh. Think of it as a sliding average anchored to the node's current view of consensus — not a fixed calendar interval, but a fixed sample of work.

What the 2641-Block Window Contains

The window is not simply "the last 2641 blocks." It is 2641 blocks counted backward from the virtual, filtered by connectivity:

• All blue blocks in the selected chain's past are included. A blue block was well-connected when it was merged — it contributed to consensus security. If a block is blue, it is guaranteed to be inside the DAA window.
• Red blocks (blocks that were poorly connected or arrived too late to be blue) are included only if they are not excessively stale. The practical threshold is roughly 45 minutes: a red block whose timestamp is more than ~45 minutes behind its merging block is considered highly disconnected and excluded.

This filtering matters. Without it, a burst of very late blocks could skew the timestamp sample and distort difficulty. By excluding the most disconnected red blocks, the DAA keeps its time estimates grounded in blocks that actually participated in consensus.

How Difficulty Is Computed

The algorithm takes the timestamps and difficulty targets of the blocks in the window and computes a new target. The core logic:

1. Sample timestamps. For each block in the window, record its timestamp. Because the window includes both blue and qualifying red blocks, the sample reflects the actual rate at which the network produced work — not just the selected chain's rate.

2. Calculate actual work rate. Sum the work represented by all blocks in the window (each block's work is a function of its difficulty target). Divide by the time elapsed between the first and last block in the window. This gives the observed hashrate.

3. Compare to target rate. Kaspa targets a specific blocks-per-second rate (currently 10 BPS). The expected work for the window duration is the target rate × window duration × work-per-block-at-target-difficulty.

4. Adjust difficulty. If the observed work rate exceeds the target, difficulty increases. If it falls short, difficulty decreases. The adjustment is proportional, not stepped — there is no discrete "retarget event." Each new block effectively recalculates.

At 10 BPS, the 2641-block window spans roughly 264 seconds — about 4.4 minutes. A hashrate change is reflected in difficulty within minutes, not weeks.

DAA Score: The Consensus Clock

DAA score is a running counter derived from the DAA window's bookkeeping:

DAA score = blue score + number of red blocks successfully merged and rewarded

Where blue score is the count of blue blocks in a block's past. DAA score is always ≥ blue score, because it also counts rewarded red blocks.

This counter serves two purposes:

1. Emission schedule. The coinbase subsidy for each block is calculated from the current DAA score. Because DAA score advances at a predictable rate (roughly tracking total blocks produced), it provides a stable basis for the chromatic emission curve.

2. Programmable clock for covenants. Covenant scripts can check the DAA score of the spending transaction against a threshold. Instead of comparing wall-clock timestamps (which miners can manipulate within a tolerance), covenants compare DAA scores — a value that the entire network agrees on and that advances at a rate tied to actual block production.

At 10 BPS, DAA score advances at roughly 10 units per second. A covenant that requires a 600-unit delay is enforcing approximately one minute of real time.

Edge Cases the Window Handles

Hashrate spike. Blocks arrive faster than 10 BPS. The window fills with recent timestamps, the observed work rate climbs, and difficulty increases — within minutes.

Hashrate drop. Blocks slow down. The window stretches in wall-clock time, the observed work rate falls, and difficulty decreases — again within minutes.

Large reorg. The selected chain shifts. The virtual block's selected parent changes, and the DAA window is recomputed from the new perspective. Because the window is only ~4.4 minutes deep, a reorg affecting the window's tail is rare but handled: the new window reflects the new selected chain's history.

Burst of red blocks. If many blocks arrive late and are classified red, they still contribute timestamps to the DAA window (unless they exceed the ~45-minute staleness threshold). This prevents a sudden influx of late blocks from distorting difficulty downward.

How Kaspa Forge Uses DAA Score

The DAA score is not just a mining parameter — it is the time reference that on-chain covenants throughout the Kaspa Forge stack rely on.

Kaspa Safe uses DAA score for withdrawal delays. When a vault owner initiates a withdrawal, the covenant enforces a waiting period measured in DAA score units. The alarm key can cancel the withdrawal during this window. Because DAA score is consensus-enforced, the delay is predictable and cannot be bypassed by manipulating timestamps.

Kaspa Escrow uses DAA score for deal timeouts. If neither party completes a P2P deal, the escrow covenant's timeout path activates after a DAA-score threshold is reached. This prevents funds from being locked indefinitely.

Kaspa Deposit uses DAA score for collateral lock periods. A landlord or service provider can require that deposit funds remain covenant-locked for a minimum DAA-score duration, with claim and refund paths gated by the same counter.

In each case, the covenant script contains a check like:

// Pseudocode: enforce a DAA-score delay
if (tx.daaScore - lockStartDaaScore) >= requiredDelay:
    allow timeout / refund path

This pattern works because every Kaspa node agrees on the DAA score of every transaction. There is no ambiguity, no miner timestamp manipulation, and no reliance on off-chain clocks.

Trade-offs and Honest Limitations

Window size vs. responsiveness. A 2641-block window at 10 BPS is ~4.4 minutes. This is responsive, but it means difficulty can fluctuate more than Bitcoin's over short intervals. The trade-off is intentional: Kaspa prioritizes fast adaptation over absolute stability.

Red block inclusion is conservative. The ~45-minute staleness threshold means very disconnected blocks are excluded from the DAA window. This prevents timestamp manipulation but also means that a burst of very late blocks contributes no timestamp data to difficulty calculation. In practice, this is rare and self-correcting.

DAA score is not wall-clock time. Covenant authors must remember that DAA score advances at roughly 10 units per second, but the actual rate depends on network conditions. A hashrate drop slows DAA score advancement; a hashrate spike accelerates it. For most covenant use cases (delays of minutes to hours), this variance is negligible. For very long lock periods (months), the drift could be meaningful — though Kaspa's difficulty adjustment keeps the rate close to target.

No miner-selectable minimum fee (yet). The protocol's minimum relay fee is an anti-spam measure, not a mining policy. Miners currently select transactions by fee rate, but there is no protocol-enforced minimum. This is a separate concern from DAA, but it affects the fee market that all Kaspa Forge transactions participate in.

Summary

Kaspa's DAA replaces periodic retargeting with a continuous, sliding-window adjustment. The 2641-block window — filtered to include blue blocks and non-stale red blocks — gives the algorithm enough data to smooth variance while remaining responsive to hashrate changes within minutes. The resulting DAA score serves double duty: it drives the emission schedule and acts as the consensus clock that on-chain covenants use for time-locks. For Kaspa Forge products, this means withdrawal delays, deal timeouts, and collateral lock periods are enforced by the protocol itself — not by timestamps that miners can nudge.