Kaspa Glossary: Complete Guide to BlockDAG Terms

Accepting Block

From the point of view of a transaction, an accepting block is the block that merges a given transaction into the Virtual Selected Parent Chain (VSPC). Transactions are considered accepted once merged into VSPC by a chain block. Technically speaking, chain blocks do not merge transactions directly. Rather, chain blocks merge blocks. As a result, transactions inherit their containing block’s acceptance status (and accepting block). Additionally, the accepting block of a transaction is used to determine the number of confirmations.

Anticone

The anticone of a given block, say block block B, are blocks that are neither in B’s past nor future. Anticone is a BlockDAG concept. Understanding the past and future of a block helps conceptualize anticone. Blocks that are reachable from B are B’s past. Blocks that B is reachable from are B’s future. Blocks in B’s anticone have ambigious ordering relative to B. Blocks in the anticone are often the result of concurrent creation or P2P block propagation timing. Anticone is a critical component of GHOSTDAG’s block coloring mechanism.

Blue Block

A well-connected block likely mined by an honest node. Blocks are either classified as blue or red by GHOSTDAG’s block coloring mechanism. A block is classified as blue if the number of blue blocks within it’s anticone is within the k parameter bound. Blue blocks count towards Blue Score, Blue Work, and pay the miner of the given block, among other things.

Blue Score

The number of blue blocks in a given block’s past. Blue score is calculated by summing the selected parent’s blue score and the number of blue blocks in the given block’s mergeset. Stored in the block’s header, blue score can be thought of as the “weight” of a block’s history within the honest portion of the DAG. Blue score contributes to several mechanisms in Kaspa - including DAA score and difficulty adjustment.

Reference: Blue Score & Blue Work (KaspaCom)

Blue Work

Blue work is the cumulative proof-of-work of all blue blocks in a block’s past. Effectively measuring the total computational effort (sum of difficulty values) of the blue set at a given block. Red blocks are excluded from the calculation. Tip selection and parent selection are based on blue work, highlighting the importance of blue work in consensus and security.

Reference: Blue Score & Blue Work (KaspaCom)

Chain Block

Chain blocks are a subset of dynamically chosen, special blocks within Kaspa’s BlockDAG. Conceptually, chain blocks form a backbone throughout the DAG, merging other blocks into this backbone. Formally this backbone is called the virtual selected parent chain (VSPC). Each chain block merges blocks into the VSPC, known as a mergeset. In Kaspa’s BlockDAG, blocks can have multiple parents. The parent block with the highest blue score is selected as the selected parent. Chain blocks play a critical role in block and transaction ordering.

Child Block

Child blocks are blocks which directly reference the given block. Using block B as an example, B’s children are blocks which directly reference B in their header. This reference is stored in the block’s parents field. Child blocks are part of a block’s future.

Confirmation Count

Confirmation count is the number of confirmations a transaction has on the network. Approximately speaking, confirmation count increases as blocks are mined in the future of the transaction’s containing block. Anticone blocks do not increase confirmation count.

Confirmation count = Sink Blue Score - Transaction’s Accepting Block’s Blue Score

Crescendo Hard Fork

The Crescendo Hard Fork was activated at DAA score 110,165,000 on May 5 2025. While the primary change was moving from 1 Block Per Second (BPS) to 10 BPS, Crescendo brought many supporting features and changes to Kaspa mainnet, as well as some unrelated changes. The crescendo hard fork is detailed in KIP-0014.

Reference: KIP-0014

Block Coloring

PHANTOM GHOSTDAG classifies all valid (valid from a structural and PoW perspective) blocks as Red or Blue. Where color generally indicates how well connected a given block is in the DAG. A block's color then dictates it's role in consensus mechanisms, security, block rewards, etc.

Blue Set

The Blue Set is the set of blue blocks included in the maximum k-Cluster. This set represents the largest well connected subset of honest blocks in the BlockDAG.

Compute Mass

A measure quantifying the computational cost of a transaction. Compute mass is a calculation over various transaction components, where each component carries a different weight. For example, signature operations are a heavily weighted component. Resulting in a multi-sig transaction having a larger computer mass than a single signature transaction.

DAA Score

DAA score is the number of blue blocks + merged & rewarded red blocks. This formula accounts for all rewarded blocks in the network, providing a comprehensive measure of progress. DAA Score increases at roughly the number of blocks per second. At Kaspa’s current target BPS of 10, DAA score increaseby roughly 10 per second. DAA Score is used in network events/upgrades (e.g. the Crescendo hard fork was activated at a DAA Score of 110,165,000), timestamp estimation, certain transaction lock times, and more.

DAG

A Directed Acyclic Graph (DAG) is a graphical representation of a series of activities. A data structure in which nodes (vertices) are connected by directed lines (edges). The directed edges dictate the flow from one node to another. The graph is “acyclic” - there are no loops or cycles in the graph. It is impossible to start from a node and return to the same node by following edge directions.

Reference: Directed Acyclic Graph

Deterministic Finality

A type of finality in which a transaction’s status is guaranteed to never change.

Reference: Finality (KaspaCom), Probabilistic and Deterministic Finality in Kaspa (KaspaCom)

Difficulty

Difficulty is a numerical value representing how “challenging” mining is or was at a given point in time, relative to the maximum target. The maximum target is a hardcoded value in rusty-kaspa that represents the easiest possible mining.

Formally, difficulty is derived from target: difficulty = MAX_DIFFICULTY_TARGET / target

Where target in the calculation above can be either the current target (virtual’s bits field) or the target of an already mined block (from the block header’s bits field).

Difficulty Adjustment Algorithm

The algorithm which adjusts mining difficulty on the Kaspa network. Mining difficulty is adjusted to ensure actual block production rate remains at approximately the desired rate. Current target block rate is 10 blocks per second. Formally, the difficulty adjustment algorithm adjusts the target, rather than a literal “difficulty” variable. The difficulty value is then derived from target.

Prior to the Crescendo hard fork, a full sliding window approach was used to calculate difficulty every 1 block (~1 second). This legacy approach is referred to as Full Window in the rusty-kaspa codebase and remains in the codebase for backwards consensus compatibility. Window size for the Full Window approach is 2641 blocks, which is approximately 44 minutes. Roughly speaking, the most recent 2641 blocks were inspected every 1 second to recalculate target. With the goal of ensuring block production rate was approximately 1 block per second.

As part of the Crescendo hard fork, KIP-0004 was activated, changing difficulty adjustment to the current Sampled Window approach. While the full window approach includes every block in the window in its calculation, the sampled window approach includes blocks at a fixed interval within the sliding window. This approach was introduced to reduce overhead of the difficulty adjustment process, allowing it to scale with increased block rate of 10 BPS introduced by Crescendo. Under the sampled window approach, blocks within the 2641 second sliding window are sampled at a fixed interval of approximately 4 seconds. Though sampling is based on DAA score, not clock time, “approximately 4 seconds” is used here for simplicity. This effectively produces a set of approximately 661 blocks from the prior 2641 seconds with an approximate 4 second interval in between each block. This sample of approximately 661 blocks is maintained and used to calculate target with the goal of ensuring current block production rate remains at 10 BPS. Additionally, Crescendo effectively divided difficulty by a factor of 10 (by multiplying target by a factor of 10) at activation to recalibrate for target block production of 10 BPS.

Effective TPS (e-TPS)

A measure of DAG capacity utilization relative to the number of available transactions in the mempool. A max value of 1.0 (100%) indicates DAG throughput is handling current demand. While a value of 0.0 (0%) indicates DAG capacity is largely filled with duplicate transactions, even though the mempool has a much larger number of unique transactions available for inclusion.

Reference: e_tps in rusty-kaspa

Fee Rate

Fee rate is a multiplier used to calculate the fee of a transaction. Kaspa nodes provide an RPC method GetFeeEstimate that returns three fee rate buckets:

Priority: an estimation of the feerate required for sub-second DAG inclusion
Normal: an estimation for sub-minute DAG inclusion
Low: an estimation for sub-hour DAG inclusion

Fee rate values are in sompi, representing the estimated fee (in sompi) per gram (unit of transaction mass). As such, a transaction’s fee can be calculated using: desired fee rate bucket * mass of the transaction.

Reference: RpcFeeEstimate struct in rusty-kaspa

Finality

The point at which a transaction is “considered” irreversible. “Considered” can be defined as a probability (Probabilistic Finality) or a guarantee (Deterministic Finality). The type of finality depends on the given network. Technically speaking, this is the point at which a block’s position in the chain/DAG/etc. is considered final. Meaning a reorg affecting this block is (extremely) unlikely, or is guaranteed not to happen. Again, depending on the type of finality used by the given network. In PoW systems like Bitcoin and Kaspa, probabilistic finality is the natural byproduct of PoW based consensus. Though Kaspa employs the additional concept of Finality Depth to secure the pruning process. Finality Depth provides deterministic finality to transactions on the Kaspa network.

Reference: Finality (KaspaCom), Probabilistic and Deterministic Finality in Kaspa (KaspaCom)

Finality Depth

The point after which blocks and their contained transactions on the Kaspa network become deterministically final. Up until the finality depth, finality on the Kaspa network is probabilistic. It is possible (though extremely unlikely), that a reorg could affect the status of a block/transaction until it reaches the finality depth. Kaspa’s current finality depth is approximately 12 hours. Prior to Crescendo hard fork, finality depth was 24 hours.

Reference: Finality (KaspaCom), Probabilistic and Deterministic Finality in Kaspa (KaspaCom)

Future

The future of a block, say block B, are blocks that B is reachable from. This can be via direct or indirect reference. Where direct references are children that reference B in their header. Indirect references are blocks that do not directly reference B in their header, but are able to reach B by following edges. Future blocks are provably created after the given block.

Hash Rate

Hash rate is a measure of total computational power mining on the network. It is the rate at which miners of a network generate hashes while attempting to mine blocks. Kaspa’s hash rate can be calculated using network difficulty * 2 * blocks per second.

Hash rate is commonly expressed in the following units:

H/s - Hash per Second (1 hash per second)
kH/s - Kilo Hash per Second (1,000 hashes per second)
MH/s - Mega Hash per Second (1,000,000 hashes per second)
GH/s - Giga Hash per Second (1,000,000,000 hashes per second)
TH/s - Tera Hash per Second (1,000,000,000,000 hashes per second)
PH/s - Peta Hash per Second (1,000,000,000,000,000 hashes per second)
EH/s - Exa Hash per Second (1,000,000,000,000,000,000 hashes per second)

k-Cluster

Generally, a k-cluster is a subset of the BlockDAG where every block has a clear ordering relationship with almost all other blocks in the subset. The number of blocks (within the same subset) that a block has unclear ordering relationship with is limited to the k parameter. These are often concurrently created blocks. More formally, the k-cluster is a subset of the DAG where no block in this subset has an anticone larger than k, where all anticone blocks are within the same subset.

k Parameter

The k parameter is the number defining the maximum anticone size for inclusion in a k-cluster. Where counted anticone blocks are blocks within the same subset.

Lock Time

Lock time is an optional transaction field that specifies the earliest time or DAA score at which a transaction can be included in a block. A value of 0 means the transaction is eligible for immediate inclusion. A value below 500 billion represents the minimum DAA score at which a transaction can be included. A value of 500 billion or above represents the minimum Unix timestamp in milliseconds at which a transaction can be included.

Mergeset

The set of blocks that a given block has merged into the DAG. These are blocks in the past of the given block, but not in the past of it’s selected parent.

Parent Blocks

In PHANTOM GHOSTDAG , blocks can have multiple parents referenced in the parents field of the block header. When a block is mined, all known DAG tips are referenced as parents.

Past

The past of a block, say block B, are all blocks reachable from B. Past blocks can be referenced directly, in B’s header. These are direct parents. Or indirectly, where B does not reference the past block in B’s header, but the past block is reachable from B by following edges between blocks.

Probabilistic Finality

A type of finality in which the probability of a transaction reversal decreases exponentially as subsequent blocks are mined. Every subsequent block mined decreases the likelihood of a (natural or malicious) reorg affecting a transaction's containing block. The decreased likelihood results from the exponential increase in required work for an attacker to revert status that each additional block creates. While probability never reaches 0, it quickly becomes extremely unlikely.

Reference: Finality (KaspaCom), Probabilistic and Deterministic Finality in Kaspa (KaspaCom)

Pruning

Kaspa nodes by default prune data older than (approximately) 30 hours. This is done to reduce node storage requirements. Which in turn lowers node hardware requirements, promoting decentralization. Block data, including transactions and headers, are pruned. The UTXO set is retained completely and contains all data required for transaction validation. The specific block in the DAG at which all earlier data is pruned is known as the pruning point. Kaspa nodes can be ran in archival mode, where pruning does not occur. Or with an optional parameter specifiying data retention.

Red Block

Red blocks are blocks in the DAG which are not well connected. A block is red if the number of blue blocks in it’s anticone is larger than the k parameter. Red blocks are valid as they meet proof of work requirements. However, Kaspa’s consensus mechanism penalizes creation of red blocks. Red blocks are merged into the DAG, but rewards are not paid to the red block miner. Instead, rewards are paid to the miner of the merging blue block. In some cases, rewards are not paid for red blocks at all.

Selected Parent

In PHANTOM GHOSTDAG , blocks are mined referencing all known DAG tips. This often results in a block having multiple parent blocks. From all parent blocks, one block is chosen as the Selected Parent. Formally, the selected parent is the parent block with the highest Blue Work.

Selected Tip

Selected tip is last block of the VSPC. Selected tip is chosen based on the largest the virtual block’s selected parent.

Sink

The selected parent of the virtual block. Effectively, sink is the same as selected tip.

Reference: get_sink in rusty-kaspa

Storage Mass

Defined in KIP-9, storage mass is a mechanism that helps regulate growth of the UTXO set. From a (very) high level, transactions that create many UTXOs, or dust UTXOs, will carry a higher storage mass.

Target

A numerical value representing the upper limit of an acceptable hashed block header value for mining. To mine a block, a miner must hash a block header using kHeavyHash, changing the block header’s nonce until the resulting hash numerically is less than or equal to the target. When a nonce is found that satisfies this requirement, the block will be accepted (assuming all other consensus & structural block requirements are met) by the network.

Target is a dynamic value that changes via the Difficulty Adjustment Algorithm to ensure actual block production rate remains at approximately the desired rate, which is currently 10 BPS. Target has an inverse relationship with difficulty. As difficulty increases, target decreases; and vice versa.

Target is directly adjusted by difficulty adjustment algorithm every 100 milliseconds. The new target is then stored in virtual’s bits field in compact representation. Virtual’s bits field is then used to populate bits on the block template provided to miners. When a block is mined, the given block header’s bits field holds that block’s target. Difficulty is then derived from the target.

Tips

Tips are blocks in the DAG that do not have children blocks. Formally defined in PHANTOM GHOSTDAG as “the set of blocks with in-degree 0 (usually, the most recent blocks).” Tips can be thought of as the most recent edge or frontier of the DAG. Honest miners reference all known tips while mining.

Transient Mass

Defined in KIP-13, transient mass helps control overall block size. Transient mass is equal to the serialized size of a transaction multiplied by 4. Since blocks are constrained to 500,000 mass, and target block size is 125KB, the factor of 4 was selected (500,000 mass / 125,000 bytes = 4 mass per byte.)

Unique Transaction

In Kaspa’s BlockDAG, the same transaction can be included in multiple blocks. For that reason, many metrics are based on unique transactions. Specifically, the same transaction that appears in multiple blocks is considered one unique transaction.

Unique TPS (u-TPS)

The number of Unique Transactions per second.

Virtual Block

Often referred to as just “virtual”, the virtual block is a conceptual, non-existing block. Virtual points to all DAG tips (known by the local node) as its parents. It can be thought of as an un-mined block, the next block to be mined. However, virtual is not a full block template - it does not contain transactions, among other required block data. Virtual’s GHOSTDAG data is inherited by the block template.

Virtual Selected Parent Chain (VSPC)

Conceptually, the Virtual Selected Parent Chain (VSPC) is a chain of blocks which form a backbone through the DAG. Each block in the VSPC is a chain block. Given that chain block status is dynamic, the VPSC inherits this dynamic property. Each chain block merges other blocks into the VPSC, formally known as the block’s mergeset. The mergeset includes blocks in the past of given chain block B, but not in the past of B’s parent. The VSPC plays a primary role in transaction acceptance, block and transaction ordering.