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 carries a compute budget, a binding to the covenant it belongs to, and its own lane. In effect the chain knows, before it runs a script, how much work that script is allowed to do |
| Covenant IDs | the chain itself 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 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. 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, measured rather than claimed, with its source named. Since 22 September 2026 we log the Kaspalytics count every day and publish the whole series, quiet days included, on is Toccata being used?
Toccata is a consensus level upgrade to Kaspa that activated on mainnet on 30 June 2026 at DAA score 474,165,565. It makes Kaspa's layer 1 programmable by adding six things, namely a transaction format carrying a compute budget, covenant IDs that let the chain track which contract a coin belongs to, introspection opcodes that let a script read its own transaction, runtime pricing for scripts, zero knowledge proof verification inside the script engine, and sequencing commitments for applications that bind to layer 1 ordering.
The official Kaspa developer guide lists six consensus additions in Toccata and native token issuance is not among them. The core developer's own pre-activation outlook does not mention native tokens either. Several news articles and widely shared posts described Toccata as introducing native token issuance, but that description does not come from the documentation. Since 2 July 2026 there is a community standard called KCC20, final since 21 October 2026, that defines fungible tokens as covenant instances built on top of what Toccata added, which is token logic above the consensus layer rather than native issuance at consensus level.
It depends what you mean by the term. The developer guide states directly that Toccata does not turn Kaspa into an account chain smart contract system. Kaspa remains a UTXO chain, so instead of contracts holding balances in accounts, individual coins carry rules about how they may be spent next. That is called a covenant. It enables things like permanently locked liquidity and on chain proof verification, but it is a different programming model from account-based chains and tooling does not carry over directly.
A covenant is a rule attached to a coin that restricts how it may be spent, for example a rule saying the coin may only move to an address that carries the same rule. Toccata made this practical by adding introspection opcodes, which let a script read the inputs and outputs of the transaction it sits in, and covenant IDs, which let the chain track a contract across its whole life even though its address hash changes at every step.
Toccata activated on Kaspa mainnet on 30 June 2026 at DAA score 474,165,565. The mainnet Toccata node release is Rusty Kaspa v2.0.0, published on 5 June 2026, with v2.0.1 as the maintenance release that followed. Node operators were told to expect roughly 20 to 50% more disk usage.
Yes, though it is early. In the week of 24 August 2026 Kaspalytics showed 403 covenant transactions a day on mainnet, against about 450 the week before, source kaspalytics. Kron, a token launchpad whose locked liquidity is enforced by layer 1 logic, is the most visible application built on the new capability. The developer guide itself notes that tooling is younger than the consensus features, so libraries, wallets and explorers are still catching up.
KCC20 is the community standard for fungible tokens on Kaspa's layer 1. It first appeared as a draft on 2 July 2026 and advanced to Final in the kaspanet/kccs repository on 21 October 2026. In the specification's own words, a KCC20 token is a covenant instance that implements a minimal fungible-token interface. It builds on the covenant capability that the Toccata hard fork added, which means it is token logic on top of covenants rather than native token issuance at consensus level.
follow kaspa pulse