In brief
A one-page public entry path into Kaspa, from first contact through source-level study.
Purpose And Position In The Tree#
This page is the front door for the source-linked reference. It gives a complete first pass through Kaspa without forcing the reader to choose between a shallow slogan and a source-code cliff. The path is: what Kaspa is, why blockDAG exists, how proof of work and GHOSTDAG fit together, where coins live, what wallets/nodes/miners/developers each do, and how to continue into mechanics and implementation.
First Contact#
Kaspa is a proof of work cryptocurrency network whose consensus design keeps a directed acyclic graph of blocks rather than treating every simultaneously discovered block as waste. The first idea to carry forward is not "more blocks means everything is solved"; it is that parallel blocks create an ordering problem. Kaspa's source-backed study path therefore moves from proof of work, to blockDAG structure, to GHOSTDAG ordering, to virtual state, to UTXO and accepted-transaction evidence.
Working Model#
A useful mental model is a five-layer stack. Wallets construct and sign transactions. Nodes validate, relay, and maintain local views of the network. Miners work on block templates using proof of work. Consensus processes blockDAG structure and selected-parent-chain changes. Applications, explorers, and indexers observe accepted evidence and UTXO changes after protocol processing.
This model is intentionally incomplete. It does not decide every edge case, encode every consensus constant, or prove that a tool preserved every field. It tells you which page owns the next question.
Mechanics#
Kaspa's guide should be read as a set of connected questions.
First, ask what object you are looking at: a wallet action, a transaction, a block, a blockDAG relation, a virtual-state change, a UTXO diff, a script rule, a proof, or an indexer observation. Second, ask what status label belongs to the claim: current, proposed, historical, research, local experience, or needs checking. Third, ask which source class can close the claim. Current protocol behavior needs implementation, merged KIPs, releases, or official docs; Kaspa documentation pages help with orientation and teaching flow; papers explain research background; local project experience must stay labeled.
Paths Through The Guide#
| Need | Start with | Then read |
|---|---|---|
| Understand Kaspa in one sitting | What Is Kaspa | Why blockDAG, proof of work to GHOSTDAG, UTXO |
| Send, receive, or operate | Wallet, node, miner, developer paths | Wallet roundtrip evidence, node/miner template evidence |
| Understand transaction evidence | Transaction lifecycle | Accepted evidence vs mempool accepted, block added vs transaction accepted |
| Study consensus | Why blockDAG | blockDAG to GHOSTDAG to virtual state, core protocol source paths |
| Study Toccata/covenants/ZK | Status labels first | Toccata application lifecycle, topic guides, Open Questions, and source paths |
| Contribute to the publication | Checking Source Claims | Claim closure lanes and site status |
Expanded Educational Walkthrough#
The shortest useful way to enter Kaspa is to keep three questions separate. The first question is network identity: Kaspa is studied here as a proof of work cryptocurrency network. The second question is structure: the guide introduces blockDAG because the page path must have a place for valid blocks that appear close together. The third question is evidence: a transaction is not treated as complete just because one interface showed it. The guide therefore follows the evidence path from wallet action to accepted data and UTXO consequences.
The first-contact model is intentionally compact, but it should not be mistaken for a slogan. Proof of work explains how miners compete to produce valid blocks. blockDAG explains why nearby blocks remain visible as graph structure. GHOSTDAG explains why the graph still needs consensus ordering. Virtual state explains where selected-parent-chain consequences become accepted data. UTXO explains the spendable objects transactions consume and create. RPC, wRPC, explorers, and indexers explain observation surfaces, not independent protocol authority.
When a page later discusses Toccata, covenants, ZK, SilverScript, or vProgs, read the status label first. Those topics can contain a mixture of current implementation, official docs, KIP/proposal text, research background, tooling behavior, local experience, and Open Questions. The guide is useful only if those categories stay separate.
