Kaspa Toccata explained

Direct answer

What Toccata turned on

Four rules, worth naming exactly, because the vague version of this list is where the overclaiming starts.

That is the whole activated surface. No virtual machine, no accounts, no global shared state, no contract deployment step. A covenant is a rule attached to coins, and nothing sits at an address waiting to be called, so app logic lives in bounded UTXO steps, in proofs, or in app-side work anchored back to L1.

Covenants

Spend rules become state rules

A covenant-style spend requires the next output to keep a rule, which turns a UTXO into a small state machine: the coin moves, but the rule keeps going.

KIP-17 adds the script tools: byte handling, hashing, transaction introspection, and signatures from the stack. A rule by itself will not stop someone forging a lookalike UTXO with logic that looks right and no real history. KIP-20 closes that gap, keeping a stable 32-byte identity through every valid step forward, so a copy without the lineage fails the check.

Primary sources: KIP-17 covenants and KIP-20 covenant IDs.

Primitives and products

Seven things between a rule and an app

Shipping a consensus rule is like shipping a new instruction in a processor. The instruction is real the moment the chip ships, and useless to almost everyone until somebody writes a compiler that emits it and enough shared convention that two teams can read each other's output. Toccata shipped the instructions on June 30. July was spent on the toolchain.

Checked July 29, 2026. Rows and covenants rechecked August 14. Anything merely announced is left out.

Four of those seven are the reason mainnet holds 373 active covenants worth about 1.67 million KAS while Testnet-10 holds 74,199. The rules are equally available on both. Only one is a place where the missing pieces do not matter yet. Mainnet covenant creation rose fifteenfold to August 8, then slowed to about 2 percent growth the following week.

Conventions cannot be settled by a protocol upgrade, because they are agreements between people who ship independent software. That argument happens in the open at kas-smiths.org and in the public Core R&D Telegram group, where the token standard draft KCC-0020 still has an open disagreement about whether token metadata belongs inside the spec. Treat everything there as proposal-stage: a thread with a confident name is still a thread, and the test is a merged KIP or a merged KCC. Track both on the KIP and KCC tracker.

The two projects below are the current attempts at closing the rest of the gap.

Application language

Argent, the layer between a covenant and an app

Toccata made covenants enforceable. It did not make them writable. A covenant is opcodes, and writing a multi-contract application in them by hand, then auditing it, is not something most teams will do. Argent is Michael Sutton's attempt at filling that gap, and it is not officially blessed. An Argent actor is a covenant object that a transaction consumes and recreates.

state TicketState {
    byte[32] owner;
    int units;
}

actor Ticket owns TicketState {
    entry transfer(byte[32] next_owner, sig owner_sig, pubkey owner_pk) emits next: Ticket {
        require(blake2b(owner_pk) == owner);
        require(checkSig(owner_sig, owner_pk));
        require(next.value == self.value);

        TicketState new_state = {
            owner: next_owner,
            units: units,
        };

        become next <- Ticket(new_state);
    }
}

app Tickets {
    actor Ticket;
}

Every example the compiler ships partitions cleanly: one UTXO per ticket, per game, per position. Two never touch the same state, so the parallel work comes free from the data model instead of a scheduler.

The hard one is shared mutable state, where many users change a single object at once, such as a pooled market maker or an order book. Those are most of what people mean by DeFi, and no public Argent code implements one. The playground's DEX is a single pair, and the compiler's own SECURITY.md never mentions replicas, keepers, or bounded divergence, the shape a partitioned pool would need. Partitioned state looks solved; shared state is a design direction with no implementation anyone can read.

Three repositories, and one person writes nearly all of it. Michael Sutton holds 73 of the compiler's 77 commits.

Baseline read on August 14, 2026. This table refreshes from GitHub when the page loads.

Fifty-eight of those commits landed in July, and the project moved out of his personal namespace into an argent-lang organization.

Argent's own README answers the production question in two halves, and quoting only the first gets it wrong. The caution is real: "The project is still under active development and is not yet release-ready," a production path opens only "Once Silverscript completes its audit and is released," and Argent "will still need further audit and hardening before general production use." The second half names what that caution is about: "The main pieces are present: compiler, generated Silverscript, portable artifacts, runtime transaction building, multi-actor routing, cross-app linking," and five more. That is a list of things that work, not things planned. The gate is a review queue, not a construction site: an audit on Silverscript, then a release, then an audit on Argent. Until then the README points at advanced users who can read the generated .sil themselves.

Silverscript, the layer underneath, still labels itself experimental and recommends its bytecode artifact only on testnet-10. Kaspa's Argent chapter is more cautious again, calling it "a design direction and prototype, not a production-stable API." Read that as the ecosystem's conservative floor rather than the project's current state, since the same page still links the old repository path. Either way, anyone describing Argent applications as running on Kaspa mainnet today is describing something that has not happened.

Roadmap architecture

vProgs, and the line Toccata does not cross

Two vProgs transactions touching different resources never wait on each other, and a proof lands on Kaspa L1 instead of a replay of every step.

Status: vProgs are prototype and roadmap work. Full vProgs and native Kaspa DeFi are not live on mainnet.

A global account model makes every app action compete for the same shared state, even when the actions have nothing to do with each other. vProgs break that state into separate named resources, built from the read and write list a transaction declares up front. Each resource acts like its own lane, so only the transactions touching the same one have to settle their order. Hans Moog's vProgs walkthrough does not claim a raw TPS number.

The public kaspanet/vprogs repo calls itself an early-development Rust framework for based computation on Kaspa. Its README splits the framework into six layers, from shared types up to a runnable node, and the repo tree carries more, including a ZK side with a RISC Zero backend.

Baseline read on August 14, 2026, unchanged. This table refreshes from the repository when the page loads.

An active repo is evidence of work, not of readiness. The line between this and Toccata is narrower than usually drawn: joining separately compiled covenant apps into one all-or-nothing transaction works on Toccata itself, through Argent's Inter-Covenant Communication, so far only in unaudited offline demos. What vProgs add is the shared mutable state case, which has not reached testnet.

So the model fits products with many users hitting one app, or a proof too big for a covenant spend to carry. Most Kaspa apps do not need it yet. Pick the smallest state model that does the job.

App case

Coordination markets, where a rule replaces an operator

The assurance-funding row above is a coordination market: it pays out only once enough strangers commit to the same condition. A website can run that loop too, and usually a website is the right answer. The version worth putting on a chain is the one where the people paying in expect the operator to move the threshold after seeing the pledges. A covenant moves the release rule out of the operator's database and into the spend rule, where breaking it means making a transaction consensus throws out.

Status: research direction. Two problems have no shipped answer. A covenant cannot see the outside world, so anything settling on a price or an event needs an oracle whose trust model is spelled out first. And no wallet yet shows a user the condition they are about to sign.

Which argues for starting narrow: one condition, one payout rule, and a group small enough to name everyone in it. Assurance funding for a single repeat event is a real test with real users at the end.