DAA score and block time

Kaspa's clock counts blocks, not seconds, and it counts them at two different speeds since Crescendo split it. Convert any DAA score back to genesis, then try to fake a block's timestamp and watch the network catch the lie.

1. Read a DAA score

A DAA score is Kaspa's own counter: it goes up by roughly one for every block the network accepts, not by one every second. It also doesn't go up at a constant speed. Before Crescendo (5 May 2025), Kaspa produced about 1 block a second. After, it produces 10. Converting a score from either side of that boundary at the other side's rate would land you badly wrong, so this converter switches rates at Crescendo, marked below.

Crescendo
genesistoday and beyond

Two real anchor points fix this: Kaspa's genesis block (exact) and Toccata's mainnet activation (exact, DAA score 474,165,565). Rates in between are interpolated from those, not assumed. Measured between Crescendo and Toccata, the network ran 421 days at 0.06% off the 10-per-second target. Dates after Toccata assume that target keeps holding, so they're an estimate, not a fact to cite as exact.

2. Try to lie about when a block happened

A block's timestamp is a number whoever mined it typed in. Nothing stops them writing a false one, so the network doesn't trust it: it checks the number against a rule before accepting the block. Try to write a false timestamp below and watch the rule catch it.

The rule: a block's timestamp must land after the past median time, the middle value of its last 11 ancestor timestamps, and it can't sit more than 132 seconds ahead of the checking node's own clock.

refused: too old accepted refused: too far ahead

3. Bitcoin has the same problem

Bitcoin has no trusted clock either, and it catches a lying miner almost the same way Kaspa does: a block's time must land after the median of its previous 11 blocks, and can't run more than 2 hours ahead of a node's own clock. Kaspa uses that identical 11-block median. What's different is how much slack the future check allows.

Bitcoin can afford 2 hours of slack because it expects a block roughly every 10 minutes. Kaspa expects one roughly every tenth of a second, so the same kind of rule needs a far tighter leash.

4. Why a DAG needs its own median

Bitcoin's 11 ancestors are a straight line: block 100 always follows block 99. On Kaspa's DAG, many blocks are mined in parallel and merge together, so there's no single line of 11 to walk, only a sampled window across the blocks the network has already folded in.

A, B, and C arrived at nearly the same moment from different miners. All three raise the DAA score together, and all three can count toward the median. None of them is "block 100" on its own.

How this is worked out, and where the numbers come from

DAA score is a block count, not a timer

Each block inherits its selected parent's DAA score and adds the number of new blocks in its own merge set that qualify for the difficulty window: daa_score = parent_daa_score + (mergeset_size - mergeset_non_daa_count). Source: consensus/src/processes/difficulty.rs, function internal_calc_daa_score, in kaspanet/rusty-kaspa.

Why the old converter was wrong, and what changed

The previous version of this page anchored on Toccata's activation and applied a single flat rate, 10 DAA units per second, all the way back through history. Kaspa's own consensus config shows that rate only held after Crescendo: consensus/core/src/config/params.rs sets mainnet's pre_crescendo_target_time_per_block to 1000 milliseconds (1 block per second) and its post-Crescendo target_time_per_block to 100 milliseconds (10 blocks per second), with crescendo_activation at DAA score 110,165,000. A flat 10-per-second rate applied to a pre-Crescendo score overstates elapsed time by roughly 10x for every day, which is many months of error for anything mined before 5 May 2025. The converter now switches rates at that boundary and interpolates between three real anchors: Kaspa's mainnet genesis (DAA 0, an exact protocol constant), Crescendo's activation (DAA 110,165,000, near 5 May 2025, 15:00 UTC per Kaspa's own activation announcement), and Toccata's mainnet activation (DAA 474,165,565, an exact date from the release notes).

The date conversion used above

Genesis anchors the pre-Crescendo segment; Toccata anchors the post-Crescendo segment; both are exact. The rate within each segment is the real elapsed time between its two anchors divided by the DAA units between them, not the bare protocol target, so the two segments meet with no jump at the Crescendo boundary. That interpolation puts the actual average between Crescendo and Toccata at about 0.06% off the 10-per-second target across 421 days, which is the basis for calling the post-Crescendo approximation good, not exact. Dates after Toccata extrapolate forward at the 10-per-second target rate, since there's no later anchor yet.

Timestamp rules used above

Past median time: a block's timestamp must be strictly greater than the median of the 11 values closest to the center of a sampled window of its ancestors' timestamps. Source: consensus/src/processes/past_median_time.rs, constant AVERAGE_FRAME_SIZE = 11, implementing KIP-0004, Sparse Difficulty Windows. A timestamp at or before that median fails with RuleError::TimeTooOld, checked in consensus/src/pipeline/header_processor/post_pow_validation.rs.

Future bound: a header is rejected if its timestamp is more than 132 seconds ahead of the validating node's own clock, failing with RuleError::TimeTooFarIntoTheFuture. Source: consensus/src/pipeline/header_processor/pre_ghostdag_validation.rs (max_block_time = unix_now() + timestamp_deviation_tolerance * 1000), constant defined as TIMESTAMP_DEVIATION_TOLERANCE = 132 in consensus/core/src/config/constants.rs.

Bitcoin's rule, checked against its own source

Bitcoin Core rejects a block whose time is at or before GetMedianTimePast(), the median of the 11 preceding blocks (nMedianTimeSpan = 11), with the reject reason time-too-old. It also rejects a block timestamped more than MAX_FUTURE_BLOCK_TIME (2 hours, 7,200 seconds) ahead of the node's own clock, with reject reason time-too-new. Source: bitcoin/bitcoin, src/chain.h (nMedianTimeSpan, MAX_FUTURE_BLOCK_TIME) and src/validation.cpp (the two checks, near CheckBlockHeader/ContextualCheckBlockHeader). Same shape as Kaspa's rule, a strict median-of-11 floor plus a future ceiling; the ceiling is roughly 55 times looser on Bitcoin because Bitcoin expects a block roughly every 10 minutes, not every tenth of a second.

Constants used, and where they live

ConstantValueSource
Mainnet genesisDAA score 0, timestamp 1,637,609,671,037 ms (22 November 2021, UTC)consensus/core/src/config/genesis.rs, GENESIS.timestamp
Target block time, pre-Crescendopre_crescendo_target_time_per_block = 1000 ms (1 block/second)consensus/core/src/config/params.rs, mainnet MAINNET_PARAMS
Crescendo activationDAA score 110,165,000, projected 5 May 2025, 15:00 UTCconsensus/core/src/config/params.rs, crescendo_activation; date from Kaspa's own activation announcement
Target block time, post-Crescendotarget_time_per_block = 100 ms (10 blocks/second)consensus/core/src/config/bps.rs, BlockrateParams::new::<10>() in MAINNET_PARAMS
Toccata mainnet activationDAA score 474,165,565, roughly 30 June 2026, 16:15 UTCrusty-kaspa v2.0.0 release notes; see this site's claims registry
Past-median-time averaging frame, KaspaAVERAGE_FRAME_SIZE = 11 timestampsconsensus/src/processes/past_median_time.rs
Timestamp deviation tolerance, KaspaTIMESTAMP_DEVIATION_TOLERANCE = 132 secondsconsensus/core/src/config/constants.rs
Median-time window, BitcoinnMedianTimeSpan = 11 blocksbitcoin/bitcoin, src/chain.h
Future-block tolerance, BitcoinMAX_FUTURE_BLOCK_TIME = 7,200 seconds (2 hours)bitcoin/bitcoin, src/chain.h

Sources

This demo models the rules above; it does not read a live node. A DAA score from a real explorer or node is always the authority, not this page.