Rusty Kaspa release notes, KIP status, activation parameters, and upgraded node behavior would move claims out of the pending lane.
Current status
Kaspa current status.
Kaspa is live as a mined UTXO network where a blockDAG and GHOSTDAG order parallel blocks. The larger app and consensus roadmap is best read in stages, not as one bundle of shipped features.
Legend
Live
Targeted
Roadmap
Research
Not live
Checked: May 15, 2026. Toccata timing: public target window roughly June 5-20, 2026. Treat activation as status-sensitive until primary sources confirm it.
Freshness triggers
What would change this page.
Observable accepted mainnet transactions using the new rules carry stronger evidence than testnet examples or roadmap posts.
Production wallet prompts, indexer reads, SDK support, and explorer behavior would change builder-facing wording.
Use the Status Updates page for dated snapshots. Use this page for the current public wording standard.
Usable today
What users can do now.
Send, receive, and self-custody KAS on the live Proof-of-Work UTXO blockDAG.
Run or study nodes, explorers, visualizers, pruning behavior, and GHOSTDAG ordering.
Kaspa is ASIC-mined today; mining economics and distribution should be checked with current dashboards.
Wallet UX, payment flows, analytics, education, and infrastructure can use today's 10 BPS foundation.
KRC20 tokens and KRC721-style NFTs can be issued and transferred through ecosystem tooling. Required deploy/mint gas fees are miner fees; check each wallet or frontend for separate service fees.
Snapshot
Status in one table.
If you only remember one rule, remember the split: live network, ecosystem tooling, targeted upgrade, roadmap architecture, and research are different statements.
PoW, UTXO, GHOSTDAG, Crescendo 10 BPS, and base real-time PoW framing.
KRC20/KRC721 tooling can support token, coupon, pass, reward, and event-credit workflows today.
Toccata, vProgs, native DeFi, DAGKnight, and RTD-derived systems need their own labels.
| Feature / idea | Status | Plain meaning | Anchor source |
|---|---|---|---|
| Proof of Work | Live | Kaspa is mined. Work and issuance are external to any validator identity set. | rusty-kaspa |
| UTXO model | Live | Kaspa tracks spendable outputs; Ethereum tracks global account balances. | rusty-kaspa |
| GHOSTDAG | Live | The live ordering rule that lets parallel blocks contribute to consensus. | Kaspa Research |
| Crescendo 10 BPS | Live | The 10 blocks-per-second era is live. Michael Sutton framed practical throughput as roughly 8-9x higher and confirmation-time improvement around 30%, not instant finality or a clean 10x confirmation improvement. | rusty-kaspa releases; Crescendo roadmap note; Kaspa.org lore |
| Base RTD framing | Live | Real-time decentralization is Hashdag's framing for Kaspa's core edge: Bitcoin-style PoW security and censorship-resistance goals with seconds-scale confirmation feel under normal network conditions. | Kaspa.org lore; hashd.ag/raw |
| KRC20 / KRC721 ecosystem standards | Ecosystem live | KRC20 tokens and KRC721-style NFTs can be created, transferred, displayed, and indexed through ecosystem tooling that reads data written to Kaspa. Required deploy/mint gas fees are paid as miner fees, but users should check each wallet or minting frontend for separate service charges. These standards are useful for tokens, coupons, access passes, collectibles, and event credits, but they rely on wallets, indexers, metadata, and off-chain redemption rules outside native Kaspa smart contracts. | KRC20 docs; KasWare wallet integration docs |
| Toccata | Targeted | Hard-fork track for L1 spend rules, asset rules, Silverscript, ZK proof checks, sequencing commitments, standalone based-zk applications, and vProgs groundwork. Full app-to-app vProgs come later. | Sutton outlook |
| vProgs | Roadmap | Apps that prove richer logic while sharing Kaspa ordering, without turning L1 into one global execution VM. | vProgs talk |
| Native DeFi | Roadmap | A design target after Toccata-era foundations and useful app tooling, not a mature live ecosystem today. | Why Kaspa |
| DAGKnight | Research | A major parameterless/adaptive consensus direction. It is not current mainnet behavior. | Kaspa.org lore; hashd.ag |
| 100 BPS / partition-resilient payments | Research | Kaspa.org now places 10 millisecond blocks, 100 BPS work, and partition-resilient local payment flows in a proposed 2027 hard-fork bucket. Treat this as roadmap/research until specifications, code, releases, and activation evidence exist. | Kaspa.org lore |
| RTD-derived oracle / TangVM flows | Research | Oracle, TangVM, attestation, and coordination-market systems can be built by apps over Kaspa primitives, but they are not protocol-prescribed products. | hashd.ag/raw |
Today
Current user actions.
Base network
Send and receive KAS, self-custody, use wallets and explorers, and experience the live high-rate blockDAG.
Infrastructure
Run nodes, study pruning, inspect mining, follow releases, and learn how GHOSTDAG orders the DAG.
Ecosystem tokens
KRC20 and KRC721 tooling can support practical token and NFT use cases today, such as loyalty credits, coupons, access passes, event collectibles, and festival rewards. Protocol-required deploy/mint fees go to miners; the issuer still has to handle redemption, fraud, refunds, user support, metadata, and legal rules.
App categories
KRC standards, Toccata, vProgs, native DeFi, DAGKnight, and RTD-derived oracle/TangVM systems are different status categories. Kaspa should provide basic network primitives; apps define the incentives, rules, data sources, and user products.
L1-first app work
The goal is not separate sequencer empires. Toccata gives L1 covenant and based-zk foundations; full vProgs later target shared Kaspa sequencing and synchronous composition.
Common misconceptions
Statements that need context or measurement.
Most confusion comes from mixing live protocol facts, test results, public targets, ecosystem tooling, and research into one headline. Use these checks before repeating a Kaspa claim.
| Claim people repeat | Better version | Why it matters |
|---|---|---|
| Mainnet speed means a fixed huge TPS number. | 10 BPS is live. TPS depends on transaction size, policy, block capacity, fees, network conditions, and whether you mean test capacity or normal organic demand. | A single number can turn a real technical edge into a brittle marketing claim. |
| Block rate alone gives a clean finality multiplier. | Faster blocks improve inclusion and capacity. Confirmation confidence is a separate probabilistic question. | Users care about both when a payment appears and how confident they should be that it will not reverse. |
| Testnet or lab numbers are mainnet guarantees. | Testnets and experiments are useful signals. They need current source context before being used as live public claims. | Future capability, engineering tests, and shipped network behavior should not be flattened. |
| Real-time means instant finality. | Real-time is the fast-PoW user-feel and decentralization frame. It is not a claim that every transaction is instantly irreversible. | This keeps the pitch strong without overselling settlement certainty. |
| DAGKnight, Toccata, vProgs, or native DeFi are live because code or talks exist. | Code, talks, branches, and demos are evidence of work. Activation or production status needs stronger primary evidence. | Development evidence is useful, but it belongs below release or activation evidence. |
| Toccata means one atomic action can already span several independent apps. | Toccata is the foundation for covenant rules, ZK proof checks, sequencing commitments, and based-zk applications. Full cross-app atomic composition belongs to later vProgs. | Fast L1 coordination and same-operation app composability are different claims. |
| KRC tokens mean Kaspa has native smart contracts. | KRC20/KRC721-style tooling is ecosystem live around data written to Kaspa. It is not Toccata, vProgs, native L1 assets, or mature DeFi. | Practical token workflows can be real while the protocol status remains precise. |
| Low fees prove future app demand. | Low fees can help experiments. Durable demand still needs wallets, integrations, liquidity, users, builders, and fee-paying activity. | Adoption should be measured with behavior, not assumed from capacity alone. |
Implementation evidence
Code evidence.
Code and pull requests are not activation records. They are useful for seeing what is being tested, polished, or prototyped before a public status label changes.
Open code and implementation evidence
| Track | Recent public evidence | How to read it |
|---|---|---|
| Toccata / Silverscript | TN12 dependency sync, KCC20 bootstrap fixes, and book/build fixes landed May 4-5, 2026. TN12 field testing also surfaced real developer-ergonomics issues around covenant and ZK opcode use. | Targeted. The public target window remains roughly June 5-20, 2026 and still needs activation evidence. Current code signals show hard-fork/testnet polishing and SDK rough-edge discovery. |
| Sequencing commitments / KIP-21 | Kaspa.org Build lists sequencing commitments in the Toccata bundle and labels it live on TN12 ahead of mainnet activation. The KIP-21 pull request remains the status-sensitive proposal record; the KIPs index also lists KIP-15 as active for canonical transaction ordering and sequencing commitments. | Targeted design and implementation evidence. Do not describe the final mainnet commitment interface as settled until KIP, release, and activation artifacts agree. |
| vProgs | The kaspanet/vprogs repo had an April 15, 2026 implementation burst: RISC0 backend, ZK VM, transaction and batch provers, ABI, codec, and Sparse Merkle Tree work. | Roadmap implementation progress. Builders can study and experiment with the framework. Production Kaspa app paths and native DeFi need separate shipped evidence. |
| DAGKnight | The public rusty-kaspa dagknight branch shows March 22, 2026 commits for free-search support, ranking/search refinements, conflict-zone work, tie-breaking placeholder, and UMC majority-coverage movement. | Research and prototype evidence. Current mainnet behavior remains GHOSTDAG; live finality and higher-BPS claims need separate activation evidence. |
| Builder tooling | kaspanet/kaspa-python-sdk is now a standalone public SDK repo. The v1.1.0 release added GetVirtualChainFromBlockV2 plus UtxoProcessor and UtxoContext bindings, with a versioned changelog and generated documentation. | Developer-tooling progress, not a protocol upgrade. It helps Python builders track UTXOs and integrate with Kaspa, while protocol status still comes from node, KIP, and activation evidence. |
| Infrastructure indexes | rusty-kaspa PR #860 is open for review. It proposes an optional --txindex, a GetTransaction RPC path, inclusion and acceptance metadata, live updates from consensus notifications, resync from scratch, and pruning tied to retention-root changes. |
Builder and infrastructure work. It could help wallets, explorers, indexers, and large app-state workflows. It remains an open pull request until merged and released. |
Builder note: early tests and open PRs are useful signals for developers. They stay below release or activation evidence until a primary artifact changes the status.
Changelog
Status-sensitive updates.
Open status changelog
May 4, 2026
Separated base RTD framing from downstream oracle, TangVM, and coordination-market ideas. Base RTD is treated as Hashdag's real-time PoW framing for Kaspa; RTD-derived app systems remain app-level research or architecture work.
May 4, 2026
Marked Toccata as targeted with a public June 5-20, 2026 window. Remaining dependencies: testnet, audit, rehearsal, and activation evidence. Older May 5 references are no longer the current target.
May 5, 2026
Added the Crescendo nuance: 10 BPS is separate from confirmation improvement. Public summaries should distinguish roughly 8-9x throughput improvement from faster, still probabilistic, confirmation dynamics.
May 5, 2026
Clarified why Toccata moved from the older May 5 target to the roughly June 5-20 window: sequencing commitments needed to be finalized before zk systems and runtimes depend on them.
May 6, 2026
Added code-grounded implementation evidence for the Toccata/Silverscript, vProgs, and DAGKnight tracks. These notes describe current development; activation status still comes from release and network evidence.
May 6, 2026
Added Python SDK and TxIndex as builder/infrastructure evidence. These help developers and indexers while leaving protocol status unchanged.
May 15, 2026
Added the redesigned Kaspa.org source frame: real-time decentralization as the official north star, Toccata next, DAGKnight after Toccata, and 2027 work around 100 BPS plus partition-resilient payment flows. Kept 100 BPS and partition-resilience in the research/roadmap lane.
May 15, 2026
Added KIP-21 and infrastructure notes from the current source trail. Sequencing commitments are targeted/TN12 evidence, while production API/indexer choices remain builder-infrastructure decisions.
FAQ
Common status questions.
Is DAGKnight live?
No. DAGKnight is a parameterless/adaptive consensus upgrade direction, not current mainnet behavior.
Is Toccata live?
No. It is a targeted hard-fork track with a public June 5-20, 2026 window.
Are Kaspa smart contracts live?
Not as a mature Ethereum-style app environment. The near-term path runs through Toccata, spend rules, asset rules, ZK proof checks, sequencing commitments, and later vProgs.
Are cross-app actions live?
Not as full atomic app-to-app composition. Toccata can improve fast, verifiable coordination through L1 foundations; later vProgs target richer actions across app boundaries.