KRC-20 and the move toward KCC-20

Kaspa's first token wave began with Kasplex inscriptions. Native covenant tokens open a different path, but existing balances do not move by themselves. Each project needs to publish its own verified process.

How the first wave worked

Kasplex introduced KRC-20 as a third-party protocol on top of Kaspa. In 2024, people used it to deploy, mint and transfer tokens. The transactions were recorded on Kaspa, while a separate indexer interpreted the token instructions and calculated balances. Kasplex's KRC-20 node documents that indexing layer. KRC-20 is not the same thing as a token rule enforced by Kaspa consensus.

That launch gave projects such as Nacho, KASPY and KANGO a way to build communities before native covenant tokens were available. Minting was easier than creating deep, continuous trading markets. KRC-20 tokens traded through specialist marketplaces and, for some projects, centralized exchanges. Access and liquidity varied by token and venue. It would be inaccurate to say that every KRC-20 token had no market or that all of them became irrelevant.

What KCC-20 changes

Kaspa's developer portal describes native mainnet covenants following the Toccata upgrade. The KCC-20 convention specifies fungible token state and transfer rules for covenant applications. Its repository marks the convention Final. The KCC repository also explains that Final means ecosystem convergence on a convention, not a Kaspa consensus change or automatic support by every wallet, exchange or application.

A KRC-20 balance is therefore not automatically a KCC-20 balance. Any transition needs a project-specific mechanism that accounts for the old supply and defines how holders receive the new asset. A testnet demonstration would show a possible implementation, not complete a mainnet migration. The project's published terms, wallet support, exchange handling and destination token identity matter more than a generic claim that "migration is live."

Projects we are watching

Nacho the Kat

Its project site identifies the KRC-20 token and links to existing bridge and trading products. We have not verified a complete, official KRC-20 to KCC-20 holder procedure there. A bridge to another ecosystem should not be mistaken for that migration.

Artwork: Nacho on X ↗

KASPY

The project site identifies the token, and the team has discussed a KCC-20 transition on its official X account. We have not verified final holder instructions, a migration window or exchange handling.

Artwork: KASPY on X ↗

KANGO

KANGO was part of the earlier KRC-20 wave. We have not verified a current, official KCC-20 migration plan or a holder action. A community post alone will not be treated as an instruction.

Artwork: KANGO on X ↗

What holders need before taking action

A usable announcement should identify the official project channel, eligible balances or snapshot, supported wallets and exchanges, any deadline, the conversion ratio, the exact destination covenant or token identifier, and who controls any bridge or custody step. It should also explain what happens to tokens held on an exchange and how the old supply is retired or accounted for. These are questions to ask, not steps to perform today.

Until those details are published and independently checked, there is no universal wallet procedure to recommend. No legitimate migration requires a holder to share a seed phrase or private key. We will add project-specific instructions only after checking the team's original notice and the relevant wallet or exchange documentation.