In brief
The navigation rules for moving from first contact to implementation and research edge.
Purpose And Position In The Tree#
This guide is built as a ramp. It organizes material by purpose: first contact, working model, mechanics, implementation, and research edge. A page may contain all five layers, but each layer should say what it is doing.
Reading Rule#
Start with the page that answers your immediate question, then follow the evidence. If a page says "working model", treat it as a reliable map, not as the entire implementation. If a page says "implementation", expect source paths, fields, functions, KIPs, tests, or command boundaries. If a page says "research edge", expect proposals, papers, or open questions rather than settled network behavior.
Source Rule#
For current protocol behavior, prefer Rusty Kaspa implementation, merged KIPs, release notes, and official docs. For page flow and education style, Kaspa documentation pages are useful. For papers and ZK systems, keep research or upstream-tooling claims clearly labeled. For local project lessons, keep local experience labels and route the general claim back to public sources.
Expanded Reading Method#
Read the guide as a source-backed path rather than as a flat article collection. A page marked first contact gives the handle: what the thing is, why the topic exists, and which neighboring concept comes next. A working-model page gives a practical mental model and names where that model stops. A mechanics page explains the flow of objects and evidence. An implementation page points to source files, APIs, commands, KIPs, releases, tests, or documented behavior. A research-edge page identifies papers, proposed work, open questions, and future-facing material.
The most important habit is to ask what kind of claim is being made. A concept explanation can be supported by Kaspa documentation orientation and docs. A current protocol claim needs stronger evidence, usually implementation, merged KIPs, releases, or official docs. A tooling claim can be supported by a tooling repository, but that does not automatically prove base protocol behavior. A paper explains research background. A local project lesson may be useful, but it is not public protocol authority unless it is cross-checked against upstream sources.
If a Source Notes says needs checking, do not mentally upgrade it. Treat it as an invitation to source review. If a page says proposed, do not read it as deployed. If a page says observation, ask which network, date, endpoint, software version, and source object were observed.