Kaspa finalizes 3 standards for native tokens and covenant apps

Kaspa's KCC Coordination Forum has finalized three standards covering covenant interfaces, authorization, and fungible tokens, establishing shared specifications for developers building applications on the network.

Summary

• KCC-1 defines shared interfaces for wallets, compilers, indexers, and other tools working with covenants.
• KCC-2 specifies five standard authorization schemes, including public keys, scripts, and covenant identifiers.
• KCC-20 sets token transfer rules and supports receiving tokens through an existing compatible output.
• Finalization establishes ecosystem conventions without changing consensus rules or requiring every participant to adopt them.

KCC Coordination Forum said in an Oct. 21 announcement that KCC-1, KCC-2 and KCC-20 were final and ready for adoption across the ecosystem. The forum invited builders to join its public channel for questions, implementation discussions, and support.

Greetings $KAS. KCC-1, KCC-2 and KCC-20 are now Final, meaning they are ready for full adoption across the ecosystem.

We invite Kaspa builders to join the public KCC channel to ask questions, get support, discuss implementations and share what you build.

Come build with us. --- KCC Coordination Forum (@kccforum) October 21, 2026

Kaspa's canonical standards repository lists all three documents as Final. Its index identifies KCC-1 as the covenant specification, KCC-2 as the authority specification, and KCC-20 as the application standard for fungible-token covenants.

The repository describes KCCs as shared conventions for independent implementations. Its documentation separates those conventions from changes to consensus or core-node behavior, which belong in Kaspa Improvement Proposals.

Kaspa standards cover different parts of application development

KCC-1 defines common terms, data layouts and an application binary interface, or ABI, for covenants. The specification describes how software encodes information, calls program functions, and identifies the state carried between transactions.

Its authors, Romain Billot, Michael Sutton and Ori Newman, identify compilers, wallets, indexers and transaction builders among the tools that need to agree on those details. The document says independent implementations need common formats beyond simply producing scripts that pass consensus checks.

The KCC-1 specification leaves developers free to choose their programming language, compiler, and framework. Its shared interface covers program entry points, state templates, and rules for handling transactions involving multiple inputs.

Within the same document, the authors distinguish basic interface rules from features that depend on covenant identifiers. Programs without covenant bindings can follow KCC-1, but the specification says they do not receive the lineage and authorization guarantees supplied by KIP-20.

KCC-2 defines who can authorize an operation

KCC-2, written by Billot and Sutton, specifies how programs identify an authority and the minimum checks required to establish its approval. An authority can be a public key, a commitment to a key, a script, or a continuing covenant lineage.

The specification assigns standard identifiers to five authorization schemes. Its public-key options cover Schnorr and ECDSA signatures, while its other options allow a script or covenant lineage to participate as an authority.

For public-key-hash authorization, KCC-2 requires the transaction to reveal the corresponding public key, match its hash against the stored authority value, and provide a valid signature. Higher-level specifications define the signed message and any further conditions.

The authority registry reserves separate ranges for standard and custom schemes. KCC-2 permits participants to adopt custom schemes without waiting for standardization, provided their definitions specify the format, meaning, and approval checks.

Under its covenant-identifier scheme, approval requires an input from the identified covenant lineage. KCC-2 says a higher-level convention can impose further checks on that input's program and state.

KCC-20 sets token transfer and receiving rules

KCC-20 builds on the first two standards, defining token amounts, ownership, and transfer interfaces. The document names Sivan Helfer, Sutton, Newman, and Billot as its authors.

Its specification requires each token covenant to publish program information that software can use to decode state and construct transfers. Configurations must disclose supported ownership schemes and 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. KCC-20 says the transaction recreates that output with more tokens, preserves its ownership and extended state, and cannot reduce its KAS value.

The security section warns that replacing the output changes its transaction reference, invalidating unconfirmed transactions spending the previous reference. A wallet must discover the replacement before spending it, according to the document.

The standard links an Argent reference implementation with generated SilverScript contracts and Rust conformance tests.

Final status carries implementation requirements

KCC-0, the document governing the standards process, requires more than completion of a final review period. It says a standards-track convention needs human-readable and machine-readable test vectors, plus at least one public implementation that passes the machine-readable checks.

Dependencies must be Final for other KCCs or Active for KIPs, according to the same rules. KCC-0 says status changes occur through pull requests and the repository index must be updated with them.

KCC-0 describes machine-readable test vectors as the authoritative form for automated testing when they accompany human-readable examples. Its submission rules require security considerations to address threats, trust assumptions, and potential replay issues before a standards-track document can enter Last Call.

The governing document states that finalization does not require every ecosystem participant to implement a convention. Substantive changes generally require a replacement KCC, while corrections and clarifications follow the document's amendment rules.

Kaspa's application development has previously included separate Layer 2 infrastructure. Gate announced a Kasplex Layer 2 integration in April, enabling KAS deposits and withdrawals through the EVM-compatible network, as crypto.news reported.

In its earlier integration announcement, Gate said customers could transfer KAS from the base network to a Kasplex wallet. Kasplex's project materials describe a two-way bridge and say developers familiar with Ethereum tools can deploy contracts by changing their remote procedure call endpoints.

Kasplex describes its design as a lightweight rollup that places EVM bytecode in Kaspa transactions and executes it off-chain. Its documentation says Kaspa supplies transaction ordering and data availability, while bridged KAS serves as the Layer 2 gas token.