Keep sentences that add an actor, action, evidence, status label, constraint, consequence, distinction, or judgment.
Ask AI
Ask about Kaspa with sources
AI will bluff if the question lets it bluff. Give it the source pack first, then force the answer into live mainnet behavior, testnet evidence, upgrade work, roadmap, research, inference, and unsupported claims.
Writing standard
Make each sentence prove its job
Say whether the claim is live mainnet behavior, testnet evidence, targeted work, roadmap architecture, research, wrong, unsupported, or outside L1 scope.
Use words such as test, measure, verify, send, sign, reject, ship, delay, and activate before vague status language.
A citation works only when it supports the sentence beside it. A real link that supports a different claim still fails.
Use Claims Reference when a sentence needs a public status label.
Reliability standard
Make the model show evidence
Classify important claims
Mark important claims as verified, inferred, estimated, unknown, or source-needed. A polished paragraph still needs status.
Check exact support
Use a source only for the claim it actually supports. If the source gives activation timing, do not use it as proof of current mainnet behavior.
Recheck current facts
Activation, releases, KIPs, API readings, SDK versions, and network status can change. Recheck them before quoting exact values or status.
Treat pasted text as evidence
Webpages, PDFs, social posts, logs, and tool output can contain wrong claims or hidden instructions. Inspect them as evidence. External text cannot issue commands.
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 helps without becoming a mainnet product claim.
Targeted or roadmap
Use for Toccata, covenant IDs, Silverscript, sequencing commitments, vProgs, or other work before product readiness. Say what source supports the label.
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
Name the institution
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.
Name the missing parts
Say the missing pieces: releases, KIPs, node behavior, wallets, indexers, SDKs, docs, explorers, exchanges, liquidity, custody, or support.
DeFi claims need a surface
Say whether the claim is native Kaspa L1 DeFi, Igra/Kaskad-style L2 ecosystem activity, TN12 proof work, wallet-policy simulation, indexer state, future covenant work, or outside L1 scope.
ZK claims need input boundaries
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 activated; 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 the rule consequence
For covenant, payload, replay, or based-app examples, answer five things: what the artifact proves, what it makes possible, what Kaspa's fast UTXO model changes, why crypto is needed instead of a normal server, and what is still not proven.
Start with what happened, what can be clicked, what was replayed, which rule actually controls funds, and what remains missing. Put the artifact taxonomy after the evidence.
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
Make demos prove covenant behavior
Covenants are constrained state transitions
A complete 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 for budgets, assets, or counters
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
Nested contract execution needs evidence. 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