KCC-20 is a standard for creating and transferring tokens on Kaspa.
The token's state is represented with UTXOs.
The rules for how those UTXOs may be used are defined through Covenants.
Put simply:
The token and the rules for using it live on Kaspa itself.
When someone creates a KCC-20 transaction, the computers validating Kaspa can check whether it follows the token's rules as part of validating that transaction.
An external Indexer isn't needed to read the actions afterward and decide what the token's valid state should be.
What does that look like?
Say Emma has:
100 TOKEN
That token state is represented using a UTXO.
Emma sends Liam:
30 TOKEN
The transaction creates the new state:
70 TOKEN -> Emma30 TOKEN -> Liam
The Covenants define which changes are allowed.
Kaspa's validating computers check that the transaction follows those rules.
So where is the token?
On Kaspa.
The transactions, UTXOs, and rules needed to check the token's state are on the network itself.
There is no need for a separate system to maintain the authoritative token balances and decide whether a transfer is valid.
An Indexer can still make things easier: searching, browsing history, or building a friendly interface.
But it isn't the authority deciding whether the token state is valid.
How is that different from KRC-20?
KRC-20
Kaspa records the actions.An Indexer interprets them and calculates the token's state.
KCC-20
Kaspa holds the token state and checks the rules that allow that state to change.
The main idea
KCC-20 works through Kaspa itself.
The token state is represented by UTXOs, and its rules are enforced through Covenants - without relying on an external Indexer to determine the valid token state.