If you had unlimited resources, what would you want to create the most on Kaspa?

I love to hear Twitter drama around Fable 5 being blocked, while opening Vim.

I was fortunate enough to witness the process behind this upgrade up close. Half a year ago, the only thing we knew was that Kaspa had to become programmable, ASAP. This notion matured into a surprisingly complete and elegant solution in a very short period of time. Building a development framework is a massive task, so the first attempts were to harness KIP-16's ZK verification opcodes to tap into existing ZK development frameworks, but we did not find a good enough fit. One weekend Ori sat down with some leftover tokens, and Silverscript came out the other side. The project grew quickly, and the compiler now enables a wide range of applications to be written and deployed directly on Kaspa in a high-level language (thanks to KIP-17 and KIP-20). KIP-21 deserves its own post, but it allows for complex ZK-based applications and is a fundamental component of the full vProgs solution. Together, all these turn Kaspa into an impressively expressive programmable money layer. From simple vaults, through basic contracts to complex multi-contract applications, alongside privacy apps and scalable batch-proving-based applications. Toccata is the outcome of pure R&D -- deep research and hardcore development, done fast and in parallel (how fitting). There’s still much work to be done to make the new capabilities more approachable, but it’s hard to understate the power, elegance, and completeness of what the best money layer in the world will soon allow us to express. @michaelsuttonil @Max143672 @OriNewman @IzioDev - Watching you guys work has been a masterclass. Thank you.

**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.

pre-release: github.com/kaspanet/rusty-ka… discord: discord.com/channels/5991532… pub rnd: t.me/kasparnd/10433/14558

Just saving this here to document a story and as a self reflection on whether AI is really making me more productive Yesterday morning I found a way to complete the new HVM approach, that is much faster than before. I spent a few hours writing a spec, and then used Opus to implement. About 3k lines of C code later, everything worked and performance was incredible: 5x faster than HVM4 (stable at ~10x now). So, in one day I had outclassed HVM4. Incredible. I'd never have implemented that so fast manually. Now, enter today. I want to turn this into a real thing, but I haven't fully read the 3k lines yet. So, how do I trust it? I spent the whole day auditing the code. With AI. Several bugs found, most minor like forgetting to collect() some argument. But then I stumble upon this: λ{ inl: 1 ; inr: 1 } This was a test. But wait. This is matching on inl/inr. So the branches should receive the value of the Either. But they were numbers instead. Numbers aren't functions. This makes no sense. So why this is a test? It then stuck me. The AI completely misunderstood how function arities work. It literally assumed for no good reason that HVM5 was supposed to handle under/over-applied functions. For no good reason. I never wrote that. It never asked either. It just kinda thought "HVM is weird in some aspects, this might be one of them..." - and then it went on to implement a massive system to handle cases that should never happen to begin with. And all of that code is obviously wrong because it should not even exist. It is wrong. It is damage. And it is there. But it isn't too bad either. I just told Opus that it was wrong. Perhaps not so politely. And it solved it just fine. But then this begs the question. I spent ~20 hours in this file, and it is STILL not done. I went from 0 to 95% in the first 5 hours. Yet, 15 hours later, it is still not 100%. I suppose that is the real effect of using AI. If I had just written the C file manually in the last two days, would I not be further than where I am *right now*? Surely, the first version would have taken much longer to drop. But when I'd finish writing all that code, there would be zero, literally zero retarded shit. And, just today, I caught 5 or 6 retarded shit. And the worst part is: I don't know what the number of retarded shit left is, but I'm afraid it is >0. So if I have to read it all, review it all to ensure there is no retarded shit... what did I achieve by using AI, other than that dopamine anticipation?

👀

It's very satisfying to progressively assemble pieces of the software you love. 1 year ago I only knew one Kaspa surface layer and today I'm starting to feel confident in many of them. I didn't fully realize the deepness, nor how big I would progress in my beloved field.

With AI what would have normally been 2 hours of study, 2 hours of white board, and about 6 hours of programming has been compressed into 7 2 hour sessions that have gone in the wrong direction. Truly alien technology

After some more correctness fixes, pnpm in rust is even faster

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

looking into PQ upgrades will be in the coming months after toccata activates

The thesis is simple: 5 kas per second for filling 10 blocks will only happen with real usage demand of 3k tps (or 10 stark proofs). I don’t think operators and miners would/should care about the worst-case double disk usage with such adoption (which also means capital flowing in) And like explained in the gist, future upgrades will handle this more elegantly and without increasing tps or disk usage.

I wrote a short gist about this a ~week ago: gist.github.com/michaelsutto… tl;dr - STARK proofs require double the byte-size of the current Kaspa block limit (125kb→250kb) - block elasticity is not easy to implement and needs more focus DK (hence does not belong in Toccata) - I think doubling the disk requirements (in worst-case usage) requires increasing the min fee ratio 10-100x so that max-throughput usage is organic and economic, and not driven by stretch testing

I wrote a PoC token contract in Silverscript, currently called DOG20 (better name ideas are welcome). It supports token ownership by 3 kinds of entities: 1. Public keys — like any regular Kaspa address. 2. P2SH addresses — which means ownership by a stateless contract, e.g. multisig. 3. Covenant IDs — which means ownership by a stateful contract. The third option is the interesting one, and it's a demonstration of a broader concept (that might be familiar to whoever watched the webinar by @IzioDev and @michaelsuttonil), called inter-covenant-communication (ICC). In this context, it means you can put arbitrary stateful rules around token control. For example: - “after the first 10 spends, wait a year before spending again” - zk-rollups can manage their L1 tokens using a stateful bridge. DOG20 also supports minters that are allowed to mint indefinitely — but that does not mean the supply must be unbounded. Let's say you want to publish a token and allow to issue only 100 new tokens each month. DOG20 doesn't support it natively, but you can achieve that by making the only minting entity a covenant. That covenant will store in its state `nextIssuance`, and will allow spends of 100 tokens only if `time > nextIssuance`, and will set `nextIssuance = nextIssuance 30 days` each time it's used. I hope to explain about it a bit more in the future, but in the meantime, feel free to look at the examples linked in the next comment.

The full vprogs vision of composable zk-based apps requires essentially 4 major building blocks: 1. You need a runtime that can efficiently drive state transitions. 2. You need a way to prove the activity of that runtime. 3. You need a way to settle those proofs on the L1 using covenants. 4. You need a "meta-program" that can invoke and orchestrate user-deployed guests for composability while enforcing certain constraints. We are currently working on step 3. which will already enable programmability but interactions between apps have to go through the L1. The full vprogs vision of synchronously composable based apps will only be achieved once we advance to step 4. It's hard to say how long things will take but so far it took a few weeks for each milestone so I would expect a similar rate of progress.

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: medium.com/@michaelsuttonil/…