In brief
Short definitions for recurring Kaspa guide terms, with links into deeper mechanics.
Purpose#
This glossary gives short, source-aware definitions for terms that appear across the guide. It is not a substitute for the mechanism pages. Each definition gives a stable handle and a go-deeper target.
Terms#
| Term | Short definition | Go deeper |
|---|---|---|
| Kaspa | A proof of work cryptocurrency network whose study path in this guide moves through blockDAG, GHOSTDAG, virtual state, and UTXO evidence. | what-is-kaspa |
| blockDAG | A directed acyclic graph view of blocks and their relationships. It is structure, not by itself the whole ordering rule. | why-blockdag |
| GHOSTDAG | The consensus mechanism studied here as the bridge from blockDAG structure into ordering and selected-parent reasoning. | blockdag-to-ghostdag-to-virtual-state |
| selected parent | The parent selected along the consensus path whose changes matter for virtual-state processing. | blockdag-to-ghostdag-to-virtual-state |
| virtual state | The consensus processing surface that turns selected-parent-chain changes into accepted data and state updates. | utxo-to-virtual-state-to-indexer |
| UTXO | An unspent transaction output: the spendable object a later transaction can consume. | where-coins-live-utxo |
| mempool | A node policy layer for transactions a node is willing to hold or relay; it is not the same as accepted transaction evidence. | accepted-evidence-vs-mempool-accepted |
| accepted transaction evidence | Consensus-visible evidence produced through virtual processing and acceptance data, not merely wallet submission. | transaction-lifecycle |
| wRPC | A Rusty Kaspa RPC surface that must be treated as an interface to source-defined objects, not protocol authority by itself. | rpc-wrpc-indexer-observation-boundaries |
| Toccata | A high-risk topic area for transaction v1, scripting, covenants, ZK, and application patterns; status labels must stay visible. | status-labels-current-proposed-historical-research |
| covenant | A script/state pattern area where successor output, covenant ID, signing context, and indexer responsibility must not be collapsed. | checking-source-claims |
| Groth16 | A ZK proof system discussed through upstream research/docs and Kaspa verifier source paths where available. | checking-source-claims |
| RISC Zero Succinct | A ZK/tooling topic that must distinguish upstream proof systems, Kaspa verifier paths, and application validity. | checking-source-claims |
| SilverScript | A tooling/source-shape topic for authoring or lowering script-like logic; it does not by itself prove base protocol readiness. | checking-source-claims |
| vProgs | A tooling/application-architecture topic that needs clear separation from base protocol behavior and production readiness. | checking-source-claims |
Expanded Glossary Method#
This glossary is not meant to compress the whole guide into one table. It gives stable handles for recurring terms, then routes the reader into mechanism pages. A good glossary entry should answer three questions: what is the term, why does it appear in Kaspa material, and which page owns the details?
Terms such as blockDAG, GHOSTDAG, selected parent, virtual state, UTXO, mempool, accepted evidence, RPC, and Toccata are easy to misuse when they are learned as isolated labels. The guide therefore treats the glossary as a map of transitions. blockDAG points to the structure problem. GHOSTDAG points to consensus reasoning. Virtual state points to accepted consequences. UTXO points to spendable state. RPC and indexers point to observation boundaries. Toccata, covenants, ZK, SilverScript, and vProgs point to status-sensitive topic pages.
If a definition needs exact source behavior, keep the short definition conservative and follow the deeper page. The glossary should help a reader ask the next precise question; it should not pretend that a one-line definition closes implementation details.
A useful way to use this page is to cluster terms before going deeper. Read proof of work, blockDAG, and GHOSTDAG together when learning consensus shape. Read transaction, mempool, accepted evidence, and UTXO together when learning value movement. Read RPC, wRPC, API, explorer, and indexer together when learning observation boundaries. Read Toccata, covenants, ZK, SilverScript, and vProgs together only after checking status labels, because those terms often mix current source, docs, proposals, tooling, and local experience.