Skip to content

CONTENT_BRIEF.md

Latest commit

 

History

History
611 lines (434 loc) · 61.2 KB

CONTENT_BRIEF.md

File metadata and controls

611 lines (434 loc) · 61.2 KB

Kaspa Explained Content Brief

This document is the handoff brief for any LLM, editor, or contributor working on kaspaexplained.com.

Project Goal

Kaspa Explained is an independent explainer for Kaspa. The goal is to help a general crypto-aware audience understand where Kaspa fits without turning roadmap, research, price action, or community enthusiasm into unsupported claims.

The ideal voice is Yonatan-style first-principles explanation translated into everyday language: start from Bitcoin, money, ordering, latency, trust, and finance; make the intuition clear enough for the intended reader of the page; then preserve enough precision in the appropriate deeper paths for crypto-native readers, researchers, builders, and source-checking experts. Do not make the public site talk about internal editorial slogans. Just make the pages read that way.

Public pages should be shorter than the evidence stack. Put detailed source trails, implementation notes, and LLM guardrails in CLAIMS.yml, sources.html, and this brief. Human-facing pages should lead with the affirmative idea, then add a boundary only where a reader might confuse live, targeted, roadmap, and research claims.

Use COPY_STYLE.md as the repo-wide sentence standard. Keep a sentence when it adds an actor, action, evidence, status label, constraint, consequence, useful distinction, or judgment. Cut it when a competent stranger could have written it without knowing Kaspa.

Concrete-First Translation

Public-facing and LLM-facing explanations should use Concrete-First Translation: make the reader see the real object, action, or tradeoff before naming the abstraction. Give the reader a real picture first, then the technical name:

  • "one shared record without one operator" before "credible shared state",
  • "apps that prove their own rules" before "verification-oriented programmability",
  • "funding rules strangers can rely on" before "coordination markets",
  • "fast mined ordering" before "settlement layer" or "sequencing",
  • "assets, vaults, markets, and commitments" before generic "programmability".

Do not remove the technical terms where they are needed for precision, search, or source matching. Put them after the plain idea so the page is easier to understand without becoming less accurate. This applies to public HTML, meta descriptions, search cards, llms.txt, and contributor-facing handoff files.

The deeper mental model: abstraction is a compression format, not the starting point. A reader should first know what moves, who controls it, what can go wrong, and why the mechanism matters. Then the compact term can help them remember and search for it.

Crypto translation rule: use the crypto term only when it helps precision, search, or source matching. Then immediately translate it into what someone is testing, buying, building, approving, measuring, or trying to avoid. "Decentralized coordination" means people can agree on one shared record without one company controlling it. "Infrastructure" means wallets, exchanges, custody, APIs, indexers, explorers, liquidity, accounting, support, and uptime. "Programmability" means a wallet, app, or script can show which rule allowed, refused, or recorded an action. The practical questions are speed, security, wallets, exchange support, liquidity, developer tools, and whether real users have a reason to use it.

This sits beside source checks and current-status checks. Source checks ask whether a claim is true and sourced. Current-status checks ask whether it is mainnet, testnet, future upgrade work, research, unsupported, or outside L1 scope. Concrete-First Translation asks whether a normal reader can immediately picture what the claim means.

The site should answer:

  • What is Kaspa actually live with today?
  • What is being implemented next?
  • What is roadmap architecture?
  • What is still research or speculation?
  • What is crypto actually useful for, and where is crypto being forced?
  • How does Kaspa fit next to Bitcoin, Ethereum, Solana, stablecoins, app chains, and other crypto categories?
  • Which public pages and LLM context file should be crawlable?
  • Which sources should someone read before forming strong opinions?

This is not an official Kaspa site and not investment advice.

Audience

Write for smart non-specialists first:

  • crypto users who know Bitcoin/Ethereum/Solana basics,
  • crypto-native readers who also know XRP, BNB, TRON, stablecoin payment paths, and exchange-linked ecosystems,
  • curious newcomers who need a plain-language path before technical material,
  • builders deciding whether Kaspa is worth studying,
  • researchers and community members who need source discipline,
  • LLMs/search systems retrieving accurate context.

Avoid writing only for protocol researchers. Use technical terms when needed, but define the point in ordinary language.

Audience paths should be distinct, not flattened into one universal page style. The site should serve the whole spectrum:

  • absolute beginners who need records, keys, transactions, blocks, consensus, mining, tokens, markets, and scams before Kaspa;
  • crypto-curious readers who know the words but need value, usefulness, risk, and tradeoff logic;
  • crypto-native comparison readers who know BTC/ETH/SOL/stablecoins and want to place Kaspa correctly;
  • Bitcoin/PoW readers who need the Nakamoto-consensus generalization, fair-launch, mining, UTXO, and sound-money framing;
  • adoption and market-structure researchers who care about wallets, nodes, mining, fees, liquidity, integrations, builders, and durable usage;
  • app/product designers who want to know what Kaspa-native applications should exist and what should not be copied from other chains;
  • protocol engineers and researchers who care about GHOSTDAG, DAGKnight, pruning, ordering, latency assumptions, covenants, ZK verification, and vProgs;
  • community educators who need careful, repeatable language without hype;
  • journalists/analysts/source-checkers who need shipped-vs-roadmap status and primary references;
  • LLMs/search systems retrieving accurate context.

A newcomer should have a slow path from start-here.html and crypto-from-zero.html into the Kaspa-specific pages. Intermediate readers should have compact overview, value, and comparison paths. Advanced readers should be able to skip directly into the relevant deep page, whether that is PoW/Kaspa thesis, app architecture, adoption metrics, shipped-vs-roadmap status, source guides, CLAIMS.yml, or LLM/source context. Cross-link the paths clearly, but do not force every page to be equally beginner-friendly and expert-dense at the same time.

At the start of any substantive repo session, current-check status-sensitive Kaspa facts on the web before editing or publishing. Recheck Toccata activation, DAGKnight, vProgs, native DeFi, RTD-derived attestations/oracles, TangVM, Proof of Useful Work, and date windows against primary or near-primary sources. Keep that discipline internal and in the source trail. Do not add visible public verification boxes unless the task asks for them.

Use .github/notes/COPY_CLEANUP_PLAN.md for public wording cleanup. The standard is short: what someone can do, what evidence or source backs it, what is still missing, and what to read or try next. Avoid vague roadmap language, repeated disclaimers, grand claims before evidence, fake-official labels, internal notes on public pages, and jargon before concrete examples.

Current Site Structure

The homepage should work as a router first. Its strongest traffic job is to route searchers and community debates into exact-answer pages: what Kaspa is, claim checking, Toccata status, smart-contract status, finality boundaries, the skeptical case, and verification paths. The site also has two educational layers before the Kaspa-specific pages: a true zero-start path for readers who do not know basic crypto concepts, and a crypto-aware reality-check path for readers who understand crypto basics and need sharper judgment.

Keep these audience paths visible:

  • Know literally nothing about crypto: start with start-here.html, then crypto-from-zero.html.
  • Ask "what is Kaspa?": use what-is-kaspa.html, then ghostdag-explained.html or kaspa-in-one-screen.html.
  • Need the fast non-technical answer: use overview.html or kaspa-in-one-screen.html.
  • Need to check a public claim: use kaspa-claims-checker.html, then status.html, toccata-status.html, or kaspa-smart-contracts-status.html.
  • Need a dated freshness snapshot: use kaspa-status-check-may-2026.html, then refresh it when major source evidence changes.
  • Need the recurring update index: use kaspa-status-updates.html.
  • Need to know whether Toccata is live: use toccata-status.html.
  • Need to correct finality language: use kaspa-confirmations-finality.html.
  • Need to understand why coins have value or why there are so many coins: use why-crypto-has-value.html, why-are-there-so-many-coins.html, and coin-atlas.html.
  • Need design constraints: use tradeoff-map.html.
  • Need a coin-evaluation checklist: use analyze-any-coin.html.
  • Need problem-first crypto history: use crypto-history.html.
  • Need Kaspa origin/fair-launch context: use kaspa-origin-story.html.
  • Need a compact shareable Kaspa artifact: use kaspa-in-one-screen.html.
  • Need a business/adoption lens without price prediction: use adoption-metrics.html.
  • New to crypto but already understands basic records/keys/blocks: use what-crypto-is-good-for.html.
  • Need current shipped-vs-roadmap status or common claim corrections: use status.html.
  • Need a compact first-reader path: use overview.html.
  • Know BTC/ETH/SOL/XRP/BNB/TRON but not Kaspa: start with where-kaspa-fits.html.
  • Want mechanics: use knowledge-map.html.
  • Want the app/design thesis: use application-layer.html.
  • Need to test whether a crypto product pitch is real or fake: use reality-check.html.
  • Need founder or supporter intake: use build-on-kaspa.html, builder-fit-survey.html, investor-supporter-survey.html, and kaspa-founder-investor-matching.html.
  • Need founder/search pages: use kaspa-for-fintech-founders.html, kaspa-app-ideas.html, kaspa-toccata-use-cases.html, kaspa-covenants-explained.html, kaspa-vs-solana-builders.html, kaspa-vs-ethereum-apps.html, kaspa-coordination-markets.html, and kaspa-hackathon-challenges.html.
  • Need a fair skeptical page to link in debates: use skeptical-case.html.
  • Want builder-specific programmability choices: use builder-guide.html.
  • Want short current builder recipes: use build-this-now.html.
  • Need to verify a transaction without trusting one explorer: use command-line.html.
  • Want source-level verification: use sources.html, status.html, claims-reference.html, CLAIMS.yml, llms.txt, and CONTENT_BRIEF.md.
  • Need quick term definitions: use glossary.html.
  • Need to find a concept or page quickly: use search.html.
  • Need quick corrections for social-media claims about TPS, finality, testnets, roadmap activation, app/project headlines, or adoption: use faq.html#common-misconceptions and status.html#common-misconceptions.
  • Need the common "why is KAS cheaper than BTC" answer: use faq.html#kaspa-bitcoin-valuation and why-crypto-has-value.html#market-cap. Keep it as valuation literacy, not price prediction.

The homepage includes a Bitcoin-style chain vs Kaspa blockDAG visual. Keep that visual claim narrow: parallel honest blocks can be included and ordered by GHOSTDAG. Do not use it to imply unlimited throughput, instant finality, or that scaling is solved.

The "Kaspa does not wait" or "impatient" idea can be used only as restrained explanatory flavor when it points to the actual mechanism: honest work does not have to wait in a single-file chain before it can be included and ordered. Prefer concrete lines like "do not force honest work to wait in a single-file chain" over personality-heavy slogans. Do not turn this into a guarantee of instant finality, a product slogan repeated across the site, or a replacement for the concrete GHOSTDAG/blockDAG explanation.

The where-kaspa-fits.html page should include a scannable comparison table near the top. The page's job is to help crypto-native readers understand what Kaspa is and is not competing with.

The knowledge-map.html page should start as an ordered learning path and then move into supporting source context.

The status.html page is the compact status reference. Keep it shorter than the source guide. Its job is to separate live, targeted, roadmap, and research claims quickly.

Use the status page to show why source discipline matters. Public Kaspa summaries often mix live mainnet features, testnet work, app/project headlines, roadmap targets, and research claims; the site should separate those lanes before repeating a claim.

The common-misconceptions material should be distributed by reader intent. The homepage may name the risk and route the reader. The claims checker should be the main link for arguments. The FAQ should give short corrections. The status page can carry the more precise table. The one-screen page can include only the compact "say this, not that" boundary. Do not repeat every correction on every page.

Volatile-data rule: do not add facts that can change in seconds, minutes, or hours unless they are free, source-backed, and read from a current API or live node/API script. If the fact is not important to Kaspa L1 status, omit it instead of creating a manual maintenance burden.

App/project catalogs should not be public status lanes on this site. Mention an app only when the L1 fact itself matters, such as transaction payload behavior, accepted-transaction evidence, or fees paid to miners. Otherwise, leave it out and keep Kaspa Explained focused on first-party L1 protocol status.

The status page may include a compact implementation-evidence section for current dev tracks. Keep it code-grounded and below activation evidence. As of 2026-06-05, the useful public evidence is: Rusty Kaspa v2.0.0 is the Mainnet Toccata Release and schedules activation at DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC; Rusty Kaspa v1.3.0-toc.5 was a June 3 mainnet pre-activation pre-release that explicitly did not activate Toccata; tn10-toc2 scheduled the first Testnet-10 Toccata activation point at DAA score 467,579,632; tn10-toc3 scheduled final Toccata ZK hardening at DAA score 476,232,000; Testnet-10 REST status showed virtual DAA 483,034,659 on June 5; raw KIP files list KIP-16 and KIP-20 as proposed plus implemented and activated in TN10 while KIP-17 and KIP-21 are implemented and activated in TN10; Silverscript/TN12 activity remained testnet polishing and field testing; kaspanet/vprogs April 15 ZK framework progress and rusty-kaspa/dagknight March 22 prototype/refinement activity remained development signals. Do not let this section become a hype feed or imply mainnet activation before the activation score and post-activation behavior exist.

The overview.html page is the 90-second first-reader route. Keep it compact: what Kaspa is, what is live, what is not live, why it matters, and what to read next.

The kaspa-in-one-screen.html page is the shareable compression artifact. It should say what Kaspa is, what is live, why it matters if the thesis works, what is not live, and what signals would strengthen or weaken the thesis. Keep it status-labeled and non-promotional.

The adoption-metrics.html page is the business/adoption lens. It should avoid price prediction and instead explain wallets, node health, mining distribution, fees/block demand, liquidity, developer activity, integrations, and post-Toccata app signals as evidence categories.

The application-layer.html page is the app-opportunity and builder-imagination page. It should explain why someone would build on Kaspa without pretending every app is live. The page should not read like "Kaspa gets L2s too," and it should not make generic merchant/POS payments the adoption thesis. It should explain the L1-first thesis in concrete product terms first: app receipts, vault rules, asset rules, escrow, coordination markets, attestations, public funding rules, proof checks, and apps that prove what they did. Then name the technical layer: Kaspa L1 supplies shared sequencing, ordering, commitments, verification hooks, settlement, and neutral primitives; apps and runtimes add semantics, incentives, proving, and user experience around those primitives. Map what other crypto networks enabled, then translate those patterns into Kaspa-native paths while preserving status discipline. Include the RTD internet-money flow as app-level research/architecture: a user defines a strategy around an external event, an application defines incentives for opt-in miners or rewarded reporters to attest, the system samples the PoW majority, and assets/logic on Kaspa can gain lower latency and closer atomicity. Do not imply this flow is shipped today or protocol-prescribed.

When explaining coordination markets, start with the product shape: users make conditional commitments, the app groups compatible commitments, a solver checks whether the group satisfies the conditions, and settlement or refunds follow. The first buildable lane can be transparent and replay-backed. The harder research target adds private accumulation, capital multiplexing, solver incentives, censorship resistance, MEV resistance, and atomic execution.

When explaining app-to-app composition, make the key boundary atomicity, not "same block." Fast L1 ordering, proof-linked coordination, or two actions landing close together are not the same as one combined state transition where all touched apps succeed or fail together. Toccata can support covenant rules, ZK proof checks, sequencing commitments, and based-zk foundations. Full cross-app atomic composition remains later vProgs roadmap architecture.

The builder-guide.html page is the builder-specific programmability router. It should help builders choose between covenants, based apps, inline ZK, and future full vProgs by asking about concurrency, state shape, and proof requirements. Credit Izio's progdoc material as builder guidance. Keep Python SDK, TxIndex, Silverscript, and open PRs in builder/tooling lanes, outside protocol-status lanes.

SilverScript/covenant examples should be judged by the state transition they actually prove. A serious example shows continuation state, required output rules, signature-script wiring, rejected paths, and a submit route that preserves covenant fields. Funding a script output or wrapping P2PK logic is not enough to call a feature script-enforced. Lead with the concrete job: budget that cannot drain at once, step-by-step workflow, asset that needs its controller, group release/refund, scheduled payout, or blocked withdrawal. Use worker-routed workflow, controller-input authority, and challenge/timeout language only when the specific artifact or source supports it.

For builder-facing ZK wording, keep the external-anchor boundary explicit. ZK verification proves a statement about chosen public inputs; it does not by itself prove external-chain canonicality, prices, oracle events, or real-world facts. If a bridge, market, oracle, or attestation app depends on outside data, name the anchor: source-chain light client, finality certificate, accumulated-work view, oracle, reporter set, challenge process, or other trust model. This is a precision rule, not a reason to bury the reader in bridge theory.

The current Kaspa.org Build page is a useful developer-resource index. Preserve links to official docs, Rusty Kaspa releases, WASM SDK docs/examples, community REST API docs, Public Node Network docs, Docker Hub, explorer/API DB dumps, testnet faucet, KIPs, Silverscript, vProgs, Simply Kaspa Indexer, DNS Seeder, kHost, kaspa-js, and the R&D Telegram. Keep hosted APIs/public nodes labeled as best-effort or demo-friendly, and community projects labeled as projects to inspect before production use.

The Kaspa Developer Platform at docs.kas.fyi is a hosted API source, not protocol activation authority. It is useful for builder references around API-key access, address history, transaction acceptance checks, block ranges by blue score or DAA score, node RPC proxy access, data types, pagination, rate limits, and beginner node-running guidance. Use it in sources.html, builder-guide.html, and command-line.html as a practical hosted read path. Keep the boundary explicit: API keys, rate limits, provider uptime, and pricing are product dependencies; production systems should plan their own node/indexer or provider redundancy when reliability, privacy, or scale matters.

For builder-guide UX, use the new Kaspa.org BUIDL path as a practical runway: try live browser SDK examples, choose App SDK / Native Rust / Node, use REST or Public Node Network only for prototypes and light reads, then graduate to own-node or indexer infrastructure for production. This is useful because it tells builders what to do first without implying that hosted APIs or testnet programmability are final production paths.

The builder guide should also preserve practical testnet breadcrumbs learned from hands-on prototyping: use exact kaspatest: addresses; faucet use may require a browser; local balance checks need a synced testnet node with UTXO index; an unsynced node can return misleading zero balances; a generic stable mainnet binary may not support every active TN12 setting; and TN10/Toccata activation-test commands should start from the current Rusty Kaspa release notes, not old Crescendo examples. Put this in the builder lane, not across the whole site, and keep mainnet instructions separate from testnet-only covenant work.

Builder-facing verification lessons should be concrete and reusable: a local txid is not accepted app state; fetch accepted transaction evidence after submit; record node version, SDK version, network id, endpoint, encoding, tx version, and input budget fields; compare failing contract spends against accepted sibling spends before claiming a protocol boundary; and label failures narrowly as bad config, stale tooling, submit mismatch, or confirmed consensus rejection. Keep private prototype txids out of public copy unless they are independently useful as source evidence.

For the app page specifically, the Bitcoin Takeover interview changes the framing in these ways:

  • Explain the app case as money plus finance without compromising the L1 monetary base.
  • Avoid Ethereum-style rollup language unless contrasting it with Kaspa's intended shared-sequencer/cohesive-program model.
  • Describe "Solana-like" only as cohesive developer/user experience and native-feeling composability, not as Solana execution imported into Kaspa.
  • Keep "one app per VM" / app-level verifiable-program intuition available for advanced readers, while explaining it first as apps proving their own logic while sharing Kaspa ordering.
  • Treat DeFi, stable assets, lending, swaps, social recovery, vaults, bridges, and tokenized assets as things builders can target through staged primitives, not as live products.
  • Make clear that core should not own the product layer: wallets, explorers, apps, oracles, bridges, and UX should be plural and community-built where possible.

The glossary.html page is the compact term map. Keep definitions short and plain.

Editorial Standard

Use plain, direct language. Preserve a serious point of view, but do not hype.

The voice should never sound clever for its own sake. Avoid dramatic authority, bold adjective piles, invented slogans, and sentences that mainly perform confidence. Let the facts, source links, and concrete examples carry the weight.

Apply this writing bar across public pages and LLM-facing files. Every touched page, repo guide, source note, generated summary, and context file should be direct, sourced or status-labeled, necessary, and free of defensive throat-clearing.

Good style:

  • specific nouns,
  • concrete tradeoffs,
  • named actors and requirements,
  • clear current-status wording,
  • useful comparisons,
  • short explanations before jargon,
  • links to source material.

Avoid:

  • "crypto fixes everything",
  • "Kaspa solved the trilemma",
  • "Bitcoin but faster",
  • "native DeFi is live",
  • "DAGKnight is active",
  • "Toccata is live" unless future primary sources confirm it,
  • price targets,
  • exchange rumors,
  • corporate abstraction without a concrete actor and requirement, such as "institutional readiness," "ecosystem maturity," "enterprise adoption," "strategic unlock," "robust platform," or "seamless experience",
  • market-cap or rank claims frozen into the explainer,
  • avoid vague claims like "revolutionary" without explaining the mechanism.
  • repeated contrast scaffolding on public pages,
  • repeated contrast frames, vague transformation formulas, and synthetic thought-leadership cadence,
  • overcorrected negative framing where every paragraph repeats a missing feature; use one status label and name the next dependency instead,
  • over-polished LLM phrasing such as "delve", "tapestry", "seamless", "robust", "pivotal", "crucial", "unlock", "empower", "transform", "reimagine", "landscape", "journey", "at its core", "ultimately", or inflated adjectives that do not add a mechanism,
  • brochure language such as "next-generation", "cutting-edge", "game-changing", "powerful platform", "accelerate innovation", "drive the future", or "pave the way",
  • clever-authority phrasing that tries to sound definitive without adding evidence,
  • dramatic adjective stacks where one plain noun would work,
  • defensive caveat stacks where one status label or one source link would do the job.

Editing test: each public sentence should make a specific, necessary, defensible claim. If a sentence mainly adds polish, symmetry, or persuasion cadence, cut it or move the detail to the source/context stack.

Craft rule: text is product surface. UI labels, public copy, repo docs, fixtures, generated summaries, LLM context, and handoff notes need the same care as code. Keep every line necessary, accurate, scan-friendly, and clean. Prefer plain build language: live, near-term, roadmap, research, needs wallet, needs indexer, needs custody, needs source.

Implementation craft rule: a public edit is not complete just because the words or layout look better in one viewport. Treat each page as a small product surface with user intent, states, responsive behavior, accessibility, performance, source trail, and maintenance cost.

For Kaspa Explained this means:

  • Pinpoint feedback is exact-defect input first, not rollback permission. If a reader or the user flags one malformed arrow, cramped label, weird glyph, typo, copy line, or spacing bug, identify and repair that element before changing unrelated parts. This does not mean hold back on quality: when the task is a broader cleanup or redesign, keep improving the surface after the defect is fixed.
  • Every section should support a reader job: understand, compare, verify, build carefully, search, or correct a claim.
  • Shared patterns should behave consistently: route cards, source cards, status chips, comparison tables, app-path ladders, search results, drawers, command blocks, and footer links.
  • Status states stay distinct: live mainnet, targeted upgrade, testnet-only, roadmap, research, source-needed, stale-check-needed, wrong, unsupported, and unknown.
  • Long source titles, URLs, page labels, protocol terms, and dates must wrap cleanly on mobile.
  • Tables belong where comparison or source evidence is the job. Beginner-facing pages should explain the plain action before dense grids.
  • Search and source-pack docs need useful routing back to source/status pages and must not become source authority.
  • Use semantic HTML, real links for navigation, buttons for actions, visible focus, logical headings, and status text that does not depend on color alone.
  • Keep the site dependency-light. Prefer crawlable HTML, shared CSS variables/classes, small SVGs, and vanilla JS over framework or animation additions.
  • Public claims, metadata, sitemap entries, llms.txt, CLAIMS.yml, and source pages should not drift apart after a status-sensitive edit.

Plain-language rule: if a sentence says a vague group "needs readiness" or "needs maturity," rewrite it around the actual actor. A fund may need custody, audit trails, reporting, and legal review. An exchange may need node stability, wallet integration, liquidity, monitoring, and support. A payments company may need payment APIs, refunds, accounting, uptime, and support. A builder may need docs, SDKs, indexers, examples, and testnet paths. If the sentence cannot name who needs what, it is probably filler.

Tone and visual weight:

  • Use medium authority. The site should sound clear and grounded. Avoid small, apologetic, manifesto, pitch-deck, and definitive-guide posture.
  • Write like a knowledgeable person helping a rushed reader choose the right path.
  • Use medium visual weight. Headings, cards, callouts, and diagrams should be clear and confident, not oversized or theatrical. Use size to create hierarchy, not drama.
  • Prefer humble guidance: "start here", "check this lane", "use this distinction", "current boundary", "what exists now", and "what may come later."
  • Avoid turning every heading into a grand claim, final answer, or abstract thesis.
  • Let interest come from concrete usefulness. The site can be Kaspa-positive without sounding promotional.

Status Lanes

Keep these categories separate.

Live / Factual Now

  • Proof of Work blockDAG
  • UTXO model
  • GHOSTDAG consensus
  • Crescendo 10 BPS era
  • real-time decentralization as the core fast-PoW value proposition and current Kaspa.org north-star framing: Bitcoin-style PoW security and censorship-resistance goals with seconds-scale confirmation feel under normal network conditions
  • pruning and UTXO commitments
  • public wallets, explorers, visualizers, nodes, mining ecosystem

Near-Term / Implementation Track

  • Toccata hard fork
  • covenants
  • Silverscript
  • ZK verification foundations
  • sequencing commitments
  • vProgs groundwork

Status note: Toccata should not be described as live mainnet functionality without current primary activation evidence. It is now a released and scheduled mainnet hard-fork track. Rusty Kaspa v2.0.0 is the current primary release source for the activation parameters: DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC. Michael Sutton's April 2026 Toccata outlook remains useful implementation context for why the older May 5 target moved so sequencing-commitment/KIP-21 architecture could be finalized before zk systems bind to it. Rusty Kaspa's tn10-toc2 and tn10-toc3 pre-releases plus Testnet-10 REST status are current testnet evidence: the releases scheduled Testnet-10 activation and final Toccata ZK hardening at DAA scores 467,579,632 and 476,232,000, and the June 5 API check showed virtual DAA 483,034,659.

Roadmap / Architecture

  • vProgs as app-level verifiable programs
  • Kaspa-native DeFi paths
  • monolithic-feeling developer experience without global L1 execution of every app
  • synchronous composability across programs
  • vProgs as a deeper application-architecture direction

Research / Speculative

  • DAGKnight final form and activation timing
  • Kaspa.org's proposed 2027 bucket for 100 BPS, 10 millisecond blocks, and partition-resilient local payment flows
  • App-level miner attestation, oracle, TangVM, and coordination-market incentive designs
  • RTD internet-money flows where miners or reporters attest to external events and apps react atomically
  • TangVM-style reality-state ideas
  • Proof of Useful Work via matrix multiplication
  • long-term post-quantum migration paths

Current Core Framing

Kaspa is best framed as:

A Proof of Work blockDAG that generalizes Nakamoto consensus so parallel honest blocks can contribute to ordering instead of being discarded as ordinary orphans.

The stronger comparison is not "faster Bitcoin." It is:

Keep Proof of Work and UTXO instincts, remove the single-file blockchain bottleneck with a blockDAG, and move toward bounded apps that can prove their rules.

Do not imply that Bitcoin has no latency parameter or network-timing assumption. Bitcoin's 10-minute block interval also assumes network latency is much smaller than the block interval; one useful shorthand is that Bitcoin behaves like the k=0 edge case in this family of Nakamoto/GHOSTDAG-style reasoning. The useful contrast is not "Bitcoin is unparameterized, Kaspa is parameterized." The useful contrast is how Kaspa exposes, raises, and eventually aims to adapt the block-rate/latency tradeoff while allowing parallel honest blocks to contribute to ordering.

Fast Proof-of-Work Framing

Keep the fast-PoW argument focused and careful. Fast inclusion and fast confirmations are different:

  • Fast inclusion: how quickly a transaction enters a block.
  • Fast confirmations: how quickly the system gives strong confidence that the transaction will not be reversed.

Any high-rate block-producing system can improve inclusion. Kaspa's stronger argument is that fast Proof of Work changes the confirmation/decentralization tradeoff. PoW samples hash power through work done after the fact, without requiring the protocol to identify and collect explicit supermajority votes from miners before every confirmation. In PoS finality designs, confirmation speed is more directly tied to stake voting, validator coordination, stake distribution, committees, or related sampling assumptions.

Do not overclaim this. Do not state that Kaspa provides instant irreversible settlement, that all PoS systems are equivalent, or that the site has fully modeled Ethereum/Solana engineering details. The durable, site-appropriate claim is narrower: fast PoW blockDAGs make the inclusion/confirmation/decentralization tradeoff different, and that is one reason Kaspa is worth studying.

Crescendo-specific nuance: do not turn 10 BPS into "10x finality." Michael Sutton's public Crescendo explanation framed practical throughput as roughly 8-9x higher under the observed policy and confirmation-time improvement as closer to 30%, because confirmation remains dominated by block latency. Use this to correct summaries that imply unlimited throughput, instant finality, or a clean 10x confirmation improvement.

TPS and speed claims need measurement labels. Do not freeze one public TPS number as normal mainnet behavior unless current primary sources support that exact measurement and context. Distinguish block rate, block capacity, policy limits, test/lab throughput, sustained capacity estimates, organic demand, fees, and confirmation confidence.

Crypto Reality-Check Framing

The what-crypto-is-good-for.html page is a general-audience bridge for people who do not live inside crypto. It should make the rest of the site more credible by stating that crypto is not useful for everything.

The start-here.html and crypto-from-zero.html pages are the true zero-start path. They should not assume the reader knows decentralization, blocks, mining, tokens, market cap, keys, privacy tradeoffs, UTXO, or consensus. Teach the problem first, the mechanism second, the tradeoff third, and Kaspa fourth.

The why-crypto-has-value.html, why-are-there-so-many-coins.html, coin-atlas.html, tradeoff-map.html, analyze-any-coin.html, and crypto-history.html pages are the market and context layer. They should explain valuation, categories, token necessity, launch design, actors, incentives, scams, and design constraints without becoming investment advice or price prediction.

The reality-check.html page is the crypto-native product judgment layer. It should help readers test pitches against concrete users, jobs, liquidity, wallet/signing flow, current-status labels, evidence, failure modes, and day-two behavior. It should not become a directory of other chains, app projects, hackathons, or market programs.

Core frame:

Crypto is useful when strangers need one shared record of ownership and rules without one company, bank, platform, or government controlling the database. The technical version is a neutral shared record: ownership records, adversarial trust, self-custody, global 24/7 settlement, censorship resistance, programmable assets, on-chain markets, objective smart-contract escrow, digital provenance, or open-network incentives.

Keep the weakness side just as explicit. Crypto is usually weak for normal domestic payments in strong banking systems, consumer reversibility, private records, ordinary corporate databases, unsecured real-world credit, replacing courts, supply-chain truth, identity, and tokenizing assets whose ownership still depends on law, custody, inspection, liens, taxes, and jurisdiction.

Keep this page conditional: crypto is real when a neutral shared record is worth the cost, and theater when a trusted operator, legal process, or normal database solves the problem better.

The why-kaspa-matters.html page is the Kaspa-specific bridge from the general crypto reality check. It should explain why Kaspa matters when neutral money, self-custody, censorship resistance, fast mined ordering, future apps that prove rules, and public group commitments matter.

Core frame:

Kaspa keeps Proof-of-Work security culture while pushing the payment experience closer to real time: fast mined ordering today, app receipts around the live network, and future apps that prove their own rules.

Keep this page tightly status-labeled. GHOSTDAG, the UTXO model, Proof of Work, Crescendo 10 BPS, and the base RTD framing are live enough to describe as Kaspa's present value proposition: real-time Bitcoin-style PoW settlement, censorship-resistance goals, and a broader case than fast payments alone. The May 8, 2026 Kaspa Daily Yonatan Q&A makes this sharper: Base of Liquidity is positioning context, generic payments are not the whole adoption strategy, and product development plus visible on-chain activity matter. Toccata, covenants, Silverscript, ZK foundations, sequencing commitments, and vProgs groundwork are the near-term implementation track. vProgs and native DeFi are roadmap architecture. DAGKnight, app-level miner attestation incentives, oracle/TangVM flows, and coordination-market applications remain research or architecture work unless future primary sources confirm activation or shipped software.

App/project nuance: do not turn app standards, wallets, frontends, or marketing into Kaspa L1 status copy. If the L1 fact matters, cite transaction payload docs, accepted-transaction docs, public node/API evidence, or miner fee/reward evidence. Otherwise, leave it out.

The sources.html page is the public source hierarchy and attribution page. Use it to centralize credits, Kaspa.com Learn Kaspa links, external references, and public crawl/LLM file links instead of adding distracting footnote walls to every human-facing page. The homepage should stay a human-first router: three primary actions, four main reader paths, one short status boundary, a compact app-layer preview, and a clear handoff to the source/context stack.

Design for two human modes at once: a rushed reader who needs the right page in seconds, and an interested reader who wants depth after choosing a lane. Long pages should provide jump links near the top. Dense source lists, changelogs, and implementation evidence can use <details> so the core explanation stays scannable. Do not hide the main thesis, status boundary, or first useful answer behind a toggle.

Programmability Framing

Be careful with app-layer claims.

DAGKnight has the better-developed research lineage and a more visible implementation branch than vProgs. Both remain outside live-mainnet status until primary sources confirm activation. This nuance belongs in status discipline and research context; it does not need to be repeated everywhere.

Keep "Kaspa DAGKnight is WWIII-resistant" out of public headline copy. When it appears as community shorthand, frame it as an adversarial-latency resilience research/implementation goal, not as a live-mainnet guarantee.

Toccata and vProgs are related but distinct. Toccata/Covenants++ is the nearer L1 hard-fork track for concrete rules such as spend constraints, asset rules, covenant IDs, Silverscript, ZK-facing verification work, sequencing commitments, native-asset groundwork, and standalone based-app experiments. A based app anchors app-specific state to Kaspa L1 ordering, commitments, proofs, settlement, or exits; ZK is one verification path, not the definition of every based app. vProgs are the longer app architecture for apps that prove richer logic while sharing Kaspa ordering, computational-DAG metadata, prover-backed execution, and eventual synchronous composability.

Kaspa programmability should be framed as concrete use first, neutral primitives second. Say what the user or app is trying to do: lock funds, enforce a vault rule, create an asset, route a payment, fund a public good, resolve a market, attest to an event, or prove app logic. Then explain that the protocol should expose durable L1 surfaces while apps define incentives, semantics, oracle sources, legal/risk constraints, and user-facing products. Apply that rule to attestations, prediction markets, DePIN freshness markets, portfolio automation, launch paths, AI-agent task boards, and DeFi.

Junny Ho's Web3 Festival HK 2026 talk, "Scaling Trustless Coordination" (https://www.youtube.com/watch?v=b3wPZ04p410), is a narrative source for the coordination-market thesis. It frames the problem as stag hunt, not prisoner's dilemma, names credible commitments, conditional participation, and economic exposure as core market primitives, and connects Kaspa's real-time decentralized confirmation thesis to coordination markets that need fast observable signals without centralized sequencing. Use it for product framing. Keep live-status labels tied to activation evidence.

The Toccata/vProgs capability split should be precise. Toccata gives L1 covenant programming and based-app foundations: covenants, Silverscript, ZK verification opcodes, sequencing commitment access, partitioned sequencing commitments, native-asset groundwork, and bridge/settlement patterns. Hans Moog's kaspanet/vprogs repo is an early Rust framework for based computation on Kaspa with scheduler, resource access, batch execution, rollback, storage/state layers, node VM, L1 bridge, and ZK proving pipeline. Its immediate role is compatible based computation/runtime work, while full vProgs synchronous composability is later architecture.

Builder tooling belongs in its own lane. The standalone kaspanet/kaspa-python-sdk repo and v1.1.0 release show Python integration, virtual-chain access, and UTXO tracking through UtxoProcessor/UtxoContext. Protocol status still comes from node, release, KIP, and activation evidence. TxIndex PR #860 is builder/infrastructure evidence while open; Fast Trusted Relay PR #930 is an infrastructure experiment until merged and released. The redesigned Kaspa.org Build page also makes the infrastructure runway clearer: Rusty Kaspa, WASM SDK, public nodes, community REST APIs, database dumps, KIPs, Silverscript, vProgs, and public R&D channels are builder routes, while production systems still need explicit node, indexer, archival, API-key, rate-limit, and provider-redundancy decisions.

KIP alignment is now a status-sensitive subtopic. As of June 5, 2026, raw KIP files list KIP-16 and KIP-20 as proposed plus implemented and activated in TN10, while KIP-17 and KIP-21 are implemented and activated in TN10. Do not flatten this into finalized mainnet activation until activation artifacts and network behavior agree.

Frame Kaspa as L1-first and shared-sequencer-first: applications add programmability directly against Kaspa L1 primitives, while based-zk systems and future vProgs use Kaspa L1 for sequencing, commitments, settlement, and verification without separate sequencer empires.

Based apps are a real build lane, not a future caveat. Direct L1 covenant examples such as vaults, escrow, and assurance can be explained without an L2. Based-app prototypes should be described as richer app state anchored to Kaspa ordering, commitments, proofs, settlement, or exits. Based-zk is the stronger proving path when replay alone is not enough. Keep ecosystem L2 projects out of the site's assumptions unless a page is explicitly about ecosystem projects.

vProgs should be described first as apps that prove their own logic, then as app-level verifiable programs or app-level ZKVM/verifiable-program environments. Do not flatten them into ordinary rollups. The intended direction is a native-feeling, cohesive developer/user experience while keeping L1 focused on sequencing, commitments, verification, and metadata, while app runtimes execute their own logic.

For application-layer discussion, treat Michael Sutton's vProgs framing as a roadmap target for one-dimensional program space, shared Kaspa L1 sequencing, synchronous composability, computational DAG metadata, prover incentives, and sovereignty obligations. Covenant++ milestone notes can inform the staged path: inline zk covenants, based zk covenants, canonical bridges, native-asset bridge work, and efficient sequencing commitments. STARK-sized proof support and standard minimum fee changes are design questions unless future primary sources confirm mainnet activation.

Long-Form Interview Model

Bitcoin Takeover S16 E41, the 2025 Yonatan Sompolinsky interview, should guide the shape of the explanation: Kaspa as a generalization of Nakamoto consensus, the blockDAG as a framework whose value depends on ordering, GHOSTDAG as current mainnet behavior, DAGKnight as future/adaptive consensus work, vProgs as native-feeling app architecture, and community context as part of decentralization.

For origin history, use the same interview to keep the fair-launch story candid: Yonatan described the launch as messy and reluctant, said the gamenet idea was overtaken by miners who kept mining, and framed the early second-genesis recovery as preserving the UTXO set rather than reallocating coins. Pair that with Kaspa.org, Hashdag, Investing.com, Guy Corem's testnet note, HackerNoon, and the older Epicenter/Rethink Trust sources before making origin claims.

Use the interview as an editorial model, not as a public slogan. It shows the target feel for the site: patient first-principles reasoning, everyday examples, willingness to compare Bitcoin/Ethereum/Solana without tribal shortcuts, clear admission of uncertainty, and careful distinction between live protocol, roadmap, and aspiration.

Do not turn the interview's roadmap discussion, demos, or aspirations into live-status claims. In particular: native DeFi is not live, DAGKnight is not live, vProgs are not live, 100 BPS and partition-resilient payment flows are proposed future work, pruning is not privacy, and Solana-like means cohesive developer/user experience, with no imported Solana execution model on Kaspa L1.

Source Hierarchy

Prefer primary or near-primary sources:

  1. Primary protocol/code: kaspanet/rusty-kaspa, releases, KIPs, Kaspa Research, and protocol documentation.
  2. Core-dev explainers: Michael Sutton technical posts, Ori Newman, Coder of Stuff, Hashdag/Yonatan, and other active technical builders.
  3. Long-form framing source: Bitcoin Takeover S16 E41. It is high-signal for explanatory framing and status nuance. Activation claims still need primary protocol/code or direct implementation evidence.
  4. Context and education sources: Oxford recordings, KASmedia, Kaspa.com Learn Kaspa, the current Kaspa.org site, full recordings, interviews, transcripts, and recaps. They are useful for orientation, links, and framing, not protocol activation by themselves.
  5. Learning references: Kaspa.com Learn Kaspa / Kaspa Facts for approachable intro/intermediate concept explanations. Credit this source when using its explanations, but treat it like community education and verify shipped-feature and activation claims against primary protocol/code sources.
  6. Discovery only: active public technical X accounts and replies.

The current Kaspa.org site is the public Kaspa/KasMedia entry point for broad orientation, fair-launch/genesis-proof framing, wallet flow, builder routing, and links into stronger sources. It replaced the older article-style site, so old Kaspa.org article URLs should be treated as stale until checked. Status-sensitive claims should still come from code, releases, KIPs, research papers, protocol documentation, or direct implementation notes from core technical contributors.

Use X cautiously. It is useful for current builder commentary, links, replies, and corrections. It is weak for shipped-feature claims unless backed by code, KIPs, releases, or durable long-form sources.

Do not use stale team pages, recycled handle lists, or contributor pages to infer current involvement.

External-source rule: credit outside sources by name and link near the relevant claim or through sources.html. Do not copy external articles into the site. Paraphrase, synthesize, and point readers to the original source.

Kaspa.com Learn Kaspa status: treat the article set as a useful learning library for BlockDAG, GHOSTDAG, DAG terminology, parents/mergesets, blue score/blue work, k-clusters, pruning, UTXO, MuHash, finality, transaction selection, mass, opcodes, KIPs, and node types. Recheck it before relying on it for newly changed concepts. Do not plaster this source across the main pages or use it as the primary authority for status claims.

The May 2026 Kaspa.com Smart Contracts article is useful because it separates programmability into layers and includes a chess covenant walkthrough. Use that chess material as a concrete example of UTXO state-machine design: registration state, player state, game state, move-routing transactions, move-application transactions, and final settlement. Do not frame it as proof that a mature app ecosystem is live.

Public Crawl Map

The sitemap should include public human pages and LLM/crawler files:

  • /
  • /start-here.html
  • /crypto-from-zero.html
  • /why-crypto-has-value.html
  • /why-are-there-so-many-coins.html
  • /coin-atlas.html
  • /tradeoff-map.html
  • /analyze-any-coin.html
  • /crypto-history.html
  • /kaspa-origin-story.html
  • /kaspa-in-one-screen.html
  • /adoption-metrics.html
  • /application-layer.html
  • /overview.html
  • /what-crypto-is-good-for.html
  • /status.html
  • /faq.html
  • /why-kaspa-matters.html
  • /where-kaspa-fits.html
  • /knowledge-map.html
  • /glossary.html
  • /search.html
  • /sources.html
  • /about.html
  • /llms.txt
  • /CONTENT_BRIEF.md
  • /README.md
  • /CLAIMS.yml

Do not advertise AGENTS.md in sitemap.xml. It can remain publicly reachable as a repository file, but it is local agent guidance outside the public content surface.

Active Public Technical Accounts

Useful for discovery and replies:

Read replies as well as top-level posts when researching a current technical point.

Transcript and Video Handling

Use video transcripts as source material, not as automatic website copy.

Workflow:

  1. Find the exact recording URL or video ID.
  2. Check whether a transcript is visible in YouTube UI, Podscan, podcast pages, or another attributable transcript page.
  3. Treat transcript mirrors as weaker than the recording page, podcast page, KASmedia recap, or user-supplied transcript unless timing and attribution are preserved.
  4. Keep recaps and transcripts separate.
  5. Promote only the strongest non-duplicative points to the homepage.
  6. Put deeper transcript notes in CONTENT_BRIEF.md, llms.txt, CLAIMS.yml, or source docs.

Important transcript-backed sources currently used:

Quantum Framing

Do not describe Kaspa as quantum-safe today.

Do not conflate mining hashes with transaction signatures. Proof of Work and wallet authorization face different quantum questions.

Do not describe Toccata as the quantum upgrade. Treat post-quantum readiness as a separate migration topic unless primary builders publish a concrete plan.

Useful quantum-answer frame:

  • wallets,
  • exchanges,
  • exposed public keys,
  • old UTXOs,
  • new address formats,
  • signature size,
  • verification cost,
  • user coordination.

Site Structure

Primary public pages:

  • index.html - audience-routed homepage, real-time Proof-of-Work case, interactive blockchain-vs-blockDAG teaching model, status labels, zero-start links, and compact Kaspa/adoption routes.
  • start-here.html - true beginner router for readers who know nothing about crypto or Kaspa.
  • crypto-from-zero.html - causal ladder from records, keys, transactions, blocks, consensus, incentives, tokens, and tradeoffs to Kaspa.
  • why-crypto-has-value.html - market-value explainer for token need, prices, market cap, open markets, speculation, launch design, and who benefits.
  • why-are-there-so-many-coins.html - category bridge explaining why major crypto assets are not all trying to do the same job.
  • coin-atlas.html - coin-category atlas and value-stack map for BTC, ETH, stablecoins, SOL, BNB, XRP, LTC, BCH, XMR, DOGE, LINK, and KAS.
  • tradeoff-map.html - beginner tradeoff map for speed, security, decentralization, privacy, scaling, nodes, ASICs, staking, launch design, and Kaspa.
  • analyze-any-coin.html - practical checklist for evaluating token necessity, supply, launch, validation, liquidity, market cap, risks, and beneficiaries.
  • crypto-history.html - problem-first history map from digital cash and Bitcoin through Ethereum, ICOs, DeFi, stablecoins, rollups, and Kaspa.
  • kaspa-origin-story.html - sourced origin page for DAGLabs, Polychain/Accomplice-era VC funding context, PHANTOM/GHOSTDAG, the April 2021 testnet, failed hardware/presale paths, fair launch, the DAGLabs/Polychain-related early-miner estimate, Black Tuesday, dust-attack context, Rust rewrite, Crescendo, and the Toccata boundary.
  • kaspa-in-one-screen.html - compact shareable Kaspa thesis with live/not-live/status-labeled framing.
  • adoption-metrics.html - non-price adoption and business lens for wallets, nodes, mining, fees, liquidity, builders, integrations, and post-Toccata app signals.
  • application-layer.html - status-labeled application-layer opportunity map for what builders can use now and what Toccata, vProgs, RTD, and coordination-market research may support later.
  • build-on-kaspa.html - founder and builder funnel that routes app ideas through fit questions, surveys, and matching-board paths.
  • builder-fit-survey.html - local browser survey for founder/app idea intake. It creates a copyable summary and does not submit data from GitHub Pages.
  • investor-supporter-survey.html - local browser survey for supporter, mentor, technical-review, and capital-interest intake.
  • kaspa-for-fintech-founders.html - founder-facing fintech fit page for payments, receipts, custody, escrow, and treasury rules.
  • kaspa-app-ideas.html - app idea map by status lane.
  • kaspa-toccata-use-cases.html - Toccata use-case page for covenants, ZK hooks, sequencing commitments, and mainnet evidence boundaries.
  • kaspa-covenants-explained.html - plain-language covenant page for UTXO spend rules.
  • kaspa-vs-solana-builders.html - builder comparison page for Kaspa and Solana.
  • kaspa-vs-ethereum-apps.html - app comparison page for Kaspa and Ethereum.
  • kaspa-coordination-markets.html - coordination-market page for conditional commitments and assurance funding.
  • kaspa-hackathon-challenges.html - hackathon challenge page for AI agents, wallets, receipts, and vaults.
  • kaspa-founder-investor-matching.html - matching-board model for opt-in public cards and consent-based intros.
  • builder-guide.html - builder-specific programmability router for covenants, based apps, inline ZK, future full vProgs, SDKs, and infrastructure evidence.
  • builder-evidence.html - proof bridge page that points readers to TN12 evidence and keeps app ideas separate from proof.
  • overview.html - 90-second overview for first-time readers.
  • what-crypto-is-good-for.html - reality-check page explaining where crypto itself is useful, where it is weak, and why Kaspa should be judged where neutral shared records are worth the cost.
  • status.html - compact status page for live, targeted, roadmap, and research items.
  • faq.html - direct search-friendly answers for common Kaspa status and concept questions.
  • why-kaspa-matters.html - Kaspa-specific bridge page explaining how Kaspa maps to crypto's useful jobs without claiming the roadmap is already live.
  • where-kaspa-fits.html - category-fit page for comparing Kaspa with other crypto categories.
  • knowledge-map.html - ordered concept map for average crypto readers, with supporting source context.
  • glossary.html - compact plain-English glossary for common Kaspa terms.
  • search.html - dependency-free static page-map search for concepts, audiences, status labels, and source terms.
  • sources.html - public source hierarchy, external reference map, Kaspa.com Learn Kaspa topic index, and public crawl map.
  • about.html - public editorial policy, disclosures, correction handling, and accountability page.
  • CLAIMS.yml - reference file for status-sensitive claims and forbidden overclaims.

LLM/source files:

  • llms.txt - compact LLM-facing context.
  • CONTENT_BRIEF.md - editorial/project handoff.
  • README.md - repo setup, source discipline, and deployment notes.
  • AGENTS.md - local coding-agent instructions.
  • builder-evidence.html - bridge page for technical proof verification.

Update Workflow

Before changing claims:

  1. Identify whether the claim is live, near-term, roadmap, or research.
  2. Check primary or near-primary sources.
  3. Prefer exact links over paraphrased rumors.
  4. Do not use current X posts alone for activation or shipped-feature status.
  5. Keep homepage copy general-audience friendly.
  6. Put dense technical detail in llms.txt, CLAIMS.yml, source docs, or this brief.
  7. Run basic checks before publishing:
    • bash scripts/check-site.sh
    • bash scripts/check-links.sh when source/reference URLs change
    • git diff --check
    • link check for new URLs
    • mobile/desktop layout check for HTML/CSS changes
    • verify CNAME, robots.txt, sitemap.xml, and llms.txt still point to https://kaspaexplained.com/

Additional consistency checks after the May 2026 human-first/tone pass:

  • Public tone: scan changed public copy for medium authority and medium visual weight. Avoid grand titles, personal/internal shorthand, pitch-deck phrasing, and overlarge visual hierarchy.
  • LLM/context boundary: keep dense source rules, maintenance notes, and retrieval guidance in llms.txt, CLAIMS.yml, sources.html, and this brief. Public pages should not expose internal editorial notes.
  • Source freshness: use current kaspa.org/developments/, docs.kaspa.org, and kaspa.org/build for orientation and builder routing, then verify live/shipped protocol claims against KIPs, code, releases, research papers, or accepted artifacts before public copy changes.
  • Web basics: favicon, touch icon, manifest, Open Graph image, Twitter image, canonical links, sitemap, robots, and local screenshots are part of the product surface. Keep them updated when brand marks, route structure, or public framing changes.
  • GitHub public framing: when homepage, README, or site voice changes, check GitHub About metadata (gh repo view ... --json description,homepageUrl,repositoryTopics) and keep the repo description aligned with the live site.
  • Fast-PoW graph: verify the why-kaspa-matters.html comparison graphic does not imply instant finality, a simple "stronger confirmation" ranking, or a universal critique of all PoS systems. The visual should distinguish inclusion speed from explicit vote/stake coordination, and it must not overlap on mobile.
  • Visual overlap: for any CSS, heading-size, diagram, table, or card change, screenshot the affected page on mobile and desktop. Check that axis labels, hero arcs, buttons, cards, and table labels do not cover nearby text.
  • Live deployment: after push, verify GitHub Actions, Pages deployment, and direct live HTML for the exact changed phrases before saying the change is live.

Interpretation Rules for LLMs

  • Do not describe DAGKnight, vProgs, app-level attestations/oracles, TangVM, Proof of Useful Work, post-quantum migration, native DeFi, or Toccata as live unless newer primary sources confirm activation. Do not flatten RTD itself into only future oracle work; Hashdag frames base RTD as Kaspa's real-time Bitcoin-style PoW value proposition, with downstream app-level oracle/TangVM/coordination-market systems as extensions.
  • Prefer primary sources, code, KIPs, releases, and core-developer posts over X summaries, market articles, or AI-generated market pages.
  • Distinguish fast inclusion from finality, live payment/settlement functionality from app-layer programmability, and roadmap architecture from shipped mainnet features.
  • Do not reduce Kaspa's speed argument to block rate alone. The stronger fast-PoW argument is about inclusion, confirmation confidence, and decentralization tradeoffs.
  • Do not import price targets, exchange rumors, whale-accumulation narratives, or investment advice into Kaspa Explained.

Publishing Notes

This is a static GitHub Pages site. The domain is kaspaexplained.com.

Preserve:

  • CNAME exactly as kaspaexplained.com
  • robots.txt sitemap URL
  • sitemap.xml canonical URLs
  • clear live/near-term/roadmap/research separation

After pushing, verify the live site before claiming a change is live. GitHub Pages can serve cached pages for a short period after push.