Builder evidence

How to prove a Kaspa builder claim

A builder claim is not a product yet. It becomes credible when a reviewer can see the status label, source, artifact, user-visible result, and blocker list.

Use this for demo proof. Use Claims Checker for protocol status. Use Reality Check for app or product pitches before they become public claims.

Proof ladder

Claim

Write the exact sentence a reader will believe or repeat.

Status lane

Label it 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 broader 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 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 reference

Browser-readable status labels for live mainnet behavior, testnet evidence, targeted upgrades, roadmap work, and research.

Claims checker

Fast route for checking whether a public Kaspa claim is live, testnet-only, targeted, roadmap, research, unsupported, or outside L1 scope.

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
Transaction payload receipts Live Transaction payload docs, accepted-transaction evidence Documented payload behavior, txid, accepting block context
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 vProgs Explained, Status, kaspanet/vprogs, technical talks Prototype repo, 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

Roadmap vProgs and oracle flows 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 Reference or read its context in Status.
  2. Check whether it is mainnet, testnet, future upgrade work, research, unsupported, or outside L1 scope.
  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. Announcement posts alone are weak evidence.

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 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.

The source trail behind Kaspa claims starts here. For protocol status, check code, releases, and primary sources in Sources. For builder tooling status, check docs.kaspa.org and rusty-kaspa.