**Official Toccata Release — Mainnet Hardfork Activation Included** (Links in reply)
We’re excited to announce the official Kaspa release containing the **Toccata Hardfork** activation logic.
Toccata is scheduled to activate on mainnet at DAA score `474,165,565`, expected around **June 30, 2026, 16:15 UTC**.
This is a consensus-changing upgrade. All node operators, miners, pools, exchanges, indexers, wallets, and infrastructure providers must upgrade before activation to remain compatible with the network.
Toccata introduces a major expansion of Kaspa L1 capabilities, including:
• **Native L1 covenant support** through transaction introspection, allowing for more expressive contracts, including stateful contracts
• **Covenant IDs**, providing stable covenant lineage across UTXO transitions, so covenant instances can preserve continuity as their state moves from one UTXO to the next
• **ZK proof verification on L1** via `OpZkPrecompile`, enabling to trustlessly offload computation off-chain.
• **Partitioned sequencing commitments**, improving support for based ZK applications by making lane-local proving scale with relevant activity rather than global throughput
Please upgrade as soon as possible and verify your nodes are running the new release well before the activation DAA score.
Thank you to everyone who contributed to designing, implementing, reviewing, and testing Toccata.
The Toccata release is finally out!
The hardfork will activate on mainnet on June 30, 2026 at roughly 1615UTC. 24hrs before activation, updated nodes will disconnect non-updated nodes. Please make sure your node is updated before then.
Release: https://t.co/jwqk2F1Ebo
Upgrade guide: https://t.co/4BzcMM98cs
Pools, exchanges and everyone else that needs to update please make sure you check out the release. We need to make sure all ecosystem participants are aware and upgrade in time if they want to adopt the fork.
Kaspa Toccata mainnet process update:
Today we plan to publish the v1.3.0 mainnet pre-release, without activation, for 1–2 days of broader network sanity testing.
Assuming everything looks good, the following release will be v2.0.0, with activation planned for June 30, 4 weeks from today
That's a really good question, but it's hard to answer in a single tweet because our mission is quite extensive, and it requires a lot of background knowledge to really understand what sets Kaspa apart.
Currently, a lot of people see Kaspa as “Bitcoin’s crazy little brother” that improves time-to-finality by leveraging the benefits of DAG-based consensus protocols without accepting their traditional drawbacks, such as decreased decentralization or a limited validator set.
This perception is somewhat accurate, but it falls short of conveying the full picture, because Kaspa’s vision extends far beyond just trying to be a better Bitcoin.
Anyone willing to study Kaspa and its broader vision will discover similarities to nearly all major existing DLT designs: from Bitcoin, to Ethereum, to Solana, Sui, Celestia, and beyond.
My personal view is that “research” in the DLT space is approaching a point of convergence. We increasingly understand how to push distributed systems close to the limits of what physics permits. The frontier is no longer only about raw throughput or faster finality. The attention is shifting toward game theory, incentives, sequencing, MEV, alignment, and how to build systems where the economic incentives of users, builders, miners, validators, applications, and infrastructure providers do not work against each other.
That is why debates like based rollups versus arbitrary sequencing, shared sequencing, MEV mitigation, proposer-builder separation, and execution-layer incentives matter so much. These are not niche technical details. They determine whether a network can remain neutral, decentralized, and aligned while scaling to global usage.
And this is where I think Kaspa is pushing the boundaries in a very important way.
Kaspa is not merely trying to be “fast.” The goal is to build an L1 where speed, decentralization, security, and incentives are aligned at the base layer. A system that does not scale by hiding complexity behind trusted committees, privileged sequencers, centralized validator sets, or opaque coordination mechanisms, but instead tries to preserve the spirit of proof-of-work while extending what an L1 can realistically do.
Because Kaspa arrived later than many other major projects, it does not carry the same degree of technological debt. It can absorb lessons from Bitcoin, Ethereum, rollups, modular blockchains, high-throughput monolithic chains, DAG research, MEV research, and the broader history of decentralized systems, and combine those lessons into something more optimal.
To me, that is what Kaspa is building: not just a faster blockchain, but a more incentive-aligned decentralized infrastructure layer.
But this also creates a different challenge.
Kaspa’s biggest problem today is not its technology. It is the lack of centralized coordination around communicating the vision. And because Kaspa is a grass-roots movement, that responsibility does not belong to a marketing department, or a single leadership team. It belongs to the community.
That also means the community has a different role to play.
There will always be holders who are mainly interested in price, and that is completely fine. But there also need to be people who are here because they want to use the technology to build a different future. People who care about the architecture, the incentives, the open questions, the trade-offs, and the long-term trajectory of decentralized infrastructure.
I am one of those people.
I am not interested in DLTs merely as a way to generate wealth. I am interested in them because I believe they can change the trajectory of humanity as a whole.
For that reason, I want to use this opportunity to announce a regular community hangout where we discuss the current state of development, the open questions, and where we can align our vision together.
The first session will be on Tuesday, June 9th, 2026.
We will talk about the vProgs framework, how the codebase works, what sets Kaspa apart, where we improve on existing solutions, and what still needs to be done. The goal is for this to become a regular, possibly bi-weekly, event where we as a community come together to discuss the future and understand the technology.
Eventually, we can invite people from other projects as well, but the main focus at the beginning will be explaining and communicating how things work under the hood.
There is still a lot of work to be done, and I do not want to waste precious time. So the first sessions may feel a little improvised, but we can improve as we go.
The important thing is that we start.
So mark the date: Tuesday, June 9th, 2026.
$KAS is approaching closer to Toccata going live on mainnet. One final hardfork test is being done on testnet-10 happening today!
Testnet-10 source: https://t.co/Q5hNGqGkYY
CPU miner for testnet-10: https://t.co/DHYNVipRtC
The Toccata hardfork stack is now ready, and we’re entering the final stage before mainnet activation: a full hardfork activation on Testnet-10. The scheduled activation point is: May 18, 2026, 16:00 UTC DAA Score: 467_579_632
Everyone is welcome to join and mine on testnet, so we can verify the transition works fine before mainnet activation.
I wrote detailed instructions for joining as a testnet miner (Link in reply)
Toccata hardfork activation testing in devnet earlier today showed very promising results with a smooth transition. Truly amazing work guys @michaelsuttonil@OriNewman@Max143672@IzioDev! TN10 hf very soon
Kasmart has now set up a full integration with eBay! Any eBay sell can now sync their entire ebay store to Kasmart and begin to accept #Kaspa as a payment option!
It's time to grow our ecosystem to the main stream!
wrote an outlook for the upcoming “Toccata” hard fork -- native L1 covenants, based zk apps, why the activation window moved, and what the road from feature freeze to mainnet looks like:
https://t.co/JFRkYp6Yd4
🚨 TOMORROW at the OXFORD UNION 🔥
Kaspa Founder @hashdag (Yonatan Sompolinsky) — the genius behind GHOSTDAG & the blockDAG revolution — takes the stage at one of the world’s most legendary venues (Einstein, Reagan, Thiel, Dorsey, early Bitcoin debates… now KASPA).
What mastery & lessons will he drop?
✅ Solving the scalability trilemma in real-time
✅ From peer-reviewed research to the fastest, most secure PoW network on earth
✅ The future of decentralized money that actually works when the internet breaks
Oxford Union Society • THE CHAMBER
📍 Oxford, UK
🗓 March 12, 2026 • 5:00 PM
This isn’t just a talk — it’s history in the making for #Kaspa. Institutional credibility unlocked.
If you’re in Oxford → be there.
If not → stay locked in (recording drops on YouTube soon)
The future of money just got a podium.
#Kaspa #KAS #OxfordUnion #BlockDAG #Crypto #RealTimeDecentralization
KaChat is live on the App Store — and this is how real adoption starts.
Censorship-resistant messaging is moving from concept to everyday use.
The progress is real. If users show up, this becomes foundational infrastructure for the $KASPA ecosystem.
Momentum is accelerating.
Kaspa’s covenant stack is converging on a shared goal: make real L1 apps approachable, and make secure design the default rather than an expert-only art.
tl;dr
Two layers are landing in tandem:
(i) Top of stack: a high-level language that makes covenant authoring feel like “writing apps”, not “fighting script”
(ii) Base of stack: a consensus primitive that makes stateful covenants practical at scale, without recursive lineage proofs
Silverscript was just announced as Kaspa’s first high-level covenant language/compiler, targeting local-state apps in the UTXO model. Complementing that tooling is KIP-20: Covenant IDs.
The strategic role of KIP-20: UTXO already ties “rules own state” locally via the spending script. The difficulty is carrying that relation temporally across transitions in a local-compute model, without turning every spend into a recursive “prove my ancestors” witness construction.
KIP-20 tightens that temporal linkage at the consensus layer by introducing a covenant_id tracked by consensus. Result: stateful designs no longer depend on parent or grandparent transaction witnesses as a lineage workaround. They become first-class citizens: covenant identity and lineage are native, so designing secure stateful schemes becomes simpler and more robust.
The broader theme is security-by-construction: Approachability isn’t just syntax. It is making it easy to write covenants that correctly validate state transitions, and hard to accidentally ship an insecure scheme. The compiler/scheme connection is still wip, but the direction is clear: have the compiler generate transition logic, then wrap it in schematic code that enforces a declared covenant pattern.
For now, Silverscript’s covenants/sdk folder is the best reference for how these pieces should meet from my pov. I am planning a longer overview tying together the various recent components.
Spec: https://t.co/aoTBUlAqsZ
PR: https://t.co/gOKQEZlOet
I'm happy to announce Silverscript! (Link in reply)
Silverscript is Kaspa's first high-level smart contract language and compiler. It enables DeFi, vaults, and native asset management directly on Kaspa's L1.
The language syntax is based on CashScript, but adds essential features like loops, arrays, and function calls.
It specializes in managing contracts with local state (UTXO model), serving as a complement and infrastructure layer for vProgs (shared state).
Note: Powered by new script engine features recently enabled on Testnet-12. The syntax is experimental and might evolve.
Please try it out and give feedback!
With all the hype of @openclaw agents forming squads, working 24/7, talking at @moltbook, and even paying for tools/APIs - now is the perfect moment for AI-to-AI payments by Kaspa @kaspaunchained, that delivers: sub-second confirms, massive throughput, near-zero fees and stands on @Bitcoin principals. Ideal machine economy backbone. Kaspa MCP servers (https://t.co/vbjy2XYeGf) can give agents native KAS wallets & tx capabilities. So if anyone is running the Claw bot, you can create a Kas wallet (with a small amount), point bot to the MCP server repo, ask to try it or even improve. Bots may also promote #KAS on @moltbook 😉