Sources and attribution

Sources for Kaspa Explained

A source list should show how a claim was built. Start with protocol material, then technical contributor context, learning libraries, article indexes, and claim-checking pages.

Read claims in browser Check a claim Open status

Source hierarchy

Source weight

Kaspa has many public contributors. This map separates code, KIPs, releases, research papers, protocol documentation, core technical commentary, long-form context, learning libraries, and discovery channels.

Mainnet feature sources

rusty-kaspa, releases, KIPs, protocol documentation, and activation records anchor claims about what users can actually do today.

Current L1 readouts

Mainnet REST endpoints, your own node, release notes, and emission schedule documents carry time-stamped supply, reward, DAA, and activation-status checks.

Consensus / protocol sources

Kaspa Research, papers, protocol docs, code, and direct technical explanations carry claims about GHOSTDAG, blockDAG ordering, pruning, and security assumptions.

Roadmap / Toccata sources

Kaspa.org Build, kaspanet GitHub KIP PRs, Rusty Kaspa releases, testnet releases, protocol docs, and future activation artifacts carry L1 status claims. Core technical posts explain rationale but do not replace activation evidence.

Official roadmap frame

Use Kaspa.org Lore and Build for current public framing: real-time decentralization, Toccata, DAGKnight, 2027 research, and builder resource routing.

Origin and fair launch

Kaspa.org, Hashdag archives, the April 2021 launch article, Yonatan interviews, and Rusty Kaspa releases anchor the fair-launch and Crescendo history.

Learning references

Use Kaspa.com Learn Kaspa and KASmedia for approachable vocabulary, diagrams, and topic orientation. L1 activation authority comes from releases, KIPs, node/API readings, and activation evidence.

Media / context

Bitcoin Takeover, Oxford, long recordings, transcripts, and interviews help with framing, history, and community interpretation.

Discovery-only sources

X posts, replies, dashboards, and aggregators can surface links or corrections. Mainnet feature claims need stronger evidence.

Summary: first-party code, releases, KIPs, Kaspa.org/docs, public node/API readings, research papers, and activation records carry mainnet-feature claims. Public explainers, media, interviews, external docs, and X posts help readers understand context or find links. They do not activate protocol status.

What source to use

Match statements to sources

Claim type Best source class Use with care
Origin and fair-launch history Kaspa.org genesis/fair-launch proof, Hashdag launch-plan archives, durable interviews, and release records. Community lore can help, but dates, bug details, and business-plan claims need source-backed wording.
Live feature or activation status Code, releases, KIPs, activation records, protocol docs. Portal articles and social posts provide context. Final proof needs primary evidence.
Current L1 snapshot Mainnet node/API readings for network name, DAA score, block count, supply, reward, fees, and hashrate, checked against release and activation records. Snapshot values are time-sensitive; recheck before quoting exact numbers.
TPS and capacity estimates Rusty Kaspa consensus params, transaction mass code, standard transaction policy, payload docs, and current block-rate status. State the workload first: simple payments, covenant transactions, ZK settlements, token rules, and vProg-style app actions are different measurements.
Emission and supply Official emission schedule, block-reward endpoint, supply endpoint, and node/explorer cross-checks. A monthly step-down schedule should not be rewritten as a one-day cliff.
Price, hash rate, and mining-cycle claims Time-stamped market data, network hash-rate estimates, Kaspa API reads, emission sources, and historical hash-rate milestones. Community models can explain incentives. They should not be used as proof of future price, miner selling, or security outcomes.
Consensus mechanics Kaspa Research, papers, protocol docs, code, and technical contributor explanations. Simple explainers can omit assumptions or edge cases.
Toccata timing and scope Kaspa.org Build, kaspanet KIP PRs, Rusty Kaspa releases and testnet releases, protocol docs, audit/rehearsal updates, and activation artifacts. Core technical posts can explain intent; mainnet claims still need first-party release, KIP, node, or activation evidence.
App and project claims For L1 impact, use Kaspa transaction-payload docs, fee/reward endpoints, Rusty Kaspa behavior, and accepted transaction evidence. Project docs, token catalogs, wallets, and frontends are not first-party L1 status authority.
Official roadmap framing Kaspa.org Lore and Build for public framing around RTD, Toccata, DAGKnight, 100 BPS research, and builder resources. Roadmap framing is not activation evidence by itself.
API, indexing, and historical data Rusty Kaspa, official Build links, community API docs, public node docs, explorer/API dumps, and open indexer work. Hosted APIs can be best-effort; production systems need their own reliability plan.
vProgs and native app architecture vProgs repo, Kaspa programmability docs, Toccata KIPs, and future formal papers or implementation docs. Describe native DeFi as live only when shipped software supports it.
DAGKnight and adaptive consensus Hashdag, Kaspa Research, papers, and direct technical explanations. DAGKnight is not current mainnet behavior.
RTD framing hashd.ag/raw and Yonatan/Hashdag context for real-time PoW framing. Oracle, TangVM, and public group-commitment systems are downstream research or architecture.
Long-form interview context Bitcoin Takeover S16 E41 with Yonatan Sompolinsky for the broad PoW, Bitcoin, Kaspa, DeFi, Solana-like UX, and community-project framing. Use it for context. Upgrade activation needs release and network evidence.

Code tracking

Implementation links

These links help track development evidence. Mainnet activation still requires activation evidence.

Toccata / Silverscript

Capacity / mass

TN12 builder utilities

Use these for testnet-only covenant prototyping. A synced local node with UTXO index is the safer source for balance checks than an unsynced local node or changing explorer API. For Testnet-10 Toccata activation testing, start from the current Rusty Kaspa release tag before reusing older TN10 commands.

Builder tooling

Network access

Hosted APIs and public nodes serve demos, quick reads, dashboards, and second-source checks. KDP adds API-key access to address history, transaction acceptance data, block ranges by blue score or DAA score, node RPC proxy calls, and operational docs for authentication, data types, pagination, and rate limits.

Production systems should decide deliberately when to run their own node or indexer, when to use provider redundancy, and how to handle API keys, rate limits, request-unit cost, provider downtime, amount precision, and timestamp conversion.

Kaspa.com Learn Kaspa

Kaspa.com learning links

Kaspa.com Learn Kaspa explains the vocabulary behind Kaspa: BlockDAGs, GHOSTDAG, parents and mergesets, blue score and blue work, k-clusters, pruning, UTXO commitments, finality, transaction selection, mass, opcodes, KIPs, and node types.

Kaspa Explained uses it as a credited learning reference for vocabulary and approachable mechanics.

Kaspa.com Learn Kaspa topic map
Kaspa.com Learn Kaspa article index
  • Kaspa and the "Bitcoin Scaling Problem" - frames Kaspa's scaling answer as including parallel honest work in the DAG.
  • Pruning Depth - explains the practical retention boundary that lets full nodes manage storage while continuing to validate.
  • KIP 10 - introduces transaction introspection and arithmetic extensions as building blocks for safer script-level programmability.
  • A Guide to Learning Kaspa - organizes the concept map by foundations, data structures, GHOSTDAG mechanics, parameters, processing, and DAA.
  • KIP 20 - adds covenant identifiers so covenant chains can be tracked through UTXOs without relying on fragile prior-transaction proof patterns.
  • KIP 21 - describes partitioned sequencing commitments so ZK proof work can follow application lanes instead of one global transaction stream.
  • OpCodes - shows Kaspa script as stack-based validation rules, from basic signatures toward richer spending conditions.
  • Anatomy of a Block - breaks a block into header, transaction list, proof-of-work, DAG references, and commitment structure.
  • DAGKNIGHT - presents the parameterless/adaptive consensus direction that responds to actual network conditions with adaptive latency assumptions.
  • Smart Contracts - places Kaspa programmability on a staged path through script, KIP-10, covenants, ZK verification, and future vProgs; its chess walkthrough gives a concrete UTXO state-machine example.
  • Storage Mass (KIP-0009) - explains quadratic pricing for UTXO-set growth as a defense against state-bloat externalities.
  • Block Processing Pipeline - describes the validation pipeline from headers and bodies through virtual-state computation and pruning.
  • Past Median Time - explains how sampled historical timestamps help validate new block timestamps in a high-throughput DAG.
  • Timestamp Validation - covers future-time and past-median checks that protect chronological consistency.
  • Virtual Parents - explains how the virtual block selects parents to maintain a bounded, consistent current-state view.
  • TX Validation - separates transaction checks into isolation, header-context, and state-validation phases.
  • Coinbase Transactions - explains miner rewards, issuance, fees, validation, and maturity in the block template flow.
  • Sink Selection - describes how the virtual selected parent gives a parallel DAG a primary state reference.
  • DAA Score - explains Kaspa's block-based timing metric for difficulty adjustment and consensus windows.
  • Transaction Mass - combines compute, transient storage, and UTXO-set impact into a resource measure for high-throughput validation.
  • Virtual Block - explains the conceptual current-state block that aggregates DAG tips into a consistent network view.
  • Anticone Finalization Depth - explains when parallel paths are effectively closed enough for strong finalization confidence.
  • Blocks per Second - explains that BPS changes require proportional security-parameter scaling alongside faster block emission.
  • Mergeset Size Limit - describes the cap that keeps parallel inclusion practical for processing and storage.
  • Kaspa Cheat Sheet - provides a broad quick-reference map across consensus concepts, security, economics, and network mechanics.
  • Merge Depth Bound - explains the time boundary that prevents very old blocks from being merged in ways that threaten stability.
  • DAA Window - explains how recent blocks are sampled to keep mining difficulty responsive as hashrate changes.
  • Finality Depth - explains the point at which blocks become final enough for pruning and reorg resistance.
  • What is Kaspa? - gives the general entry frame: high-speed transactions through BlockDAG while preserving security and decentralization goals.
  • k-Cluster - explains how the best-connected subgraph helps identify blocks that fit the honest consensus structure.
  • Intro Transaction Selection - explains why Kaspa shifts from taking all ready transactions to probabilistic selection under congestion.
  • Blue Score and Blue Work - separates block counting from accumulated PoW measurement inside a DAG.
  • First Order Pruning - explains pruning old block transaction data while preserving the UTXO set needed for validation.
  • DAG Terminology - defines past, future, anticone, mergeset, and K so readers can reason about non-linear block relationships.
  • GHOSTDAG Simplified - explains how GHOSTDAG orders a DAG and classifies blocks while preserving security properties.
  • Parents vs Mergeset - clarifies the difference between direct references and consensus-relevant included blocks.
  • Second Order Pruning - explains deeper pruning of consensus data while preserving enough proofs for future validation.
  • Kaspa UTXO Model - explains spendable outputs as the foundation for ownership, validation, and pruning.
  • MuHash - explains compact UTXO-set commitments that help nodes verify state across pruning boundaries.
  • Kaspa - Linking the Body to the Header - explains Merkle and accepted-transaction commitments that bind transaction bodies to block headers.
  • Kaspa BlockDAG - introduces directed acyclic graphs as the structure that lets Kaspa represent parallel block production.
  • Archival Nodes vs Full Nodes - explains that pruned full nodes still validate consensus while archival nodes retain complete historical data.
  • Probabilistic and Deterministic Finality in Kaspa - distinguishes growing confirmation confidence from deterministic finality points used for pruning and violation detection.
  • Transaction Selection - explains the adaptive selection strategy across low, moderate, and heavy congestion.
  • K Parameter - explains K as the security parameter limiting blue anticone size in GHOSTDAG.
  • Kaspa Blue Work - Ordering pt4 - explains accumulated blue-block proof-of-work as the basis for ordering and tie-breaking.
  • Kaspa Blue vs Red - Ordering pt3 - explains which blocks contribute to the consensus structure and which are excluded from blue work.
  • Kaspa Mergeset - Ordering pt2 - explains how GHOSTDAG chooses the blocks to include beside a selected parent.
  • Kaspa Parent Chain - Ordering pt1 - contrasts Bitcoin's sequential heaviest-chain selection with Kaspa's blue-work-backed parallel integration.

KASmedia context

KASmedia context

KASmedia provides recaps, interviews, and community context. Verify activation claims against primary code, KIPs, releases, or protocol sources.

Open KASmedia usage notes

Theory and consensus

Use for GHOSTDAG, blockDAG, PoW-vs-BFT, safety/liveness, fee-market, and confirmation-time context.

Roadmap interpretation

Use for following Toccata, covenants, vProgs, ZK architecture, DAGKnight prototypes, and RTD direction.

Human context

Use for wallets, custody, point-of-sale tools, miner/device context, education projects, and user infrastructure.

Active builders to watch

Builder accounts

Builder accounts are good for discovery. They are not enough by themselves for activation dates, shipped-feature claims, or protocol guarantees.

Open builder account list

Research and protocol framing

  • Hashdag / Yonatan Sompolinsky - RTD, public group-commitment markets, MEV/oracle direction, and research links.
  • Michael Sutton - Toccata, covenants, ZK verification, sequencing commitments, vProgs, and Rusty Kaspa notes.
  • FreshAir08 - fee mechanics, pruning, throughput/TPS clarification, and research/development commentary.

Implementation and developer tooling

  • Ori Newman - Silverscript, covenant examples, Kaspa Q&A, and developer explanations.
  • Coder of Stuff - Rusty Kaspa, DAGKnight prototypes, testnet/devnet, and implementation progress.
  • IzioDev - Kasia, tooling, covenant workshops, and application-layer notes.

vProgs and application experiments

  • Hans Moog - vProgs, ZK app architecture, modular VM thinking, and execution-framework notes.
  • Eliott Mea - oracle, market-structure, and application-layer analysis.
  • KasSigner and KasSigner/KasSee - offline signing, PSKB, multisig, and hardware-wallet-adjacent experiments.

External references

External references

Open external reference list
  1. hashd.ag and hashd.ag/raw for Hashdag / Yonatan Sompolinsky's writing archive.
  2. Kaspa launch plan: responding to reality and Kaspa (Black Tuesday) for launch, governance, early bug, and UTXO-commitment context.
  3. Polychain Capital homepage for Polychain's own high-level description as an investment firm managing portfolios of blockchain assets.
  4. Hackernoon interview with Yonatan Sompolinsky for DAGLabs, ASIC-presale, optical ASIC, Polychain, Gadi, and fair-launch context.
  5. Kaspa Wiki prehistory page for DAGLabs mining after launch, Polychain-related distribution context, and the under-3% / 840 million KAS early-miner estimate.
  6. Investing.com April 2021 Kaspa launch article for the testnet bundle, DAGLabs context, and pre-mainnet no-premining launch intent.
  7. Guy Corem's April 2021 Kaspa testnet note for Golang Phantom/GHOSTDAG implementation framing and pre-mainnet context.
  8. Epicenter episode 192 and Rethink Trust 2018 interview for GHOST, SPECTRE, Layer One scalability, throughput, confirmation-speed, and trustless-design context.
  9. Uphold Institutional interview recap for sequencing, finance, MEV, Rust implementation, and ZK-oriented future-programmability framing.
  10. DBLP record for PHANTOM for the 2018 PHANTOM paper citation.
  11. Kaspalytics Week 4, 2024 for September 2023 dust-attack UTXO-count context.
  12. Michael Sutton on Toccata for covenants, ZK verification, sequencing commitments, Silverscript, and vProgs bridge context.
  13. rusty-kaspa GitHub and rusty-kaspa releases for implementation and release evidence.
  14. mainnet blockDAG API, supply API, and block reward API for time-stamped L1 snapshot checks.
  15. Kaspa Wiki tokenomics and the block reward API for monthly emission-policy and current-reward checks; use them to avoid "emission cliff" wording.
  16. Rusty Kaspa v2.0.1, Rusty Kaspa v2.0.0, and the Toccata guide for the current Toccata release line, DAA 474,165,565 activation score, and June 30 activation estimate.
  17. tn10-toc3, tn10-toc2, and Testnet-10 REST status for the May 2026 Testnet-10 Toccata activation and hardening path.
  18. rusty-kaspa Toccata branch and rusty-kaspa TN12 branch for status-sensitive implementation evidence.
  19. kaspanet/vprogs for the early Rust prototype of the vProgs execution framework, and michaelsutton/argent for actor-style Silverscript tooling research.
  20. Kaspa KIPs, KIP-16, KIP-17, KIP-20, KIP-21, KIP-24, and KIP-22 for proposal status and protocol-change records.
  21. Kaspa Research on based ZK rollups for architecture context around L1-sequenced actions and off-chain execution. Production activation needs release and network evidence.
  22. Kaspa Research and Kaspa Q&A for research and technical answers.
  23. Kaspa.org, Lore, Build, and HODL for the current public Kaspa/KasMedia entry point, source discovery, builder routing, and beginner wallet flow.
  24. KASmedia and Kaspa.com Learn Kaspa for community context and introductory vocabulary.
  25. Bitcoin Takeover S16 E41 transcript and full recording for explanatory framing.
  26. Kaspa: Mining the Internet, Oxford address, and Oxford Q&A for RTD and coordination-market framing.
  27. Kaspa Daily Yonatan Q&A Part 1 for current narrative context around Base of Liquidity, coordination markets, product-before-marketing, L1-first framing, and payments as one application route. Protocol activation claims need release and network evidence.
  28. Michael Sutton's vProgs talk and Sutton's milestone notes: covenant++ / vProgs, STARK-sized blocks / min-fee.
  29. Izio's Kaspa programmability guide and KASmedia fast-PoW recap for builder distinctions and fast-inclusion nuance.
  30. Bitcoin whitepaper and Ethereum scaling docs for stable comparison context around base-layer money and rollup-centric scaling.

Page map

Page map

Next step

Use the source guide with the right reading path

Use status for shipped-feature claims. Use the zero-start guide when a reader does not yet know the crypto machinery behind those claims.

Open status Start from zero

Keep reading

PreviousFind the right page

Search the Kaspa Explained page map by topic, audience, status, and source type.

 NextAsk about Kaspa with sources

Open ChatGPT, Claude, Perplexity, or Grok with a Kaspa prompt that checks sources, status labels, and unsupported claims.

 StatusKaspa current status

Kaspa status in plain buckets: live, targeted, roadmap, research, and claims that need caveats.