When one token becomes two
You and Sam hold the same token. Right now any coin of yours equals any coin of Sam's. Update just one of you, and that stops being true, for good.
A made-up token, used as an example. The standard is real; this token is not.
9 coins. One shared supply.
Either of you could pay the other any amount. A coin is a coin.
A price, a balance, an exchange listing: anything that assumed one supply of this token now has to track two.
What the spec's own authors said about this
This demo is a simplified stand-in for KCC-0020, a draft Kaspa token rule that lets an issuer update the state of some holders and not others. Issue #14, opened by Knitser on kaspanet/kccs, August 21, 2026, reports that this same mechanism permanently splits a token's supply once triggered. Two KCC-0020 co-authors replied. This is not a universal bug: one pattern below is defended as intended, a different one is conceded as a wrong pattern the standard does not yet handle. The reporter never withdrew his concern, and the issue is still open.
“My view is that the combination of extended state, alongside token-specific entry points, allows for various use cases which are not only write-once, nor only for a singleton token. The standard transfer function, though, is meant to transfer fungible tokens, hence, it assumes that inputs and outputs state (excluding ownership and amount) must be identical (or else could not be treated as fungible)” Sivan Helfer (Manyfestation), KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I can relate bcs example extensions that come to mind indeed illustrate this. for instance a frozen bool indicator which can be used by stable coin issuer for black listing, indeed renders the token as temporarily non fungible.”
Michael Sutton, KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I had one conceptual exception, but I think it means it's a wrong pattern. The example would be some contract using the ext state for storing receipt-like information… It mutates all the time but isn't part of the state that matters. I guess this pattern only makes sense if it was well defined as part of the std, and not as an opaque virtual state” Michael Sutton, KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I agree that kind of pattern should either be defined in the standard or implemented in a non state storage (maybe the payload, as you once suggested).” Sivan Helfer (Manyfestation), KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
KCC-0020 (Fungible Token Covenant Specification), authors Sivan Helfer, Michael Sutton, and Romain Billot, Status: Draft as of August 21, 2026. No spec change has merged as of this writing. Source: github.com/kaspanet/kccs/blob/main/kcc-0020.md.