Toccata: Kaspa's Expressiveness Upgrade

In crypto there are basically two ways to design the thing: account-based and UTXO.

Ethereum and Solana-style account or shared-state systems have been treated as the place where the complex on-chain stuff lives. DeFi, games, lending, all of it. But that power has a bill attached. The base layer is carrying a lot of shared state and a lot of computation, and the more it carries, the heavier a node gets, and the heavier a node gets, the fewer people can actually run one, and there goes a chunk of your sovereignty. You can push performance up, but you usually pay for it somewhere, in node requirements or in some flavor of centralization creeping in.

Bitcoin and Zcash-style UTXO or output-based systems, plus Cardano's eUTXO, are the other bunch. They're more local. A transaction eats specific outputs and makes new ones, and that's the whole event. Not a giant shared world-computer where every app sits in global state bumping into each other. There's a quiet bonus here: because each transaction spells out exactly which outputs it touches, transactions that touch different outputs can be validated at the same time, in parallel (most shared-state chains struggle with that, since they don't know up front what a transaction will touch; Solana is the exception, and it pays for it elsewhere). This locality is why UTXO is lighter and part of why it can run fast, and being lean and parallel is a big part of what makes Kaspa cool. The catch, the thing everyone "knew," is that UTXO is supposed to be the dumb-but-honest branch of crypto. Great for money, bad for expression. Bitcoin leans into this on purpose (and creates harder workarounds to keep it as "dumb" as possible). Zcash and Monero spend their complexity budget on privacy, which is its own giant pile of tradeoffs. Cardano's eUTXO is clever yet also comes with its own compromises.

So the folk wisdom has settled into something tidy and a little lazy. Want real apps? Go account-based. Want a lean sovereign chain? Accept that it can't really do much. Toccata is Kaspa walking up to this tidy little dichotomy and saying "huh, fuck that; let's try to push the limits." To be clear, this doesn't erase tradeoffs and it doesn't turn KAS into ETH or SOL. This isn't what we want. The move is sneakier, and I'd argue more elegant.

The first piece is the one I find beautiful: covenants.

Quick word-nerd detour, because the name is doing work here. A covenant is a promise (the word's from Latin, roughly "to come together," an agreement you're bound to). A binding agreement that follows you forward. In a plain old boring UTXO the script is basically "if you have the key, spend it, do whatever you want afterward, I don't care." A covenant changes this deal to "you can spend this only if the next output also obeys these rules." The coin starts carrying a promise about its own future. This is REALLY cool.

Sounds like a small grammatical tweak. It's enormous. Once a coin can constrain what the next coin must look like, you can chain those constraints, and chained constraints are how you get state that evolves while the rules stay locked. Vaults, escrow, assets, payout logic, a chess game. Picture a wall of locks and keys where each lock also dictates what the next lock is allowed to be. Like switches flipping on and off in a semiconductor, or 0s and 1s in code: the individual pieces are stupid-simple, and the whole expressiveness lives in how you arrange them. That's the trick the entire field of computing is built on, and Kaspa just brought it to its UTXO model.

A quick word on how anyone actually writes these, because the tooling matters as much as the upgrade (otherwise you can't do anything with said upgrade). Raw Kaspa script is low-level and miserable to write by hand, roughly the way nobody wants to write a program directly in 0s and 1s. So there's an experimental high-level language for covenants called SilverScript: you write something readable, and a compiler translates it down into the low-level script the network actually runs. A compiler is just a translator; human-friendly code in, machine-friendly code out, the same reason you get to write Python instead of raw processor instructions. When one covenant isn't enough and you need several of them referring to each other (the chess system needs exactly this), there's an early prototype Michael made called Argent that generates the plumbing between them.

One more piece that sounds boring and absolutely is not: covenant IDs. If a covenant is just "a set of rules," then nothing stops some guy from copying rules that look identical and walking in with fake state. Fine for a toy, fatal if that covenant is guarding a real asset. You need to know this coin descends from the real covenant and not a convincing knockoff.

Bitcoin Cash gets closest here with CashTokens: token categories give assets a consensus-tracked ID tied to genesis. Kaspa takes the same lineage problem and makes it general. Covenant IDs let consensus track the covenant's bloodline directly, for any covenant, without routing identity through the asset layer.

Deeply unsexy. One of the most important parts.

Unlike other chains I'm aware of, Kaspa looks at this whole process and asks which part is even special. And computation, it turns out, is not the special part. Computers are everywhere. AWS will rent you all the computation you could ever want, and so will a pile of other providers. You can buy plenty of compute at an electronics store too. So Kaspa takes the expensive part (computation) and moves it off chain, and keeps the part that's actually unique to crypto (verification, ordering, censorship resistance, proof-of-work security) on chain.

This is where zero-knowledge proofs come in, and I want to be careful here, because ZK in Toccata doesn't mean "private transactions for everyone tomorrow." It means Kaspa gains the ability to verify proofs. An app does its heavy lifting off chain, then hands Kaspa a compact proof, and Kaspa checks the proof instead of re-running the entire program. You keep the thing that matters (anyone can verify the result) and drop the thing that's wasteful (everyone re-computing the same work).

Here's the example that made this click for me, the chess game I mentioned earlier. You're playing on chain for real value. Almost all of it is covenants doing their thing (board state, legal moves, locked payout), except for one ugly problem: bots. You're not going to bet real money against a stranger who might be running an engine, and catching cheaters is exactly the kind of messy pattern-matching you can't put on chain (chess.com keeps its bot-detection secret precisely because publishing it would let people dodge it). So an outside watcher runs that detection off chain, and when it catches a bot it posts a ZK proof to L1 that says "this player cheated." The chain never sees the algorithm. It just checks the proof, and the game's own rules dock the cheater automatically. Off-chain work, small proof back, Kaspa verifies.

Strip the chess out and the principle is plain: any time the real work is too heavy, too private, or both, you do it off chain and hand Kaspa a proof instead of the work itself. A trading app could match orders off chain and prove it matched them fairly. A sealed-bid auction could prove who won without ever revealing the bids. A game could run a thousand moves off chain and settle the whole thing with one proof. Kaspa never does the work. It just refuses to believe you until the math checks out.

The proof systems here include a STARK-based RISC Zero path, plus a Groth16 verifier. To my knowledge, this puts Kaspa among the first proof-of-work L1s to support native STARK-based proof verification, and possibly the first major one.

The bigger ZK pattern has a name: based apps. "Based" just means anchored to L1. The app commits to processing the L1 transactions aimed at it, in the order L1 provides, so it inherits Kaspa's ordering and censorship resistance while running its real computation off chain and proving the result back. The payoff is a hard kind of sovereignty: a based app doesn't depend on any other app staying alive, because everything talks through L1. If someone else's app dies, yours doesn't even notice.

But here's a problem that sounds dumb until you sit with it. You've built an app on Kaspa. How does your app know which transactions are even talking to it?

If the answer is "it checks every single transaction on the entire network," you're cooked, because almost none of them are yours. Imagine proving, every few minutes, that you read the whole post office and only one envelope had your name on it. That doesn't scale.

KIP-21 fixes the addressing. Instead of grinding over the whole DAG to find your sliver of relevant activity, your app follows its own lane and proves the chain of events that actually pertain to it. That's the difference between a cute whiteboard idea and something a builder can ship without lighting money on fire. (On a VM chain you'd usually solve this with some core contract inside the VM that hoovers up the app's data. Works, but now a user-level contract is quietly doing system-level sequencing inside the shared on-chain VM. This cost shows up as more state and execution, which makes nodes heavier. Kaspa takes that job at the protocol level and skips the full VM.)

And as far as I can tell, no other non-VM base layer has actually solved this cleanly. It's also one of the heaviest pieces of engineering in the whole upgrade, and a big chunk of what vProgs will eventually need, quietly shipping now. The thing you trade away is composability: based apps can't reach into each other mid-transaction the way contracts sharing one VM can. This is the deliberate call: more sovereignty now, less synchronous composability. vProgs are the later step that buys some of that composability back without surrendering the rest. Different article.

People have done parts of it. Bitcoin Cash deserves the credit on UTXO covenants. It added native introspection in 2022, CashTokens followed in 2023, and SilverScript is openly modeled on CashScript. Covenants on a UTXO chain are not a Kaspa invention.

So the real question isn't "why did nobody do covenants," it's "why is doing them well so rare." Two reasons. One, the base layer has to be fast. Slow chains can technically run covenants but can't run the good stuff: multi-phase apps, a chess league flipping through states quickly, anything that only works when blocks come fast and parallel. Two, Kaspa adds covenant IDs and native ZK on top. Kaspa needed the full Rust rewrite and Crescendo's 10 blocks per second before any of this was worth attempting. Crescendo brought the speed. Toccata brings expressiveness.

Bitcoin itself is the holdout, still refusing the opcodes that make this easy (OP_CAT and friends), partly on philosophy and partly on real worries about security and recursive-covenant risk. Litecoin, Monero, and Zcash mostly went the other way, toward payments or privacy instead.

Kaspa's edge is the bundle: covenants, covenant IDs, native ZK verification, KIP-21, and a fast parallel proof-of-work base layer. The covenant idea is old. This combination is not.

Two smaller changes ride in with Toccata, and both are constantly getting misread.

First, the transient-mass byte allowance roughly doubles, from about 125 KB to 250 KB. This has little to do with increasing TPS (although, sure). A large STARK-based proof can be big enough that a block needs room for the proof plus the surrounding transaction data. No room for the proof, no ZK verification on L1. Simple as that.

Second, a minimum standard fee. Doubling the byte allowance means the DAG can soak up more data, which increases the disk burden on everyone running a node, an archive, or an explorer. This isn't abstract: the Toccata guide now says 640 GB SSD minimum, 1 TB preferred. If storage requirements are going there, the space should be filled by proofs, app transactions, asset activity, payments, actual use, instead of free junk. For a service or app, the fee is small compared with the thing being purchased, settled, or protected. For someone filling blocks with junk, the floor makes chain filling cost real money.

This is just a standard-relay fee floor. A miner can accept cheaper transactions, but most run the default, so only that miner's share of blocks would carry the spam. Nodes can change policy later if the number stops making sense.

This one's wired straight into the sovereignty story, and imo, it's underrated. Shoutout to @LiveLaughLove13, who built the Rust Stratum Bridge that's now provided with rusty-kaspa and currently marked beta.

The sovereignty pitch usually stops at "run your own node." For proof-of-work the better version is "mine to your own node." Problem is ASICs don't speak Kaspa's node language, they speak Stratum, so for a long time you needed a separate bridge or, more commonly, you just handed the job to a pool because wiring yourself directly into the network is a pain. Pulling a maintained Stratum bridge into the rusty-kaspa package itself makes solo mining a normal thing instead of a weekend science project. Run your own node, verify your own chain, mine to your own node. Be your own bank, be your own miner.

An implication came up that I hadn't chewed on before, and I'd flag it as speculation (for now) because the mechanism isn't decided: if RTD-style oracle flows ever need miners to attest to outside claims on chain, the Stratum bridge is one plausible place for that app-layer work to plug in. It already sits between ASICs and a Kaspa node. That's app layer, not base consensus. Maybe nothing, but the direction is interesting.

Solo mining guide for the actual miner-to-node setup.

Covenants make UTXOs expressive. Covenant IDs keep that expressiveness honest. ZK moves the expensive computation off chain while keeping cheap verification on it. KIP-21 lets apps find their own activity instead of scanning the (DAG) universe. The fee and byte-room changes make room for proofs without making spam free. The Stratum Bridge makes solo mining real, and maybe gives future miner-side app jobs a place to plug in. Stack those up and the sovereignty story gets a lot more complete: sovereign money, sovereign verification, sovereign mining, sovereign apps, and maybe one day a sovereign way to bring real-world information in.

Yet this still isn't completely finished. vProgs aren't here. DAGKnight isn't here. 100 BPS isn't here. But it's also not nothing, which is the thing Kaspa people keep doing to ourselves: under-celebrating what's shipped because we're already squinting at the next milestone. Toccata isn't a roadmap promise anymore. It activated, and now it's live primitives: vaults, assets, weird state channels, ZK apps proving work back to L1, chess games, or something none of us has thought of yet. That's the fun part.

For years, UTXO programmability has been this quiet research corner full of brilliant people inventing clever workarounds. Bitcoin has some of the sharpest minds in the entire space, and a lot of them are stuck working around a culture that doesn't want the solution to exist on L1. The same little opcode that quietly makes most of this possible, OP_CAT, is something Bitcoin has refused for years on purpose, because it treats that much expressiveness as a risk, both to keeping coins as pure money and to Bitcoin's own security. This is a legit philosophy and not necessarily a dumb one. Kaspa just made a different call, and tried hard not to lose the lean, verifiable, sovereign properties that made this whole thing worth caring about in the first place.

That's why I keep landing on the word elegant, because none of this has been, is, or will be easy. It's taken the Rust rewrite, Crescendo, years of grinding performance work, and a stack of upgrades and tools most users will never need to know by name (the new opcodes, covenant IDs, the ZK verifier, KIP-21's activity tracking, SilverScript, Argent, on and on), plus a pile of people quietly building parts most users will never see or thank them for. Not to mention the stuff I'm sure core is already working on to make this future more usable.

Which is the real reason I'm "bullish," more than any chart. The design is good. The people are better. Core devs, contributors like @LiveLaughLove13, the SilverScript and tooling folks, the writers and explainers (people like me, hello) trying to make this legible to humans who don't read consensus code for fun. We're a real community doing hard, unglamorous work because this design goal is worth pursuing.

Underneath the coin, even underneath the people, there's this idea I've actually fallen for. You take something simple and clean, a lock, a key, one rule about what's allowed to come next, and you arrange those tiny pieces into something complex and beautiful. That's the whole story of computing. It's the story of covenants. It's the thing Bitcoin's best researchers wanted for years and weren't allowed to have on Bitcoin. Bitcoin Cash built a version first. Kaspa built it on a base layer fast enough to make it relevant.