Kaspa & Toccata,
explained simply.

Toccata is a Kaspa hard fork — a network-wide consensus upgrade. It is the moment Kaspa gains native, layer-1 programmability: the protocol learns how to enforce custom rules about how coins can be spent, directly in consensus, with no second layer and no smart-contract chain bolted on top.

It activates on mainnet at DAA score 474,165,565 (roughly June 30, 2026, ~16:15 UTC) and is specified across four Kaspa Improvement Proposals — KIP-16, KIP-17, KIP-20, and KIP-21. Together they bring covenant programming and the groundwork for ZK (zero-knowledge) applications to Kaspa.

Watch it land on the live Toccata countdown, tracked block by block against the chain's DAA score.

DAA stands for Difficulty Adjustment Algorithm. The DAA score is Kaspa's measure of how much accumulated work the BlockDAG has produced — it ticks up by roughly 10 per second (Kaspa targets ~10 blocks/sec).

Because it advances at a steady, predictable rate, the DAA score is used as the network's clock for scheduled events. Toccata doesn't activate at a wall-clock time — it activates the instant the DAA score crosses 474,165,565, which is why the countdown estimates a date rather than guaranteeing one.

A covenant is a spending condition attached to a coin that constrains how it can be spent next — not just who can spend it. A normal Kaspa output asks one question: “did the right key sign?” A covenant output can ask far more: “is the money going to the right address? in the right amount? does the change re-create this same contract? is another token moving in the same transaction?”

In other words, a covenant lets a coin carry its own rulebook. The network enforces those rules at the consensus level when the coin is spent. That single primitive is enough to build tokens, escrows, atomic swaps, and on-chain order books — all natively on Kaspa, with no virtual machine like Ethereum's EVM.

After Toccata, transaction outputs can carry a covenant and UTXOs carry a covenant_id identifying the lineage they belong to.

A vprog — “virtual program” — is the actual executable logic that powers a covenant. When a covenant output is spent, its vprog runs and introspects the spending transaction: it can read the transaction's inputs, outputs, amounts, and other covenants, then accept or reject the spend based on what it sees.

So the relationship is: a covenant is the concept (a coin with rules), and the vprog is the program that expresses and enforces those rules. Covenants are what's possible; vprogs are how they're written and run.

Developers don't hand-write low-level vprogs. They write in a higher-level language — SilverScript — which compiles down to the vprog form the Kaspa node validates.

SilverScript is the high-level language for writing Kaspa covenants. You describe the rules of your contract — a token, a swap, a limit order — in SilverScript, and a compiler turns it into the vprog the network enforces.

It's the practical entry point for building on Toccata: think of it as the “Solidity” of native Kaspa covenants, except it compiles to transaction-introspection rules rather than to bytecode running on a global virtual machine.

Not in the EVM sense, and that's deliberate. Ethereum runs a shared, stateful global virtual machine. Kaspa's model is UTXO-based: there's no global contract state, just coins with rules. Covenants make those rules expressive enough to cover the same use cases — tokens, swaps, escrows, order books — while keeping Kaspa's parallel, high-throughput BlockDAG design.

The trade-off: instead of arbitrary global computation, you get fast, predictable, locally-verifiable contracts that fit Kaspa's speed. Different philosophy, overlapping outcomes.

KCC stands for Kaspa Covenant Contract — the family of standards built on Toccata's native covenants. Where “ERC” is the prefix for Ethereum token standards, KCC is the prefix for Kaspa's native, on-chain standards.

The key word is native: KCC standards live in consensus, enforced by covenants and their vprogs, not by an external indexer or a second-layer protocol agreeing to play by the rules.

KCC20 is the fungible-token standard for native Kaspa covenants — Kaspa's answer to ERC-20, but enforced by the chain itself.

Under the hood, a KCC20 token is a covenant lineage identified by a covenant_id. The token's supply lives inside covenant UTXOs — each one carrying that covenant_id, an amount, and an owner. Moving the token means spending those UTXOs and creating new ones of the same lineage:

• Mint — a covenant output is created from genesis.
• Transfer — a covenant UTXO is spent, producing new covenant UTXOs of the same lineage (tokens can split or merge in one transaction).
• Balance — the sum of an owner's unspent covenant UTXOs for that token.

Because the rules ride on the coins, the token can't be forged or over-minted — conservation is enforced by the covenant every time it moves.

They sound alike but describe fundamentally different things.

• KRC (e.g. KRC-20) is the older inscription / layered approach: token rules are written as metadata inside transactions and tracked by an off-chain indexer protocol (Kasplex-style). The base chain doesn't understand or enforce the token — everyone has to trust a separate indexer to agree on balances. It existed before Kaspa had native programmability.
• KCC (e.g. KCC20) is the native, post-Toccata approach: the token is a real covenant the consensus layer itself enforces. No external indexer is required to keep it honest — the chain does.

The short version: KRC = layered on top, trust an indexer. KCC = built into Kaspa, enforced by consensus. Kaspian Tools builds exclusively for native KCC tokens — the model Toccata makes possible.

Covenants are a small primitive with a big reach. With KCC20 tokens plus a few covenant patterns you can build:

• Fungible tokens whose supply rules the chain enforces directly.
• Atomic swaps & escrow — trade a token for KAS (or another token) with no counterparty risk, settled in a single transaction.
• On-chain order books — a resting limit order is itself a covenant UTXO on the chain; anyone can fill it, partial fills re-rest the remainder, and there's no trusted matcher.

These compose using Inter-Covenant Communication (ICC) — one covenant referencing and validating another in the same transaction — which is how, say, a swap covenant can move a KCC20 token safely against payment.