Toccata made Kaspa's layer 1 programmable without turning it into an account chain. It added six things at consensus level: a new transaction format with a compute budget, covenant IDs, introspection opcodes, runtime pricing for scripts, zero knowledge proof verification built into the script engine, and sequencing commitments for apps that bind themselves to layer 1 ordering. Together those let a coin carry rules about how it may be spent next. That is what a covenant is, and it is the foundation everything else on this page rests on.
Six pieces landed at once. They sound technical apart and make sense together, so it is worth reading them as one mechanism rather than a feature list.
| What it is called | What it actually does |
|---|---|
| Transaction v1 | every transaction now carries a compute budget, a binding to the covenant it belongs to, and its own lane. In effect the chain now knows, before it runs a script, how much work that script is allowed to do |
| Covenant IDs | the chain itself now tracks which contract a coin belongs to across its entire life, even though the address hash changes at every step. before this, following a contract meant reassembling it from the outside |
| Introspection opcodes | a script can now look at the transaction it sits in, at its own inputs and outputs. that is the piece that makes a rule like "this coin may only move to an address that carries the same rule" possible at all |
| Script pricing | a runtime meter for stack growth, hashing, signatures and proof verification, so a heavy script costs more than a light one instead of being refused outright |
| ZK precompiles | the script engine can verify Groth16 and RISC Zero proofs directly, which is what lets a chain check a computation it never performed |
| Seqcommit lanes | an application can commit its own activity to layer 1 ordering without proving the whole DAG, which is the groundwork for apps that inherit Kaspa's sequencing |
The short version: before Toccata, a Kaspa coin could be locked. After Toccata, a Kaspa coin can carry rules. Everything from a permanently locked liquidity pool to a proof verified on chain follows from that one change.
If you followed the coverage in June you will have read that Toccata brought Kaspa native tokens, or native KRC-20 issuance, or simply "smart contracts". Those claims travelled a long way. They are worth checking against the source rather than against each other.
The official developer guide lists six additions, and native token issuance is not among them. The core developer's own outlook written before activation does not mention native tokens either. We are not saying the feature is impossible or unplanned, and we are not correcting anyone's roadmap. We are saying that if you read that Toccata introduced native tokens, that claim does not come from the documentation.
The guide is equally direct about the bigger framing. It states plainly that Toccata does not turn Kaspa into an account chain smart contract system. Kaspa stays a UTXO chain, in which coins carry their own rules, rather than becoming a chain of accounts and balances with contracts sitting above them like Ethereum. That distinction is not pedantry. It decides what can be built, how it has to be written, and why tooling from other chains does not simply carry over.
Consensus features being active and an ecosystem using them are two different things, and the guide says so itself, noting that developer tooling is younger than the consensus it targets. So here is the honest state of it, counted rather than claimed.