Post-Toccata Covenant Standards Come to Kaspa

Toccata brought covenants to Kaspa's mainnet. Now the question is what gets built on top of them — and who decides how the pieces fit together.

On July 24, 2026, Kaspa core developer Michael Sutton published three coordinated announcements that outline an answer: a community standards forum called Kas-Smiths, a formal convention process called KCCs, a conceptual framework for thinking about covenant state as "actors," and a new programming language called Argent for writing covenant applications. Separately, contributor @IzioDev opened a draft pull request for KCC-0001, the first formal covenant specification under the new process.

Taken together, these releases represent the earliest infrastructure for ecosystem-wide covenant development on Kaspa — the layer between the protocol itself and the independent wallets, applications, and tools that will use it.

Kas-Smiths: A Workshop Before the Fragmentation

Kas-Smiths is a community forum and GitHub repository intended to coordinate ecosystem standards, protocols, tooling, wallets, and applications before independent teams end up building incompatible implementations.

From the Kas-Smiths welcome post:

"Kas-Smiths is a workshop for Kaspa ecosystem coordination. A place to discuss and forge standards, protocols, tooling, wallets, applications, and the shared infrastructure being built on top of Kaspa. The goal is to create a practical space where ideas can be proposed, challenged, improved, and eventually turned into something the ecosystem can build on."

The distinction from Kaspa Improvement Proposals (KIPs) is deliberate. KIPs govern changes to the Kaspa protocol itself — consensus rules, block structure, the things every node must agree on. KCCs, short for Kaspa Calls for Conventions, govern voluntary agreements between independent projects: how fungible tokens should be represented on-chain, how covenant scripts should expose their interfaces, how wallets should interpret contract state. No one is forced to adopt a KCC, but projects that do gain interoperability with each other.

Early proposals already in discussion include KCC-20 for fungible token standards and KCC-0001 for stateful covenant script ABIs — the subject of @IzioDev's draft, which we'll get to below.

The Actor Model: Covenant UTXOs as Stateful Agents

Alongside the forum launch, Sutton published an argument for a specific mental model when thinking about Kaspa's stateful covenant UTXOs: the "actor" model borrowed from concurrent programming.

The core idea is that a covenant UTXO should not be thought of as shared mutable data sitting on the ledger. Instead, each covenant actor exclusively owns its own state and exclusively authorizes changes to that state. A transaction is the message — the interaction — that triggers the actor's next state transition.

As Sutton wrote: "The tx is the interaction/msg that triggers the actor's next state transition." He concluded the argument by proposing standard terminology:

"I argue that this is the right mental model and terminology to establish when discussing covenant state-controlling entities: a piece of code owning a state and exclusively authorizing its mutation/consumption."

This is not a consensus change. It's a conceptual framework — a way for developers to discuss increasingly sophisticated covenant applications as Kaspa's execution layer develops. But framing matters: choosing the wrong abstraction early can lock a community into terminology that makes later design work harder. Getting the mental model right now, while the ecosystem is still small enough to coordinate, is a deliberate investment.

Argent: A Language for Covenant Applications

The third announcement is Argent, described as "an actor-based, multi-contract and multi-app language and compiler for building Kaspa covenant applications."

Argent models covenant UTXOs as actors that own typed state, with transactions defining how those actors transition between states — directly implementing the conceptual model Sutton outlined. The compiler translates .ag source files into auditable Silverscript contracts and portable artifacts consumed by argent-runtime, which handles transaction construction and covenant state management.

The documentation is explicit about maturity: syntax and APIs are expected to change as the system evolves, and the project has not yet been audited. This is early-stage tooling, not production-ready infrastructure. But its existence signals that the Kaspa developer community is moving beyond hand-written covenant scripts toward higher-level abstractions that can scale to complex applications.

For anyone building on Kaspa's covenants — or evaluating whether to build — the existence of even an evolving language layer changes the calculation. Writing raw Silverscript for every covenant application is labor-intensive and error-prone. A language that compiles to auditable contracts and manages state transitions programmatically lowers the barrier to entry, even before it's fully stable.

KCC-0001: The First Formal Covenant Specification

Kaspa contributor @IzioDev opened a draft pull request proposing KCC-0001, a specification that defines the core terminology, application binary interface (ABI), and byte layouts for Kaspa covenants.

The draft is explicitly independent of any particular source language, compiler, framework, or artifact format. It does not change consensus rules. What it does is define a shared vocabulary and data layout that different tools can agree on: covenant programs, covenant instances, continuations, templates, Covenant ID lineage, leader and delegator roles, and virtual elements.

As @IzioDev wrote: "As the first (in order) kcc, kcc-01 brings those assumptions into public discussion while they are easy to question and change."

That last phrase is important. KCC-0001 is in draft, open for public review, and being proposed precisely now — before implementations harden around incompatible assumptions. The specification provides a common foundation for future covenant tooling and interoperability.

Why This Matters for KAS Holders and Self-Custody Users

None of these releases change what KAS does today. Your node runs the same. Your transactions validate the same way. What changed is the infrastructure that will determine what covenant-powered applications look like six months or two years from now — and whether they work together.

For holders who use self-custody tools, covenant standards directly affect the quality and safety of the tools available to them. When independent projects agree on how covenant state is represented, wallets can display contract state accurately. When they agree on ABIs, audit tools can verify contracts uniformly. When they agree on a language and compiler, bugs can be caught at a higher level before they reach on-chain execution.

This is the connective tissue between Toccata's on-chain capability and the real-world tools that make it usable. The vaults and escrow contracts that Kaspa Forge builds are exactly the kind of covenant applications that benefit from shared standards — not because they need them to function, but because ecosystem-wide conventions make audited, interoperable tooling possible at scale.

Broader Context: Tokenization Momentum

The same Kasmedia report notes that institutional tokenization continued gaining traction during the week, with the Depository Trust & Clearing Corporation (DTCC) announcing live production transactions using tokenized representations of securities — including equity and U.S. Treasury/repo delivery-versus-payment trades. The DTCC described it as "the largest tokenization production initiative in breadth of use cases, asset classes and number of participants," ahead of the planned October 2026 launch of its Tokenization Service.

This is happening on permissioned infrastructure owned by existing financial market participants. It has no direct technical connection to Kaspa. But the broader trend — digital representations of real-world assets settling on-chain — is the same class of problem that covenant standards on Kaspa will eventually make possible on a permissionless, proof-of-work base layer.

The Kaspa ecosystem isn't trying to replicate what the DTCC is doing. It's building the open, auditable, self-custodial infrastructure that lets individuals and smaller organizations participate in the same kind of programmable asset settlement — without trusting a custodian, without asking permission, and with keys that never leave their device.

What Comes Next

The announcements from July 24, 2026 are foundations, not finished products. Kas-Smiths needs community participation to produce standards worth adopting. KCC-0001 is in draft and under review. Argent is evolving and unaudited. The actor model is a proposed convention, not a settled fact.

But foundations laid early, while the ecosystem is still small enough to coordinate, tend to shape everything that follows. The alternative — fragmented implementations, incompatible token standards, every team reinventing covenant ABIs from scratch — is the default outcome when coordination infrastructure doesn't exist.

For KAS holders who care about what gets built on top of their chain, these releases are worth watching. They're the difference between a covenant-enabled blockchain and a covenant ecosystem.

A companion essay series by community contributor moose.kas has also expanded to approximately 140 pages across 16 essays, explaining the first volume of his Kaspa book — useful background reading for anyone following along as the ecosystem develops.