Kaspa builder guide.

Kaspa builders should start with the user action: a payment, vault rule, asset rule, market, proof, or later app-to-app flow. Then choose the simplest state model that can support it.

Build rule: start with the smallest working path. Mainnet status still comes from activation, releases, and working applications.

Need terminal commands first? Open Kaspa Command Line From Zero.

Status-sensitive page. Last checked: May 15, 2026. Use current status before quoting Toccata, vProgs, DAGKnight, KRC, native DeFi, or finality claims.

Start with state and proofs.

Match app model to state model.

Covenants are for constrained spend rules: vaults, treasury controls, escrow-like flows, unlock conditions, issuance policy, and small UTXO state machines. One protected state advances one valid step at a time.

Based apps are for richer app state anchored to Kaspa ordering: balances, orders, packs, risk rows, task states, or market state. They can start with deterministic replay over accepted transactions and add ZK only when proof-verified execution, privacy, or trust-minimized bridge logic becomes the product boundary.

Inline ZK is for actions that need their own proof before settlement. Full vProgs are the later app-to-app composition direction, where independent apps can read or call one another in one combined outcome.

Say what the example buys the user.

A builder example should not stop at "the script compiled" or "the txid was accepted." Say the practical job: a budget that cannot be drained at once, an asset that moves only under a controller rule, a game turn that cannot get stuck forever, a payout that can be replayed, or a group payment that refunds if the condition fails.

Use this order before showing artifacts: what landed on TN12, what the reader can click or repeat, what the repo replayed from accepted rows, which rule is script-enforced versus replay-derived or wallet policy, and what remains missing before a real product claim.

Then keep the boundary honest. If the rule is script-enforced, name the script path. If it is wallet policy, planner state, replay-derived state, or testnet-only evidence, say that. The useful implication is strongest when the reader can see both the accepted path and the rejected path.

Use the same template for every covenant example: user job, spend rule, accepted path, rejected path, wallet review field, and remaining blocker. Say "budget that cannot drain at once," "step-by-step workflow," or "asset that needs its controller" before naming the mechanism.

For the public application framing, see what TN12 covenant tests are teaching. For the current testnet examples, open the TN12 experiment map.

Map product ideas to a path.

Pick the smallest path that matches the product. Most first builds should be a wallet/payment path, a covenant-shaped rule, or a narrow based app.

Use the new BUIDL path as the practical start.

Kaspa.org now gives builders a cleaner first mile: try the SDK in-browser, pick an app or infrastructure path, then decide when public access is enough and when you need your own node.

Kaspa.org Build, the official getting-started docs, the community REST API docs, and the Kaspa Developer Platform docs are normal first references. Keep hosted APIs as prototype infrastructure until reliability, privacy, and scale requirements are clear.

Public tools to track.

Start with official docs and examples. Open the full tool list only when you need a concrete implementation reference.

Useful builder surfaces.

Most builders only need one or two of these at a time. Keep the rest as a reference drawer.

Ecosystem projects to inspect.

Use these as references after choosing a build path. They should not be the first thing a new reader has to parse.

What helps before prototyping.

Use TN12 when you need testnet covenant practice. Keep this as setup detail, not the public explanation of Kaspa.

Mainnet builders should use the released mainnet node and normal `kaspa:` addresses. TN12 builders should label every address, token, and transaction as testnet-only.

Prove the state change.

After submit, fetch accepted state and compare the exact result to the thing the app claims happened.

Testnet lesson: teach the verification habit without turning one prototype into a mainnet claim.

Say the stage first.

1. Covenants: nearer L1 state-output path for constrained asset and UTXO-state rules.
2. Based apps: app-specific state anchored to Kaspa ordering, commitments, proofs, settlement, or exits.
3. Inline ZK: specialized proof path for actions whose validity or privacy proof is the product boundary.
4. External anchors: ZK can check a statement about chosen inputs; builders must still define how source-chain roots, prices, events, or attestations become trusted inputs.
5. Based-zk apps: based apps that add proof-verified execution or bridge logic when deterministic replay is not enough.
6. Full vProgs: future app-to-app atomic composition direction, beyond standalone based-app construction.
7. KRC standards: ecosystem token and NFT-style tooling available today through indexed data and wallet support, not native smart-contract activation.

Use the positive stage first. Add caveats only where a reader might confuse builder work with live mainnet functionality.

Builder references.

1. Izio's Kaspa programmability overview for the builder decision tree: covenants, based apps, inline ZK, and future full vProgs.
2. Izio on Covenants for sequential protected-output state, covenant IDs, and the current Silverscript builder reference.
3. Izio on Based Apps for shared-state app architecture and Rust app logic in a managed environment.
4. Izio on Inline ZK for per-action proofs and proof-driven settlement.
5. Izio on Full vProgs for future app-to-app synchronous composition.
6. rusty-kaspa TN12 branch, Silverscript, and TN12 faucet for testnet covenant prototyping context. Treat these as testnet builder tools, not mainnet activation evidence.
7. Kaspa.org Build for the current developer resource index: Rusty Kaspa, WASM SDK, public node access, REST API, Docker, DB dumps, testnet, KIPs, Silverscript, vProgs, community infra, and R&D links.
8. Kaspa Developer Platform docs for hosted address history, transaction acceptance, block-range, KRC20, and node RPC proxy APIs. Treat it as hosted infrastructure, not protocol-status authority.
9. Kaspa docs, especially Getting started, Programmability, Transaction payload, Accepted transactions, and Kaspa node, for current builder workflow guidance.
10. Aspectron RpcClient docs and Aspectron transaction signing guide for the JavaScript SDK request shape used by current builder examples.
11. KasSigner and KasSee for experimental external-signer and watch-only wallet references. Use them for wallet UX and signing-boundary research, not shipped protocol status.
12. Kaspa Explained status and source hierarchy for live/targeted/roadmap/research boundaries.