What is a KCC?
KCC stands for Kaspa Call for a Convention. A KCC describes a shared convention around which independent wallets, indexers, applications and infrastructure providers can converge.
Conventions can define covenant patterns, application interfaces, asset formats, wallet behavior, indexer interoperability, based applications and verifiable programs. Their purpose is coordination: two implementations should be able to recognize and interpret the same on-chain construction without relying on one vendor.
Ecosystem agreement
Defines conventions and application-level interoperability. Acceptance signals convergence, not a change to Kaspa consensus.
Protocol proposal
A Kaspa Improvement Proposal addresses consensus or core-node behavior. It belongs at the protocol layer.
A useful way to think about it is: Kaspa consensus decides what transactions are valid; a covenant decides which state transition is valid; a KCC helps independent software agree on what that construction means.
The Toccata foundation
Toccata is Kaspa’s mainnet programmability stack. It expands what scripts and transactions can validate while preserving Kaspa’s UTXO-oriented architecture. This is not an account system with one globally mutable contract object.
The key ingredients include richer transaction introspection, covenant-aware outputs, transaction version 1 semantics, explicit script computation budgets and cryptographic primitives for advanced applications. Together, these allow a spent output to constrain the outputs that may replace it.
| Account-style intuition | Kaspa covenant model |
|---|---|
| Contract is a mutable account | Contract state is represented by one or more spendable UTXOs. |
| Call updates stored variables | A transaction consumes old state and creates authorized successor state. |
| One global state location | State can split into many independent cells and execute in parallel. |
| Contract address stays fixed | P2SH state can change its script public key; covenant lineage provides a stable family identity. |
How covenants work
A normal UTXO primarily defines who may spend it. A covenant can additionally constrain how it may be spent: which successor outputs must exist, what state they contain, who may control them and what values must be conserved.
State and identity
State commonly lives in the redeem-script preimage. If the state changes, the P2SH commitment may change as well. A covenant ID provides stable lineage across those changing hashes and controls admission to a covenant family. It does not replace application logic: the script must still validate every transition and its successor outputs.
Parallelism by construction
A state transition does not have to be one input to one output. Covenants can express one-to-many splits, many-to-one merges and more complex multi-contract relationships. Independent UTXOs can progress independently, fitting Kaspa’s parallel transaction model.
SilverScript
SilverScript is a CashScript-inspired high-level language and compiler targeting Kaspa Script. It provides typed contract structure, constructor parameters, entrypoints, signature checks, cryptographic functions and transaction introspection.
A developer writes a .sil contract, compiles it into bytecode and an ABI, constructs the appropriate signature script, and submits a transaction whose inputs and outputs satisfy the compiled rules. Contract entrypoints can represent operations such as transfer, reclaim, split or mint.
The language and tooling are currently marked experimental by the repository maintainers. Syntax, APIs and artifact formats may change. Production deployments require careful version pinning, reproducible compilation, testing and independent security review.
The KCC20 model
The SilverScript repository contains two coordinated examples: KCC20, which represents token-bearing covenant cells, and KCC20Minter, a separate controller that governs issuance. Together they demonstrate a covenant-controlled fungible token system and provide important implementation experience for the newer KCC-0020 proposal.
Instead of placing every holder balance in a global mapping, the model represents token state in UTXOs. A token cell can carry an amount, an owner form and information tying it to the intended covenant family. The total visible token state is reconstructed from the set of live, valid cells.
Value and ownership
Carries a token amount and can be controlled by a public key, a script hash or another covenant ID.
Controlled issuance
A separate covenant can authorize new supply and link minted outputs to the correct token template.
Recognizable shape
Validation can constrain another contract’s state layout and its expected successor construction.
Stable lineage
Connects changing state outputs to one covenant family and supports cross-contract linkage.
Ownership forms
The examples are deliberately broader than “a token owned by a public key.” Ownership can be delegated to a P2SH script or covenant identity. This enables assets controlled by escrow logic, vaults, markets or other programmable conditions—not only ordinary wallet signatures.
Metadata is not consensus
Names, tickers, aliases and images are application metadata. An indexer must distinguish cryptographically validated covenant state from labels supplied by deployment data or external conventions. Duplicate tickers and misleading names are possible, so stable token identifiers remain essential.
KCC-0001 and KCC-0020
Two open proposals in the Kaspa KCC repository are turning the ideas demonstrated by SilverScript into language-independent interoperability specifications. They are highly relevant to wallets and indexers, but their current contents must be treated as draft behavior.
Covenant foundations and ABI
Defines shared terminology, canonical state and argument codecs, entrypoints, dispatch tags, the P2SH program envelope, templates, Covenant ID lineage, multi-input roles and virtual elements.
Fungible token convention
Proposes a standard token-state shape and transfer interface for fungible covenant assets, including ownership identifiers, consumed states, successor states, signatures and witness information.
What KCC-0001 is intended to solve
Without a common ABI vocabulary, compilers and hand-authored scripts can encode equivalent concepts differently. KCC-0001 proposes conventions that let external software identify state, arguments, entrypoints and templates without depending on one source language or compiler artifact.
Its Covenant ID model describes stable lineage across stateful continuations, while leader and delegator roles help define coordinated transitions with multiple covenant inputs. Template hashes identify concrete program shapes; a broader way to group several templates belonging to one logical application family is still under discussion.
What KCC-0020 adds
KCC-0020 proposes a common fungible-token state and transfer contract on top of those foundations. The draft currently considers ownership by a public key, script hash or Covenant ID. Review discussion also considers ECDSA key variants and ownership constrained by both a Covenant ID and a particular template.
| Concept | Current draft direction | Indexer implication |
|---|---|---|
| Owner identifier | A typed or hashed representation of the authority controlling a token state. | Store the raw owner ID and its type; only render a Kaspa address when the type and encoding support it. |
| Token state | Token identity, ownership information and amount carried by live covenant outputs. | Validate the complete state shape before accepting balances. |
| Transfer | Consumes existing states and creates ordered successor states under conservation and authorization rules. | Track inputs and outputs as one transition, including splits and merges. |
| Witness data | Additional context may describe how an owner condition is satisfied or how an extension is constructed. | Preserve raw arguments and witness material instead of assuming one fixed wallet-signature flow. |
| Templates | One logical token implementation may use multiple program templates for deployment, minting or transfer roles. | Keep token identity, Covenant ID and template hash as distinct fields. |
Questions that remain open
- The final set and encoding of owner identifier types.
- Whether ownership should use a uniform construction such as a hash over a type tag and its data.
- The exact separation between signatures, witnesses and implementation-specific transfer arguments.
- How generic wallets construct transfers for extended assets such as blacklist-aware or proof-carrying tokens.
- How multiple concrete template hashes should be grouped into one logical contract or token family.
- Which draft elements will change during review before the proposals are accepted.
Follow the live discussions in KCC-0001 pull request #3 and KCC-0020 pull request #2.
A token’s lifecycle
Deployment
The initial transaction establishes the covenant family and initial state. Depending on the design, issuance may begin with an initial token cell, a minter controller or both.
Transfer
A holder spends one or more token cells and creates successor cells for the recipients. The covenant verifies ownership and ensures that the transition cannot create unauthorized token value.
Split and merge
One cell can become several outputs for multiple recipients, while several compatible inputs can be consolidated. Conservation rules keep input and output token amounts consistent unless a specifically authorized mint path is involved.
Minting
Mint-capable branches link token creation to the separate minter covenant. The controller determines whether issuance is allowed and validates that newly created cells match the expected token state template.
Composition
When ownership is assigned to a script hash or covenant ID, a token can participate in another application’s rules. This is the bridge from a basic fungible asset to programmable custody and multi-contract workflows.
What can be built?
Covenants are general state-transition primitives. Fungible tokens are one visible example, but the same architecture can support a wider class of applications:
- Programmable assets with controlled minting, supply rules and composable ownership.
- Escrow and conditional settlement using signatures, time constraints, hashes or multi-party rules.
- Vaults and recovery paths that restrict destinations or add delayed emergency exits.
- Atomic exchange patterns where multiple assets move only when all required conditions hold.
- Recurring or scheduled payments with locally enforced spending constraints.
- Markets and application state machines composed from linked covenant cells.
- Based applications whose user operations are ordered on Kaspa and whose off-chain execution can settle through proofs verified by L1 covenants.
The right architecture depends on where state belongs: a single covenant UTXO, many parallel UTXOs, a coordinated group of contracts, or an off-chain state root with proof-based settlement.
Why indexers matter
A node validates the chain, but application users need higher-level answers: Which cells are live? Who owns them? What is the current supply? Which transition created a balance? Is a token branch verified or merely claimed?
A covenant indexer follows accepted blocks, extracts relevant transactions, reconstructs state transitions and keeps only the canonical result through chain reorganizations. For KCC20 it can derive tokens, holders, balances, mint and transfer activity, ownership history and the scripts needed to understand a live cell.
This site’s explorer and public API provide that read layer. They do not custody assets, sign transactions or replace validation performed by Kaspa nodes and covenant scripts.
Limits and security
- Experimental software: SilverScript and the KCC20 examples can change before stable releases.
- Convention versus consensus: a KCC label does not itself make a transaction valid or a project trustworthy.
- Successor validation: checking authorization without constraining successor outputs can break a covenant’s intended state machine.
- Identity versus behavior: covenant IDs admit members to a family; scripts still enforce application rules.
- Metadata risk: token names, tickers and images are not unique security identifiers.
- Client verification: wallets and applications should validate token IDs, scripts, amounts, fees and destinations before signing.
- Audit requirement: compiler output and contract logic require independent review before valuable production use.
Short glossary
| KCC | Kaspa Call for a Convention: an ecosystem interoperability document. |
| KIP | Kaspa Improvement Proposal: a proposal concerning the Kaspa protocol or core behavior. |
| Covenant | A script-controlled UTXO whose spend constrains permitted transaction outputs or successor state. |
| UTXO | An unspent transaction output: a discrete piece of spendable value and, for covenants, potentially application state. |
| P2SH | Pay to Script Hash: an output committed to a redeem script whose preimage is revealed when spent. |
| Covenant ID | A stable lineage identifier for related covenant states across changing script commitments. |
| SilverScript | A high-level experimental language compiling to Kaspa Script. |
| KCC20 | A worked SilverScript token example and the subject of the emerging KCC-0020 fungible-token convention. |
| KCC-0001 | An open proposal for shared covenant terminology, byte layouts and ABI conventions. |
| KCC-0020 | An open proposal for an interoperable fungible-token covenant convention. |
| Indexer | Software that derives searchable application state from canonical on-chain transactions. |
Primary sources
This guide is an educational synthesis. For implementation decisions, always consult the current upstream specifications and source code.