Pay, escrow, cap a budget, move an asset, join a group payment, or trigger a conditional payout.
What to build on Kaspa
Kaspa app analysis starts with money that settles on a fast Proof-of-Work network. Rules for funds, receipts, and shared state come next only when the product needs them.
parallel blocks
ordered into one spend history
Use this mental model before adding receipts, covenant rules, based apps, or later app programs.
App filter
The app leaves inspectable evidence
A crypto app earns its complexity when the user can see custody, ordering, a rule or receipt, and a result another app or wallet can inspect.
The user needs self-custody, public ordering, rules strangers can rely on, or proof that state was not rewritten privately.
Live payment, receipt, covenant spend rule, based-app replay, proof check, or later cross-app action.
Accepted txid, app receipt, replayed state, local reject, wallet warning, source link, or explicit blocker.
The rule changes who can move money or whether strangers can coordinate without trusting one operator.
The app only wants a database, a brand token, or a private score that no outside party needs to verify.
Fast mined ordering helps when the workflow has multiple visible steps before final settlement.
Routes by need
Use the smallest path that changes the user action. Payments and receipts work on current mainnet. Toccata covenants add spend constraints on mainnet. Based apps anchor shared app state to Kaspa ordering. Later app programs handle cross-app actions.
Wallets, payments, receipts, exchange flows, dashboards.
App data, invoices, proof links, and replayable rows.
Vault rules, escrow, caps, refunds, simple controlled assets.
Auctions, coordination, markets, and app-specific state.
vProgs-style actions where several app states update together.
What TN12 covenant tests are teaching
TN12 covenant tests are evidence 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 controlled the spend.
A wallet or app should 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 is blocked. A normal server can display those claims; the crypto-native version puts 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 product path 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. Keep the status label near the demo.
The public TN12 experiment map is a testnet evidence map. Mainnet product claims need mainnet product evidence.
Buildable on today's mainnet
Receipt and transfer paths
Wallets, invoices, tips, remittances, and exchange withdrawal UX that make inclusion, confirmation confidence, and app state understandable instead of just saying "fast."
Self-custody tools
Safer wallets, address books, payment requests, invoicing, accounting exports, and recovery education for users who want direct control.
Miner and node dashboards
Infrastructure that makes mining distribution, node health, propagation, fees, pruning, and network conditions visible to normal users.
PoW-native risk UX
Checkout and exchange flows that show inclusion, confirmation confidence, and risk level as separate states. This is payment-path work. Merchant adoption needs its own evidence.
Payload-aware receipts
Apps can attach compact context to payments, then show txid, amount, address, accepted status, source, and timestamp in a receipt a user can verify later.
Accepted-evidence tools
Dashboards, alerts, and support flows can explain whether a transaction is seen, included, accepted, or still waiting for more confirmation confidence.
Education and proof tools
Visualizers, local node guides, blockDAG explainers, and verifiable references that make Kaspa's current system legible.
Workflow-linked activity
Dashboards that separate user payments, mining behavior, exchange movement, spam, fees, and app tests instead of treating all transactions equally.
What Toccata adds
Toccata is the near-term hard-fork track for spend rules, asset rules, Silverscript, ZK proof checks, sequencing commitments, and vProgs groundwork. Use the timing label once, then focus on the app surface.
For builders, the first 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.
Open Toccata app examples
| Opportunity | What it looks like | Why Kaspa fits | Status |
|---|---|---|---|
| Vaults and wallet policies | Time-locked spending paths, delayed withdrawals, emergency keys, spending limits, and business treasury controls. | UTXO covenants can express constrained asset movement without turning every account into a global VM object. | Post-Toccata opportunity |
| Assurance contracts | Funds move only if enough participants commit by a deadline; otherwise they return. | This maps directly to stag-hunt and public-goods coordination: the rule is credible before everyone acts. | Post-Toccata opportunity |
| Conditional escrow | Milestone payments, disputes, deposits, delivery windows, and refund paths governed by transparent script rules. | Fast payment feedback helps escrow feel usable while covenants keep the state machine constrained. | Post-Toccata opportunity |
| Native assets and access passes | Tickets, memberships, credentials, game items, loyalty points, and redeemable claims with clear custody rules. | Some assets need fast transfer and self-custody before full general-purpose DeFi. | Post-Toccata opportunity |
| Atomic market primitives | Simple swaps, auctions, batch settlement, OTC flows, and intent-style exchange with bounded script behavior. | Kaspa's edge is credible fast ordering; market design uses that and labels immature DeFi paths clearly. | Post-Toccata opportunity |
| Games and state machines | Chess-like or turn-based apps where state is carried through constrained UTXO transitions. | The state discipline is the lesson: registration, player state, game state, move routing, and final settlement. | Post-Toccata opportunity |
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 worry that the operator can censor, reorder, change terms, or disappear.
The 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.
Open group-commitment examples
Public-goods assurance
Projects, research, events, software, or local infrastructure that receive funding once enough participants join under fixed rules.
Real-time auctions
Fast, open auctions for scarce digital goods, access, blockspace-related rights, or services that need ordering and censorship resistance.
Oracle-backed markets
Prediction, insurance, and payment markets that need external data, but where oracle trust, incentives, and dispute paths are explicit.
First-to-know signal markets
Watch miners or other rewarded reporters begin attesting to an event, then surface the earliest credible signal before normal feeds agree.
Machine-to-machine payments
Agents, devices, miners, apps, and services buying resources or making commitments at internet speed with self-custodied funds.
Start with what works today
Live network UX, receipts, and source-verifiable reads 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.
Open capability table
| Capability | What builders can do | Status |
|---|---|---|
| 10 BPS GHOSTDAG payment flow | Fast inclusion, fast PoW user experience, wallets, payments, infrastructure, and clearer confirmation UX. | Live |
| Receipt and payload UX | Payment receipts, compact app context, accepted-transaction checks, support dashboards, and fallback verification paths. | Live foundation; depends on wallet and infrastructure quality |
| Attestation-capable paths | Opt-in event reporting, early external-event signals, oracle experiments, and first-to-know dashboards built by apps. | App-level design over base payment paths |
| MEV-aware ordering or auctions | Protects users who delegate an if-this-then-that strategy from miners or searchers exploiting the same event signal first. | Research / design work |
| Toccata covenants and ZK hooks | Vaults, assurance contracts, state-machine apps, simple assets, bridge foundations, and zk covenant experiments. External-chain or real-world claims still need an anchor such as a light client, finality certificate, accumulated-work view, oracle, reporter set, or dispute process. | activated protocol surface; wallet, explorer, and app evidence still needed |
| STARK-sized proof support | Large validity proofs on Kaspa, with block-size and standard-fee tradeoffs to avoid cheap spam. | TN12 context / mainnet design question |
| Later app programs | Apps that prove their own logic, share Kaspa ordering, feel cohesive to users, and support atomic app-to-app actions in the later roadmap. | Roadmap architecture |
| DAGKnight / higher BPS RTD | Higher-density real-time majority sampling and more internet-round-trip attestation confidence. | Research / future upgrade direction |
Build order
Build in this order: 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.
Open build-order table
| Phase | Build focus | What success looks like |
|---|---|---|
| Now | Wallets, receipt UX, infrastructure, explorers, mining/node visibility, education, confirmation-risk tools. | People can use and understand the live network without trusting one interface. |
| Now: verifiable receipts | Payment receipts, address-history views, accepted-transaction monitors, accounting exports, support tooling, and API fallback paths. | People can use the live network with clearer evidence instead of trusting one interface. |
| Now: L2 ecosystem apps | Igra/Kaskad-style EVM L2 lending and bridge-adjacent app activity, labeled as ecosystem/L2 context. | Readers can see app activity without mistaking it for native Kaspa L1 DeFi, Toccata mainnet activation, or vProgs. |
| Toccata | Covenant examples, vaults, simple assets, escrow, assurance contracts, UTXO state-machine demos, STARK/zk proof experiments, developer docs. | Builders can make small apps without claiming full DeFi is live. |
| Based apps | App-specific state machines anchored to Kaspa ordering, commitments, proofs, settlement, or exits. They can start as deterministic replay and grow into based-zk when proof verification reduces trust or verification work. | Builders can test richer products without waiting for full app-to-app composition. |
| Later app programs | Apps that prove their own logic, share Kaspa ordering, support richer markets, private proofs, app-to-app flows, and canonical bridge design. | The later goal is app composition without asking the base layer to execute every app globally. |
| Research | DAGKnight, 100 BPS sampling, RTD-derived attestations, oracle markets, MEV auctions, TangVM-style flows, public funding markets, and AI-agent commitments. | The broad coordination thesis becomes testable through real products. |
Application-layer references
Open application-layer source list
- Kaspa: Mining the Internet at Tokenize London for Yonatan Sompolinsky's RTD, miner-attestation, internet-money flow, and focus/flywheel framing.
- KASmedia Hong Kong wrap-up for historical context on Michael Sutton's Crescendo/L1-L2 bridge talk, the ZK panel with Hans Moog, and the 2025 discussion around based rollups, state management, and liquidity fragmentation.
- Michael Sutton's vProgs masterclass for apps sharing Kaspa ordering, one-dimensional program space, app-to-app composition, computational DAGs, prover incentives, and sovereignty obligations.
- rusty-kaspa Toccata branch, rusty-kaspa TN12 branch, kaspanet/vprogs, and michaelsutton/argent for current implementation/prototype evidence. Treat branches and prototypes as moving targets.
- TN12 faucet and TN12 explorer for testnet prototyping. Faucet balances, browser checks, and explorer APIs can change; use local TN12 RPC for serious testing.
- KIP-16, KIP-17, KIP-20, and KIP-21 for TN10 implementation evidence. Confirm mainnet activation separately.
- Kaskad and Kaskad docs for current Igra L2 lending context. This is ecosystem/L2 evidence. Native Kaspa L1 DeFi and Toccata-era app claims need separate evidence.
- Michael Sutton's covenant++ and vProgs milestone notes for inline zk covenants, based zk covenants, canonical bridge work, efficient sequencing commitments, and RTD context.
- Michael Sutton's STARK-sized blocks and min-fee notes for the STARK proof, block-size, standardness-fee, and elasticity tradeoffs.
- Kaspa Explained sources for the Kaspa status hierarchy and source list.