KRC-20 is a token standard from the Kasplex project. It carries token instructions in Kaspa transactions, while Kasplex’s indexer, software outside Kaspa, interprets those instructions and tracks token balances. [1][2] KCC-20 uses covenants, programs whose rules Kaspa nodes enforce, to create native assets. The key difference is who checks that a token transfer follows its rules. [1][3]
KRC-20: instructions on Kaspa, balances tracked outside it
An indexer is software that reads transaction history and works out who owns which tokens. With KRC-20, this software interprets token instructions; Kaspa’s own transaction validation does not establish the resulting token balances. [1][2]
On 20 September 2026, Kaspa developer Michael Sutton explained that KRC-20 uses Kaspa transactions as data carriers, but its token state is interpreted outside the network. This does not mean KRC-20 transactions happen somewhere else. It means recording an instruction and checking its meaning as a token transfer are different jobs. [1]
There is a useful technical detail behind that distinction: on 10 August 2026, Manyfest explained that the indexer reads the scripts a transaction reveals when it spends coins, not the transaction’s payload field, a free data slot that Kaspa added in the Crescendo upgrade, after KRC-20 was created. [2]
KCC-20: token rules enforced by covenants
A covenant can require that spending a coin preserves particular rules in the coins created next. For native tokens, those rules protect the token’s state, such as its balances and ownership, rather than only the KAS held by the covenant. Sutton described native KCC-20 tokens as examples of this state-carrying category in October 2026. [4]
Identity matters too. A covenant ID provides a verifiable lineage back to a covenant’s creation. Copying a token’s program is therefore not the same as continuing the original token. Sutton explained that this protection against imitation is why state-carrying covenants need covenant IDs. [4]
What this means for users
Metadata and spending rules are separate. The proposal adding KCC-23, a convention for binding JSON metadata to a covenant ID, was merged on 14 October 2026 (its status is still Draft). It adds no spending authority or application logic. [5]
Network enforcement also does not remove the need to examine a covenant’s code. Sutton stressed on 5 October 2026 that complex ownership logic requires responsibility, auditing and testing. [6]
For a visual explanation, watch the Kaspa Programmability MasterClass with Manyfest, at 35:48. In that section, Manyfest explains the difference between indexer-interpreted KRC-20 tokens and covenant-based native assets. His comments about formalizing KCC-20 describe its development stage in June 2026, when the masterclass was published. [3]