KCC-20 defines a shared standard for interchangeable tokens on Kaspa. Its tokens live in covenants, programs that restrict how coins can be spent. The standard covers balances, transfers, owner approval and receiving tokens. The KCC-20 reference implementation implements those rules in Argent.[1]
What the standard provides
“Interchangeable” means that units of the same token follow the same rules and can be exchanged for one another. KCC-20 gives applications a common way to recognize token balances and construct transfers, without needing a different interface for every token.[1][2]
KCC means Kaspa Call for a Convention. KCC-20 builds on two other conventions: KCC-1 describes covenant structure and data encoding, while KCC-2 describes who or what can authorize an action.[1]
Approval need not come only from a person’s key. A token can also be controlled by a script or another covenant. The presenter in the *Kaspa Covenant Dev Workshop - KCC20 & Argent* explains that another covenant can authorize a token spend by participating in the same transaction.[3]
The common interface does not require every token to have identical behavior. In his August explanation, IzioDev described room for token-specific data and behavior while keeping the basic token interface recognizable.[2]
Why covenant identity matters
Copying a token’s program should not make the copy the same asset. Michael Sutton explained that state-carrying covenants, including native tokens, need protection against imitation. Covenant IDs provide a provable lineage: a way to distinguish the original covenant’s continuing coins from a separately created copy.[4]
Identity is not the same as safety. On 2 October 2026, Sutton described covenant genesis proofs as a way to connect a covenant ID to its source code, deployment settings and initial state. He called for explorers to expose this information so people could inspect what was deployed.[5]
Receiving tokens without a new coin each time
KCC-20 includes borrowed receive. A token holder can permit an existing token coin to receive more tokens while its KAS value, owner and extended state remain unchanged. This avoids funding a separate token coin for every incoming payment. The owner chooses whether to allow it and which authorization conditions apply.[2]
The reference implementation also includes zero-token receiving coins. These let someone establish a receiving coin before they hold any token balance.[1]
Where it stands
KCC-20 entered Last Call on 7 October 2026. This is the final review window, not Final status. Its current specification and status are maintained in the KCC-20 document.[6]
The reference implementation comes with offline examples and contract tests. Its README says those tests do not exercise network submission or wallet synchronization and “are not an independent security audit”, and Argent, the language it is written in, describes itself as “not yet release-ready”. A shared specification, a working implementation and an audited deployment are different things.[1][7]
Token metadata is a separate piece. KCC-23, a draft convention for binding JSON metadata to a covenant ID, was added to the KCC repository on 14 October 2026; its status is still Draft.[8] It uses an additional preparation transaction rather than a permanent metadata coin or extra covenant state. It adds no spending authority, and it leaves the meanings of metadata fields to ecosystem conventions.[8]
For a technical explanation of how a token can be owned by a key, script or covenant, watch the *Kaspa Covenant Dev Workshop - KCC20 & Argent*, from 1:15:58.[3]