Status page
Compact shipped-vs-roadmap status with a code-grounded implementation evidence section. Covers covenants, Toccata, vProgs, Crescendo, DAGKnight, and common misconceptions.
Builder evidence
Where to find proof for Kaspa builder claims.
This page bridges Kaspa Explained and technical proof. It is not protocol authority by itself. It points you to evidence, status boundaries, and source files so you can verify claims before building.
What this page does.
Kaspa Explained separates live, targeted, roadmap, and research claims. This page shows you where each category lives and how to find proof.
For state-transition proof models, the useful pattern is selected-parent root plus current root plus leaf write witnesses. That keeps validation local to the transition instead of forcing clients to maintain the whole incremental SMT.
- Live: code merged, activated on mainnet, available to builders now
- Targeted: scheduled for near-term release or being implemented
- Roadmap: architecture approved or research-backed, not yet scheduled
- Research: in exploration, no timeline or approval yet
Builder evidence helps you avoid mixing builder tooling, open code, and mainnet activation—three different states that often get confused.
Start here for verification.
Sources & Reference Map
Public source hierarchy: protocol sources, core technical contributors, Kaspa.com Learn Kaspa, KIPs, research papers, and supporting site files for claim verification.
CLAIMS.yml
Lightweight status ledger for sensitive live/targeted/roadmap/research claims. Each claim links to evidence or source context.
llms.txt
Source pack for AI models. Use this prompt in your favorite LLM to get Kaspa Explained as context before asking technical questions.
Builder categories and their evidence sources.
Expand evidence map
| Feature / Claim | Status | Where to verify | Evidence type |
|---|---|---|---|
| Fast Proof-of-Work ordering (10 BPS) | Live | Status, live mainnet, wallets, block explorer | Live activation, transactions, mining history |
| UTXO model, self-custody | Live | Status, docs.kaspa.org, SDKs | Protocol specification, SDK implementation |
| Receipt and transfer rails | Live | Status, block explorer, wallet indexers | Live protocol, working wallets, indexer code |
| KRC20 tokens / KRC721 NFTs | Live ecosystem | Builder Guide, explorer, open community repositories | Community implementations, token registries, examples |
| Covenants (after Toccata) | Targeted | Status, rusty-kaspa, Toccata PR/release timeline | Code in branches, release schedule, KIPs |
| Vault rules, escrow, spend limits | Targeted (Toccata) | Builder Guide, Toccata covenant documentation | Covenant design docs, examples in progress |
| Proof verification hooks | Targeted (Toccata) | Status, Toccata specification | Protocol specification, proof design documents |
| Inline ZK verification | Targeted | Builder Guide, Status | Protocol specification, research papers |
| Full vProgs (app-specific execution) | Roadmap | Status, research.kas.pa, technical talks | Research papers, architecture documents, talks |
| Crescendo (scaling) | Roadmap | Status, research materials, talks | Research documents, protocol vision |
| DAGKnight (ordering improvement) | Research | Status, academic papers, protocol research | Research papers, proof-of-concept implementations |
| Coordination markets, oracle flows | Research | Application Layer, Status | Design documents, research directions |
Public builder rails (what to build around).
These are the concrete Kaspa capabilities builders can rely on for product decisions:
Vault and escrow
After Toccata, covenant rules let you build vaults and escrow that enforce spending limits or unlock conditions without trusting a server.
Receipts and proof of payment
Fast inclusion and ordered history mean receipts settle quickly and can be verified on-chain. Indexers and APIs let you query proof of a payment.
Assurance contracts
After Toccata, simple contracts can enforce group commitments: "if N people agree, do X; otherwise, refund everyone."
Coordination markets
Future vProgs and oracle flows may enable markets where strangers can agree on rules before trusting each other, for prediction, funding, or work.
How to check a claim.
- Find the claim in CLAIMS.yml or read its context in Status.
- Check the status label: live, targeted, roadmap, or research.
- Follow the source link to primary material: code, releases, KIPs, papers, or core contributor posts.
- For builder tooling vs. mainnet status: check rusty-kaspa releases for code availability and docs.kaspa.org for official builder guidance.
- For roadmap claims: look for architecture documents or research direction, not announcement posts alone.
Related pages.
Builder Guide
Programmability choices: covenants, based apps, inline ZK, vProgs, SDKs, and infrastructure evidence.
Application Layer
Status-labeled map of what builders can use now and what Toccata, vProgs, and research may enable later.
Status
Shipped-vs-roadmap status with implementation evidence for features, activation dates, and common misconceptions.
Sources & Reference Map
Full source hierarchy and external reference map for protocol sources and builder resources.
This page does not make Kaspa claims authoritative. It points you to places where claims are sourced. For protocol authority, check code, releases, and primary sources in Sources. For builder tooling status, check docs.kaspa.org and rusty-kaspa.