Keep sentences that add an actor, action, evidence, status label, constraint, consequence, distinction, or judgment.
Ask AI
Ask about Kaspa with sources.
Pick a question, include the source pack, then open your AI tool with a prompt that separates live mainnet behavior, testnet evidence, targeted upgrades, roadmap work, and research.
Status-sensitive page. Last checked: May 15, 2026. Use current status before quoting Toccata, vProgs, DAGKnight, KRC, native DeFi, or finality claims.
Writing standard
Make each sentence prove its job.
Say whether the claim is live mainnet behavior, ecosystem tooling, testnet evidence, targeted work, roadmap architecture, or research.
Use words such as test, measure, verify, send, sign, reject, ship, delay, and activate before vague status language.
The repo-level copy rules live in COPY_STYLE.md. Use Claims Reference when a sentence needs a public status label.
Prompt builder
Open your AI with the right context.
Prompt is ready. Opening a tool also copies it.
Main rule
Name the evidence class.
Mainnet live
Use only for behavior available on Kaspa mainnet now. Use current code, releases, activation records, or primary protocol documentation.
Testnet evidence
Use for TN12 or other testnet work with accepted transactions, artifacts, and commands. Testnet evidence is useful without being a mainnet product claim.
Targeted or roadmap
Use for Toccata, covenant IDs, Silverscript, sequencing commitments, vProgs, or other work before mainnet activation. Say what source supports the target.
Research
Use for architecture, product ideas, oracle designs, coordination markets, or future app patterns that do not yet have live or testnet proof.
Plain language
Say the real requirement.
Do not say "institutional readiness"
Say which actor needs what: an exchange needs node stability, wallet integration, liquidity, legal review, and support; a fund needs custody, reporting, audit trails, and risk controls.
Do not say "ecosystem maturity"
Say the missing pieces: wallets, indexers, SDKs, docs, explorers, exchanges, liquidity, merchant tools, custody, or support.
Do not say "DeFi is live"
Say whether the claim is KRC ecosystem tooling, TN12 proof work, wallet-policy simulation, indexer state, or future native covenant work.
Do not say "ZK proves the real world"
A ZK proof can prove computation over inputs. It does not prove that a real-world price, event, identity, reserve, or legal claim is true.
Kaspa framing
Start from the job.
Kaspa is best explained as a mined shared record that aims to feel closer to real time without becoming one operator's database. From there, explain the job: payments, records, vault rules, assets, commitments, app-state anchors, or proof verification.
Keep the split clear: Kaspa mainnet is live; Toccata-era programmability is targeted; TN12 proof labs are testnet evidence; coordination markets, based apps, and advanced covenant systems need their own artifacts before becoming product claims.
Implication discipline
Explain why the rule matters.
For covenant, payload, replay, or based-app examples, answer five things: what the artifact proves, what it could make possible, why Kaspa's fast UTXO model matters, why crypto is needed instead of a normal server, and what is still not proven.
Do not start with the artifact taxonomy. Start with what happened, what can be clicked, what was replayed, which rule actually controls funds, and what remains missing.
Keep the everyday implication close to the technical label. Start with the job: a budget that cannot drain at once, a step-by-step workflow that can recover, or an asset that only moves with its controller. Then add the technical label only when it helps a builder find the source artifact.
SilverScript and app lessons
Do not build shallow demos when the target is covenants.
Covenants are constrained state transitions
A serious example should show the input rule, output rule, continuation state, and what spend path is rejected. A P2PK wrapper with one happy-path txid is only a primitive.
Use DECL state when state matters
For budgets, assets, or counters, use explicit state, `readInputState`, `validateOutputState`, covenant IDs, and continuation outputs where tooling supports them.
Split complex logic into roles
For chess-like or game-like systems, study the step-workflow pattern: a hub routes to smaller worker contracts, workers return state, and timeouts prevent stuck two-transaction flows.
Use controller inputs for authority
Do not assume nested contract execution. One covenant can authorize another through a sibling input, covenant ID, template hash, or signature rule.
Prove state before live claims
Compile the script, prove local state/output behavior, prove the signature-script path, then submit only through a route that preserves every required transaction field.
Before publishing