Sources and attribution

Sources for Kaspa Explained.

This page keeps the references tidy: protocol material, technical contributor context, learning libraries, article indexes, and supporting site files.

Read claims in browser Open claims file Open LLM context Open AI guidance

Source hierarchy

Source weight.

Kaspa has many useful 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.

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

Michael Sutton, KIP discussions, technical posts, release candidates, and future activation artifacts carry timing and implementation-context claims.

Official roadmap frame

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

Learning references

Kaspa.com Learn Kaspa and KASmedia are useful for approachable vocabulary, diagrams, and topic orientation.

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.

Short version: code, releases, KIPs, research papers, and protocol docs carry mainnet-feature claims. Public explainers, media, interviews, and X posts help readers understand context and find links. Many Kaspa summaries mix live mainnet features, testnet work, third-party projects, future upgrade work, and research; this guide checks the category before repeating the claim.

What source to use

Match statements to sources.

Claim type Best source class Use with care
Live feature or activation status Code, releases, KIPs, activation records, protocol docs. Portal articles and social posts are context, not final proof.
Consensus mechanics Kaspa Research, papers, protocol docs, code, and technical contributor explanations. Simple explainers can omit assumptions or edge cases.
Toccata timing and scope Michael Sutton's Toccata outlook, KIP discussion, testnet/audit/rehearsal updates, and release artifacts. Older roadmap pages can lag the current public target window.
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 talks, technical posts, 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, not as proof that an upgrade is activated.

Code tracking

Implementation links.

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

Network access

Hosted APIs and public nodes are useful for 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, KRC20 data, 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 is useful for explaining 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 is useful as 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 is useful for recaps, interviews, and community context. Verify activation claims against primary code, KIPs, releases, or protocol sources.

Open KASmedia usage notes

Theory and consensus

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

Roadmap interpretation

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

Human context

Useful 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. Michael Sutton on Toccata for covenants, ZK verification, sequencing commitments, Silverscript, and vProgs bridge context.
  3. rusty-kaspa GitHub and rusty-kaspa releases for implementation and release evidence.
  4. rusty-kaspa Toccata branch and rusty-kaspa TN12 branch for status-sensitive implementation evidence.
  5. kaspanet/vprogs for the early Rust prototype of the vProgs execution framework.
  6. Kaspa KIPs and KIP-21 pull request for proposal status and protocol-change records.
  7. Kaspa Research on based ZK rollups for architecture context around L1-sequenced actions and off-chain execution. Treat it as design context, not production activation evidence.
  8. Kaspa Research and Kaspa Q&A for research and technical answers.
  9. Kaspa.org, Lore, Build, and HODL for the current public Kaspa/KasMedia entry point, source discovery, builder routing, and beginner wallet flow.
  10. KASmedia and Kaspa.com Learn Kaspa for community context and introductory vocabulary.
  11. Bitcoin Takeover S16 E41 transcript and full recording for explanatory framing.
  12. Kaspa: Mining the Internet, Oxford address, and Oxford Q&A for RTD and coordination-market framing.
  13. 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 app path. Use it as direction, not protocol activation evidence.
  14. Michael Sutton's vProgs talk and Sutton's milestone notes: covenant++ / vProgs, STARK-sized blocks / min-fee.
  15. Izio's Kaspa programmability guide and KASmedia fast-PoW recap for builder distinctions and fast-inclusion nuance.
  16. Bitcoin whitepaper, Ethereum scaling docs, Solana, XRPL, BNB Chain, and TRON for comparison context.

External market studies

Comparison inputs, not Kaspa evidence.

These links are useful for studying product behavior, builder funnels, wallet assumptions, and market structure on other chains. They do not prove Kaspa protocol status, roadmap timing, or activation claims.

Open external market-study sources

Public crawl map

Useful public files.

The sitemap focuses on public pages, source files, and crawler-facing context.

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