Mainnet live
Use only for behavior available on Kaspa mainnet now. Use current code, releases, activation records, or primary protocol documentation.
AI and source discipline
How to talk about Kaspa.
Use this before summarizing Kaspa with an AI tool. Keep mainnet behavior, testnet evidence, targeted upgrades, roadmap architecture, and research in separate buckets.
Main rule
Name the evidence class.
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.
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 recurring caps, 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 mux/worker pattern: a hub routes to worker contracts, workers return state, and timeouts prevent stuck two-transaction flows.
Use ICC for sibling authority
Do not assume nested contract execution. One covenant can authorize another through sibling inputs, covenant IDs, template hashes, and signature semantics.
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