Kaspa's KCC Coordination Forum Finalizes Three Token and Covenant Standards

KCC-1, KCC-2 and KCC-20 Are Final

Builders on Kaspa, the altcoin whose KCC Coordination Forum sets ecosystem conventions, worked without a shared covenant specification until this week. On Oct. 21 the forum declared KCC-1, KCC-2 and KCC-20 Final, a status it defines as ready for full adoption across the ecosystem. The announcement, posted on the forum's X account, invited builders to join a public channel for questions, implementation discussions and support. The canonical standards repository under the kaspanet organization lists all three documents as Final and identifies KCC-1 as the covenant specification, KCC-2 as the authority specification and KCC-20 as the application standard for fungible-token covenants. KCC-1, authored by Romain Billot, Michael Sutton and Ori Newman, defines common terms, data layouts and an application binary interface for covenants: how software encodes information, calls program functions and identifies the state carried between transactions. It names compilers, wallets, indexers and transaction builders among the tools that need to agree on those details, while leaving developers free to pick any programming language, compiler or framework. Its shared interface covers program entry points, state templates and rules for transactions involving multiple inputs. Programs without covenant bindings can follow KCC-1, but the specification notes they receive none of the lineage and authorization guarantees supplied by KIP-20. KCC-2, written by Billot and Sutton, sets out how a program identifies an authority and the minimum checks required to establish its approval. It assigns standard identifiers to five authorization schemes: public-key options covering Schnorr and ECDSA signatures, plus options that let a script or a continuing covenant lineage act as an authority. For public-key-hash authorization, a transaction must reveal the corresponding public key, match its hash against the stored authority value and provide a valid signature. Custom schemes may be adopted without waiting for standardization, provided their definitions specify the format, meaning and approval checks.

@kccforum · X post

Posted on the forum's X account.

View on X

KCC-20, credited to Sivan Helfer, Sutton, Newman and Billot, builds on the first two documents and defines token amounts, ownership and transfer interfaces. The standard targets fungible tokens rather than NFTs. Each token covenant must publish program information that software can use to decode state and construct transfers, and configurations must disclose supported ownership schemes plus limits on token inputs and outputs. A feature called borrowed receive lets a sender use a recipient's existing compatible token output as the destination: the transaction recreates that output with more tokens, preserves its ownership and state, and cannot reduce its Kaspa (KAS) value. The security section warns that replacing the output changes its transaction reference, invalidating unconfirmed transactions that spend the previous reference. An Argent reference implementation ships with generated SilverScript contracts and Rust conformance tests. Final status carries hard requirements under KCC-0, the document that governs the process. A standards-track convention needs human-readable and machine-readable test vectors, at least one public implementation that passes the machine-readable checks, and security considerations addressing threats, trust assumptions and replay issues before it enters Last Call. Dependencies must be Final for other KCCs or Active for KIPs, and status changes move through pull requests. The repository separates these shared conventions from changes to consensus or core-node behavior, which belong in Kaspa Improvement Proposals. Finalization does not require every ecosystem participant to implement a convention, and substantive changes generally require a replacement KCC. Application development on the network has so far run through separate infrastructure. Gate announced a Kasplex Layer 2 integration in April, enabling Kaspa (KAS) deposits and withdrawals through the EVM-compatible network. Kasplex describes a lightweight rollup that places EVM bytecode inside Kaspa transactions and executes it off-chain, offers a two-way cross-chain bridge, and treats bridged KAS as the Layer 2 gas token.

Where the Standards Stop

The finalization converts what used to be per-project format negotiation into spec conformance: a wallet or indexer team can now build once against KCC-1's interface and KCC-2's authorization identifiers instead of reconciling conventions with every token project separately. KCC-0's test-vector rules give those teams an objective bar, and the Argent implementation with its Rust checks already exists to build against. Our live monitoring shows KAS logging a 5.3% spot move over the past 24 hours, so the market is digesting the news alongside normal flow. The limit that survived the change is jurisdiction: none of the three documents touches consensus or core-node behavior, programs outside covenant bindings gain no KIP-20 guarantees, and adoption across the ecosystem stays voluntary.