Kaspa developers have published the first three Kaspa Calls for Conventions as drafts, moving covenant interoperability from a general objective into specifications that wallets, indexers and applications can implement. KCC-01 defines the common covenant vocabulary and ABI, KCC-02 standardises authority schemes, and KCC-20 applies both layers to fungible-token covenants (IzioDev, KCC repository).
The three drafts were developed together rather than as an isolated sequence. KCC-20 needed a consistent way to describe who can authorise a token operation, which produced KCC-02. That authority work in turn exposed terms and layouts that had to be made explicit in KCC-01. Publishing the set together lets reviewers test the lower-level conventions against a concrete token use case instead of assessing an abstract framework.
KCC-01 defines canonical byte layouts, value types, state encoding, entrypoints, dispatch tags, covenant templates and Covenant ID lineage. It is independent of SilverScript, Argent or any other source language. A program can follow the same ABI regardless of which compiler or framework produced it, allowing external tools to decode state and construct invocations without learning a private format for every application. The draft does not alter consensus rules.
KCC-02 gives authority schemes fixed identifiers and interpretations. Its initial set covers direct Schnorr public keys, Schnorr and ECDSA public-key hashes, exact P2SH scripts and continuing covenant lineages identified by Covenant ID. Higher-level standards can choose which schemes they support while using the same canonical byte for each one. A wallet can therefore read the program ABI to determine whether an owner is represented by a key, a script or another covenant instead of relying on application-specific assumptions.
The covenant-lineage option is especially important for application composition. A token operation can require participation from another continuing covenant and optionally inspect its program template and state. This creates a standard route for one covenant to act as an owner, governor or other authority over another covenant without reducing every authorisation rule to a conventional wallet key.
KCC-20 defines the shared state and transfer surface for fungible-token covenants. Its base state includes the token amount, owner, owner scheme, borrowing configuration and a commitment to optional extended state. The standard preserves room for project-specific behaviour while making the core token state and transfer interface recognisable to wallets, explorers, indexers and trading applications.
The draft also specifies normal owner-authorised transfers and borrowed receive. Token assets are separate from KAS, but a newly created token UTXO still needs sufficient KAS under storage-mass rules. Borrowed receive allows an existing recipient token UTXO to be reused when its owner has opted into an accepted authorisation scheme. The token amount can increase while the KAS value, owner and extended-state commitment remain unchanged.
Review in the Kaspa Core R&D channel quickly moved to the limits of that model. Developers discussed whether several script templates can share one Covenant ID, how wallets identify the full token identity, and what each template must expose to remain composable. Michael Sutton said the full identity should combine the Covenant ID and template hash, while Sivan Helfer explained that every supported actor must implement the standard transfer entry if the token state is allowed to move between scripts (discussion, template identity). The draft remains open precisely so these cases can be challenged before applications depend on a settled convention (review request).
Builders are already testing the proposed common surface. ZealousSwap said ZealousSwap and ZealousLaunch conform to all three drafts, allowing compatible tools to read tokens launched there and KCC-20 assets created elsewhere to enter its pools without a project-specific integration (ZealousSwap). That is an early implementation statement rather than proof of ecosystem-wide adoption, but it shows how the standards can reduce fragmentation between issuers, wallets and markets.
All three documents remain drafts. Their identifiers and interfaces can still change as reviewers find ambiguities or incompatible assumptions. The immediate milestone is a shared technical target that separate Kaspa builders can now implement, compare and challenge in public.
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
