Proof of Work
A security model where miners spend real computation to propose blocks. Kaspa keeps this Bitcoin-like foundation.
Glossary
Kaspa terms in plain English.
Short definitions for Kaspa-specific terms, with links into the longer guide.
Core mechanics
Live-network terms.
UTXO
An unspent transaction output: a spendable coin chunk. Kaspa uses UTXOs; Ethereum uses account balances.
BlockDAG
A graph of blocks where multiple honest blocks can exist in parallel instead of forcing every block into one line immediately.
GHOSTDAG
Kaspa's live consensus rule for ordering the blockDAG so parallel work can contribute to consensus.
Selected parent
The chosen parent that helps define the main ordering path inside the DAG. It is not the same thing as Bitcoin's longest chain.
Mergeset
The group of past blocks a new block brings into view. It helps explain how parallel work gets folded into ordering.
Anticone
Blocks that are neither in a block's past nor its future. Anticones matter because parallel blocks need a rule for ordering.
Blue / red blocks
GHOSTDAG classifies well-connected blocks as blue and less-compatible blocks as red for ordering and security accounting.
Blue work
Accumulated proof-of-work weight through blue blocks. It is part of how Kaspa compares competing DAG histories.
Blue score
A blockDAG progress marker based on blue blocks in the selected-parent chain history. Explorers and APIs use it for ordering and range queries.
DAA score
A Kaspa progress marker used by nodes and APIs. Builders often use it for block ranges, timestamp estimates, and lock-time reasoning.
Virtual block
A conceptual current tip/state used by nodes to reason about the present view of the DAG.
Speed and storage
Scaling terms.
BPS
Blocks per second. Kaspa's 10 BPS era means faster block production, not unlimited throughput or instant finality.
Fast inclusion
A transaction gets into a block quickly.
Fast confirmation
Confidence rises quickly that the transaction will not be reversed. This is stronger than merely appearing quickly.
Finality depth
A threshold after which old history is treated as settled under the protocol's assumptions.
Pruning
Removing old block data that ordinary nodes no longer need for current validation.
Archival node
A node that preserves full historical data for explorers, audits, and historical queries.
MuHash
A compact commitment tool used around UTXO-set state and pruning safety.
Transaction mass
Kaspa's measure of transaction resource cost.
Storage mass
A cost model intended to make UTXO/state growth pay for the burden it creates.
Sompi
The smallest unit of KAS. One KAS equals 100,000,000 sompi. APIs often return amounts as strings so software does not lose precision.
Hosted API
An API run by a provider outside your own node or indexer. Useful for quick reads and prototypes; production apps need key handling, rate-limit handling, and a reliability plan.
API key
A credential sent with hosted API requests, usually in a header such as x-api-key. Keep it out of client-side code and public repos.
Rate limit
A provider rule that caps request volume. Apps should read rate-limit headers, cache stable data, batch where possible, and back off on 429 responses.
Cursor pagination
A way to fetch long lists in stable chunks. Address history endpoints use it so apps can move through many transactions without one huge response.
Accepting block
The block that accepted a transaction into ordered history. Acceptance data is useful evidence, but apps still need confirmation and reorg handling rules.
Roadmap terms
App and research terms.
Toccata
A targeted hard-fork track for spend rules, asset rules, ZK proof checks, sequencing commitments, and vProgs groundwork.
Covenant
A rule that limits how a coin or asset can be spent later. That can support vaults, escrow, and simple app state.
Silverscript
A higher-level scripting direction around Kaspa's covenant and programmable-UTXO path.
ZK verification
Checking a proof that computation was done correctly without re-running all of that computation on L1.
Sequencing commitment
A way for an app to track the activity lane it cares about, instead of forcing every proof to depend on the whole DAG stream.
vProgs
Apps that prove their own logic around Kaspa, while L1 stays focused on ordering, commitments, verification, and metadata.
DAGKnight
A parameterless/adaptive consensus research direction. It is not current mainnet behavior.
RTD
Real-Time Decentralization: Hashdag's framing for Kaspa's core edge, meaning Bitcoin-style PoW security and censorship resistance operating in real time. Oracle and TangVM ideas are downstream extensions.
Proof of Useful Work
A speculative research direction where mining work might also perform useful computation. It is not live Kaspa functionality.