18,006 covenant outputs unspent on Kaspa layer 1 at the end of 25 October 2026, source kaspalytics
Yes, Kaspa has smart contracts. Since the Toccata hard fork, Kaspa's layer 1 runs native covenant contracts, spending rules that sit inside the coins themselves. The developer documentation at docs.kaspa.org puts it in two sentences, "Toccata makes Kaspa UTXOs expressive enough to carry real application state. It is active on mainnet as of June 30, 2026, at DAA score 474_165_565."
On layer 1, 18,006 covenant outputs were unspent on chain at the end of 25 October 2026, source kaspalytics, logged daily in our covenant log. On top of layer 1, two EVM layer 2s, Kasplex and Igra, run contracts written for the EVM, with the capital committed to them shown below.
Kaspa's answer to smart contracts is unusual because it refuses the standard shortcut. Most chains bolt a single global virtual machine onto their base layer. Kaspa instead built three distinct levels, each with its own job.
Kaspa's base layer is a UTXO chain, like Bitcoin. A covenant is a programmable spending rule attached to a UTXO. The coin itself carries code plus a piece of state, committed on chain as a hash. Whoever wants to spend that coin must reveal the code and state, and the network verifies that the spend follows the rules. There is no global computer executing everyone's programs. Each contract is a small, self-contained state machine partitioned across UTXOs, which is why covenant apps inherit layer 1's speed and parallelism instead of competing for one shared engine.
What covenants do not yet come with is an agreed way to build tokens on top of them. That work is happening in a separate set of proposals, and as of August 2026 none of them is finished. We track where that stands on Kaspa's token standards.
Raw covenant scripting is unforgiving, one wrong byte and funds are stuck. Argent is the high-level language built to fix that. Developers define actors (a contract plus the state it owns), entries (the operations you can call), and transition rules, and the compiler generates the underlying script. Two design choices matter for non-developers too. Every app is a closed system under one covenant ID, so outside code cannot inject itself into an app's state machine. And the compiler is only needed at build time; creating transactions afterwards needs only a lightweight runtime, so tooling in other languages can drive the same apps. Core developer Michael Sutton documents the whole workflow in public coding sessions on the Kaspa Native channel. Episode one builds a working ticketing app from scratch.
For everything built for the EVM, Solidity contracts, MetaMask and existing DeFi codebases, Kaspa has two EVM layer 2s that settle against layer 1, Kasplex, a zkEVM running since 2025, and Igra, running since 2026. This is where Kaspa's DeFi actually operates, and where the TVL shown above sits. The trade-off is the standard one, EVM compatibility and rich tooling, in exchange for each L2's own performance and trust profile.
18,006 covenant outputs were unspent on Kaspa layer 1 at the end of 25 October 2026, source kaspalytics. Every one of them is a coin that carries its own spending rule, and the count rises when apps create new contract outputs faster than they spend them. The full daily series, with transactions and outputs created and spent, is in our covenant log.
Tokens are the next layer on top of covenants. KCC-20 (KCC-0020 in the kaspanet/kccs repository) is the standard for fungible tokens built as covenants. In its own words, "a KCC20 token is a covenant instance that implements a minimal fungible-token interface". It first appeared as a draft on the kas-smiths forum on 2 July 2026. On 21 October 2026 KCC-20 advanced to Final in the kaspanet/kccs repository, together with the base specification KCC-1 (covenant concepts, byte layouts and ABI) and KCC-2 (authority schemes). The repository adds one caution in its own words, "A finalized KCC marks an ecosystem convergence point; it does not make the convention protocol ground truth." Wallets still have to build support for it one by one.
The encoding already works on chain. During the review, one independent indexer reported 2,561 hash-verified KCC20 token reveals with zero mismatches against the draft, source the KCC-0020 review, as of 14 August 2026, more than two months before the standard was final. KCC-20 is token logic on top of covenants, not token issuance at consensus level. Where each proposal stands is on Kaspa's token standards.
There are two ways to build smart contracts on a blockchain. In an account-based design, contracts are accounts with balances and storage inside one shared machine, and every transaction updates that global state in turn. In a UTXO design, there is no shared machine. Each coin carries its own rules and its own piece of state, and a transaction proves that the next output follows those rules. Kaspa's developer documentation is explicit about which one Toccata built, "The result is still UTXO-native. Toccata does not turn Kaspa into an account-chain smart contract system. Instead it makes UTXOs able to carry state, split into parallel lineages, merge when necessary, and prove the next step." (docs.kaspa.org, read on 6 October 2026)
| Account-based design | Kaspa L1 covenants | Kaspa L2s | |
|---|---|---|---|
| Model | one shared virtual machine | state machines inside UTXOs | EVM, per rollup |
| Where state lives | global account storage | partitioned across UTXOs | the L2's own state |
| How work is split | transactions queue for the one machine | parallel lineages that merge when necessary | the rollup's own execution |
| What a transaction proves | a call into a contract account | that the next output follows the rules | a call into an EVM contract |
Neither approach is free. One shared machine makes composability easy and congestion structural. Kaspa's partitioned model keeps the base layer fast and parallel, but asks developers to learn a genuinely different way of building, which is why the tooling work around covenants matters as much as the protocol itself.
Years of "Kaspa is payments only, no smart contracts" left a deep imprint. You will still hear it from commentators and see it in older articles. It stopped being true on June 30, 2026. Anyone repeating it after that date is describing a chain that no longer exists, so check the activation date, not the vibes.
The layer 2s are their own systems. They inherit settlement from Kaspa's layer 1, but their throughput, latency and trust assumptions are their own. When you see EVM performance claims, ask which layer they describe. The honest answer is almost never "layer 1."
The first wave of covenant apps and L2 protocols is weeks-to-months old. Some launched anonymous, some unaudited, and the standard advice from Kaspa's own core contributors is blunt. Know what you buy. A working demo is not a security review. The mechanism being sound says nothing about any individual app being safe.
Yes, in two layers. Since the Toccata hard fork on June 30, 2026, Kaspa's layer 1 runs native covenant contracts, programmable spending rules living inside UTXOs, written in the Argent language. In addition, two EVM layer 2s, Kasplex (since 2025) and Igra (since 2026), run full EVM smart contracts on top of Kaspa.
KCC-20 is the standard for fungible tokens built as covenants 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, together with KCC-1 and KCC-2. It is token logic on top of covenants, not token issuance at consensus level.
Covenants are programmable spending rules attached to individual UTXOs on Kaspa's layer 1. Each contract is a small self-contained state machine. The coin carries code plus state committed as a hash, and any spend must reveal and satisfy those rules. There is no single global virtual machine. State is partitioned across UTXOs, preserving layer 1's speed and parallelism.
Argent is the high-level language for writing covenant applications on Kaspa's layer 1. Developers define actors (a contract plus its state) and entries (callable operations), and the compiler generates the underlying script. Each app is a closed system under one covenant ID, and transactions can be created with a lightweight runtime without the compiler.
Layer 1 covenants are not EVM compatible, they use a different, UTXO-native model. Full EVM compatibility sits on Kaspa's layer 2s, Kasplex, a zkEVM running since 2025, and Igra, running since 2026, which run Solidity contracts and standard EVM tooling.
The mechanisms are active on mainnet, but the first wave of applications launched in 2025 and 2026 and much of it is young, some of it anonymous or unaudited. Kaspa's own core contributors advise users to understand exactly what they are buying. Treat individual apps as carrying real contract risk until independently audited.
Toccata activated on Kaspa mainnet on June 30, 2026 at DAA score 474,165,565. It added covenant rules, covenant IDs, transaction introspection opcodes and zero-knowledge proof verification to layer 1. It did not add account-based smart contracts. Kaspa's own documentation states that Toccata does not turn Kaspa into an account-chain smart contract system. Full EVM contracts run on the layer 2s, Kasplex and Igra.
Building on Kaspa? We review projects and run testnet load tests before launch.
follow kaspa pulse