What should be built on Kaspa?

Use this page by job

Public reader first, builder detail later.

Start with the simplest path.

The order is practical: move money first, attach receipts when the app needs context, add spend rules when funds need constraints, anchor shared app state when many users need the same record, and use later app programs only when several apps must update together.

Current products should improve wallets, receipts, dashboards, confirmation-risk UX, and KRC token/NFT support around the live network. Toccata-style covenants belong to spend limits, vault rules, escrow, simple assets, and bounded UTXO state changes. Based apps come later when shared state must be anchored to Kaspa ordering, receipts, proofs, settlement, or exits.

The app job.

The application case starts with money users can hold themselves. Then come payment receipts, vault rules, escrow rules, assets, and funding rules. Based apps are the next step when an app needs shared state anchored to Kaspa evidence. Later app programs matter when several apps need one combined action that succeeds or fails together.

A good Kaspa app starts with a plain question: does this need self-custodied money, a public ordering record, fast PoW sampling, local UTXO rules, proof-backed execution, or later app-to-app actions? If not, ordinary server state is probably enough.

If an app depends on an outside fact such as a price, weather event, or another chain, it needs an input rule for that fact before settlement can rely on it.

Match the app to the path.

For broader comparisons, use the coin atlas and tradeoff map. This page stays focused on Kaspa-shaped applications.

Reusable app patterns.

Kaspa-native filter.

Start with the properties Kaspa has or is explicitly working toward: fast mined inclusion, UTXO ownership, GHOSTDAG ordering, covenants, ZK verification, sequencing commitments, and apps that can prove what they did.

The filter is simple: who controls the record, who can censor it, who holds the assets, how quickly an action is seen, and whether strangers can commit to rules before trusting one another.

Use Kaspa where fast mined ordering changes the product.

What TN12 covenant tests are teaching.

TN12 covenant tests are useful when they make a money rule visible at the spend layer. Start with what happened: testnet transactions landed, artifacts link to the txids, and replay can explain the resulting state. Then ask which rule actually controlled the spend.

The practical product idea is a wallet or app that can explain the rule before the user signs: this spend is under the cap, this asset has the required controller input, this payout matches accepted evidence, or this withdrawal should be blocked. A normal server can display those claims; the crypto-native version tries to put the money movement and the rule in the same public record.

Keep the evidence classes separate: an accepted TN12 transaction landed on testnet; a local reject failed in a local script or covenant engine; replay-derived state explains accepted rows but does not itself control funds; wallet policy is a signer warning or refusal before broadcast.

The practical direction is not games on chain for their own sake. It is allowance wallets, team treasuries, controlled assets, staged approvals, refunds, and turn-based workflows where the allowed move and the refused move can both be reviewed. Treat this as testnet evidence until mainnet activation, wallet signing, audits, and production replay catch up.

The public TN12 experiment map is a testnet evidence map, not a mainnet product page.

Community-built apps.

Kaspa's app layer can come from many builders: wallets, dashboards, receipt flows, covenant examples, vaults, funding tools, coordination tools, docs, and analytics around the same base asset. The standard is concrete: build something people can use, label the stage, and check security before asking users to trust it.

Possible Kaspa versions.

Use the short list first: wallets, payment receipts, vaults, escrow, funding rules, simple assets, auctions, market replay, coordination apps, and agent-payment flows.

A based app is an app whose state is tied back to Kaspa ordering, commitments, proofs, settlement, or exits. It may use ZK later, but it can start as accepted transactions plus deterministic replay.

Later app programs are the composition path: one user action can update several app states together, with the combined action succeeding or failing as a unit.

Buildable on today's mainnet.

What Toccata would add.

Toccata is the near-term hard-fork track for spend rules, asset rules, Silverscript, ZK proof checks, sequencing commitments, and vProgs groundwork. It should be described as future mainnet capability until activation is confirmed.

For builders, the first useful testnet products are simple and auditable: a vault policy, an assurance contract, an escrow, or a constrained asset rule. The hard part is the gap between a good UI and an enforced covenant: address generation, faucet funding, a synced TN12 node, UTXO-indexed balance checks, Silverscript compilation, signing, broadcast, and explorer-visible outputs.

Choose the app model first.

Choose the smallest model that can honestly run the product. Use covenants for bounded spend rules, based apps for shared app state, inline ZK when a proof is the product boundary, and later app programs for cross-app atomicity.

The unusual app job is rules strangers can rely on.

RTD and Staghunt framing point to markets where people need credible commitment before they act. A normal website can collect promises, but users may still worry that the operator can censor, reorder, change terms, or disappear.

The practical first version is simple: collect conditional commitments, group compatible commitments, run a transparent solver, prepare settlement or refunds, and replay the accepted evidence. The harder research target adds privacy, reusable capital, solver incentives, censorship resistance, and atomic execution.

The hard parts are concrete: event sources, incentives, anti-MEV design, scheduling, disputes, and implementation. Start with transparent commitments before claiming private or atomic coordination markets.

Start with what works today.

Live network UX and KRC ecosystem tooling are the starting point. Covenants, ZK hooks, later app programs, and higher-density RTD ideas belong in the later build path until their activation evidence changes.

Coordination app examples.

These are examples, not a second homepage. Start with the checklist below, then open the list if the app really needs group commitment rules.

App idea checklist.

1. Needs a neutral shared record. The app gets meaningfully better when no single operator controls the database.
2. Benefits from fast mined ordering. Real-time Proof-of-Work feel changes user experience, risk, or group action.
3. Uses UTXO constraints well. The app can be modeled as bounded state transitions, vaults, commitments, assets, or payment flows.
4. Names off-chain assumptions. If the app depends on outside facts, it names the source root, oracle, reporter, light-client, challenge, and dispute assumptions clearly.
5. Can start narrow. The first version solves one concrete problem before claiming to replace finance, identity, games, or law.

Build order.

Build in this order: useful wallet and payment paths, small covenant-shaped products, then richer based-app or later app-program paths only when the product needs shared state or composition.

Use these as maps, not investment recommendations.