Wallets, support tools, exchange flows, receipt pages, node monitors, and source-verifiable reads run on current mainnet today, no fork required.
Build on Kaspa
Build Kaspa apps
Toccata activated at DAA 474,165,565, putting spend limits, escrow paths, asset rules, and proof checks into L1 script rules. You can read the rule before funds move.
Status: payments are live today, and Toccata's rules are active on mainnet. Start with Toccata Explained if the app needs covenants, proof checks, activity lanes, or based-app foundations.
Before pitching: run product claims through Reality Check and protocol/adoption risk through Risks and Open Questions.
Build filter
Start with the user job, then pick the rule
Plenty of Kaspa products need nothing more than payments, receipts, API reads, or better wallet UX. Toccata only matters once your product needs a spend rule the user can inspect before funds move. If you are still deciding whether the network belongs in the product at all, check which payment, custody, and settlement workflows actually gain from Kaspa.
Vaults, escrow, spend limits, controlled assets, proof checks, and safer payouts need Toccata's covenant rules, plus a wallet, an explorer, and an app that actually support them.
Based-ZK apps and vProg-style systems are waiting on tooling, app design, proof paths, and a first cohort of users to build against.
Infrastructure note
Some builders need Toccata readiness work
If you run nodes, wallets, pools, exchanges, explorers, indexers, or custom RPC/protobuf integrations, the Toccata node guide is for you. Everyone else can skip this section.
Run Rusty Kaspa v2.0.1 or newer. The node database upgrade only runs one direction, so operators who need to roll back must budget for a full resync.
Direct RPC submission now runs on the standard-fee floor: 100 sompi * max(compute grams, 2 * transaction bytes). That's a mempool policy number. Consensus rules are a separate calculation entirely.
New integrations need storageMass/storage_mass, transaction version 1, input computeBudget, output covenant, and UTXO covenant_id wherever those fields apply.
Test deposits, withdrawals, mining templates, block submission, indexing, wallet balances, and fee estimation against Testnet-10 behavior, then against mainnet behavior. The two won't match on every edge case.
Primary reference: Rusty Kaspa Toccata node setup guide.
Start here
Pick the next step
Payments, receipts, vaults, escrow, assets, and coordination ideas, sorted by status.
Two side doors: miners can connect an ASIC to their own node with the Stratum Bridge, and anyone weighing chains against each other can compare Kaspa against Ethereum and Solana on execution, liquidity, and app maturity. For the mechanics under the spend rules themselves, read how money that carries a rule with it works.
Before you post an idea publicly
The idea-scoring rubric, user, Kaspa reason, evidence, and status label, lives on Kaspa app ideas. One check is specific to Toccata-era pitches: name the exact rule the idea needs (vault, escrow, asset, proof check, or ordered commitment) and check it against the Toccata status record. A build artifact headed for public copy goes through builder evidence first.
Match the need to the simplest route
| App need | Better first route | Why |
|---|---|---|
| Payment, receipt, balance, withdrawal, or support evidence | Live network work | Current wallets, APIs, nodes, txids, and accepted-transaction checks already handle this. |
| Vault, escrow, spend cap, asset rule, release, refund, or timeout | Toccata covenants | A bounded spend rule is simpler to build and to audit than a full app runtime. |
| One app keeps its own richer state from accepted Kaspa transactions | Based app or replay path | The app proves or replays its own state without needing cross-app atomicity at all. |
| A statement needs proof before settlement | ZK or proof-check path | Proof verification covers one specific statement. Builders still define external anchors on their own. |
| Several independent app states must succeed or fail together | Future full vProgs | App-to-app composition is the later roadmap case. |