Use documented hosted APIs, public nodes, explorers, and database dumps for quick reads and demos.
Build now
What can you build on Kaspa now?
A build starts where the chain can answer back: network reads, accepted transactions, wallet flows, UTXOs, receipts, and testnet practice. Toccata adds new surfaces. Products still need receipts, tooling, wallets, and users.
Summary: Kaspa builds today are payment, read, receipt, monitoring, API, UTXO, and verification tools. Toccata expands the app rule surface after activation.
Recipes
Small builds that work now
| Build | Status | First proof |
|---|---|---|
| Read current DAG information | Live | Fetch server info, block count, DAA score, or blue score from a node, public node, or documented API. |
| Watch accepted transactions | Live | Listen or poll for accepted transaction IDs and record the accepting block context. |
| Track address UTXOs | Live | Use wallet software, your own node with UTXO index, or a documented hosted API for a prototype. |
| Generate a payment receipt page | Live | Show amount, address, txid, accepted status, source, timestamp, and fallback verification links. |
| Build wallet-confirmation UX | Live | Separate seen, included, ordered, accepted, and confidence-increasing states. |
| Plan a data/indexer path | Live | Use the community API or public nodes for prototypes, then decide when production needs its own node, indexer, archival data, or provider redundancy. |
| Build payload-aware receipts | Live | Use transaction payload docs, accepted-transaction evidence, and explicit source labels so users can verify what the receipt claims. |
| Replay a TN12 covenant proof | Testnet | Record network, txid, accepted evidence, script path, and what remains testnet-only. |
Infrastructure
Pick the evidence path early
Apps need address history, accepted-transaction state, UTXO views, timestamps, pagination, and a plan for stale or unavailable APIs.
Decide when to run Rusty Kaspa, a UTXO index, a transaction indexer, archival storage, or redundant providers.
Show the source used for each receipt or status check, and give a fallback path when one API disagrees or times out.
Builder loop
Turn each build into a source-linked page
Name the user action: send, receive, watch, verify, issue, redeem, refund, or replay.
Show the source: node, API, wallet, accepted transaction, code, release, or testnet proof.
Label it live, testnet, targeted, roadmap, research, wrong, or unsupported.
Name what could go wrong: stale API, unsynced node, wallet support, indexer mismatch, or activation gap.
Make the page short enough to paste in Discord, Reddit, Telegram, X, docs, or a GitHub issue.
Route builders to docs, command-line verification, status, and sources.