Builder evidence

How to prove a Kaspa builder claim.

A builder claim needs a status label, a source, an artifact, a user-visible result, and a blocker list before it becomes product copy.

Status-sensitive page. Last checked: May 15, 2026. Use current status before quoting Toccata, vProgs, DAGKnight, KRC, native DeFi, or finality claims.

Proof ladder.

Claim

Write the exact sentence a reader will believe or repeat.

Status lane

Label it live, ecosystem-live, testnet-only, targeted, roadmap, research, wrong, or unsupported.

Source

Point to the strongest available source for that lane.

Artifact

Name the txid, branch, release, KIP, demo, indexer result, or command output.

User-visible result

Say what a wallet user, builder, miner, or operator can actually observe.

Remaining blocker

List what still prevents a stronger public claim.

Evidence lanes.

Kaspa claims split into mainnet features, near-term upgrades, and early design work. Each lane needs a different proof level.

Keep builder tooling, open code, and mainnet activation separate. They are three different states.

Advanced state-transition proof note

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.

Start here for verification.

Status page

Compact shipped-vs-roadmap status with a code-grounded implementation evidence section. Covers covenants, Toccata, vProgs, Crescendo, DAGKnight, and common misconceptions.

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

Reference file for status-sensitive Kaspa statements. Each entry links to evidence or source context.

llms.txt

Source pack for model context. Use it with the sources, status page, and claims file before asking technical questions.

Builder categories and their evidence sources.

Show verification links
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 paths 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
TN12 covenant proof lab Testnet only TN12 covenant vault demo, results explorer, playground Accepted TN12 records show testnet money movement, app receipts, replayed balances, blocked actions, and explicit mainnet blockers. Use the linked lab for exact txids, payload counts, and reducer artifacts.
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
Scaling beyond Crescendo 10 BPS Roadmap / research-dependent 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 paths.

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 support markets where strangers agree on rules before trusting each other, for prediction, funding, or work.

How to check a claim.

  1. Find the claim in CLAIMS.yml or read its context in Status.
  2. Check whether it is mainnet, testnet, future upgrade work, third-party ecosystem work, or research.
  3. Follow the source link to primary material: code, releases, KIPs, papers, or core contributor posts.
  4. For builder tooling vs. mainnet status: check rusty-kaspa releases for code availability and docs.kaspa.org for official builder guidance.
  5. 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 support 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.