Two ways to build, and a tradeoff nobody escapes

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. They hold the keys for rich applications. 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 genuinely 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. Very complex behavior out of very simple operations. 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. Doing computation is not crypto's unique selling point. 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. That's the whole pattern.

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. The plain idea is the same either way: heavy computation happens off chain, and Kaspa verifies a compact proof on chain. 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, not expression.

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.