In the specification repository, KCC1 is the vocabulary, not the token. KCC-0001 defines shared terminology, byte layouts and calling conventions for covenants on Kaspa, and contains no token logic at all. The fungible token standard is a separate proposal, KCC-0020. Both live as open pull requests in the kaspanet/kccs repository, both still need at least one approving review, and neither has been merged. Separately, at least one project uses the name KCC1 for its own proposed token standard, which is a different thing again. That collision is covered below.
In the author's own words, the specification "defines common terminology, byte layouts, and application binary interface conventions for covenants on Kaspa." Concretely, it covers:
Two sentences from the proposal matter more than the list. "KCC1 is independent of any source language, compiler, framework, or artifact format." And: "It does not change consensus rules." This is not a protocol upgrade and it is not a token. It is an agreement on what words and byte layouts mean, so that later specifications can use them without redefining them.
An ERC-20 token works because every Ethereum contract is a global object with a stable interface. You call transfer and the contract handles the rest internally. On a UTXO chain there is no global object. A covenant is a rule attached to a coin, and every state transition has to be constructed and proven inside the transaction itself. Before anyone can write "the token standard," the ecosystem first has to agree on how a covenant's state is laid out in bytes, how you address a piece of it, and how you identify the same contract across two spends. That agreement is KCC-0001.
This is the part almost nobody sees, and it is the reason "is my token compatible?" currently has no clean answer:
| Proposal | What it covers | Status as of 14 aug 2026 |
|---|---|---|
| KCC-0001 | covenant terminology, byte layouts, ABI. the base everything else builds on | open, review required, no approving review |
| KCC-0020 | fungible token covenants. the actual token standard | open, review requested from two maintainers |
| KCC-0008 | a multi-token standard covering fungible, non-fungible and mixed profiles | submitted, its author is asking to converge with KCC-0020 |
| KCC20V2 | an implementation already shipped by KaspaCom | compatibility with the drafts is an open question in its own tracker |
One reviewer on KCC-0008 puts the stakes plainly: the goal is "a single unified standard that prevents the fragmentation other ecosystems experienced." That fragmentation is not hypothetical here. There are currently at least three overlapping token proposals plus one shipped implementation, and the base vocabulary they all depend on is itself unmerged.
"I think this should be reviewed once KCC-0001 is merged, or at least in light of it."
There is a second kind of fragmentation running underneath the first one, and it has nothing to do with code.
In the specification repository, KCC-0001 is explicitly not a token standard. Its own text states that it is "independent of any source language, compiler, framework, or artifact format" and that it "does not change consensus rules." The authors abbreviate it KCC1 throughout.
In August 2026, the team behind KaspaKaha described their work in the official Kaspa Telegram as "KCC1 is our proposed token standard for Kaspa". In the same thread they were clear about its status, calling it "a proposal, not a launch", running on testnet-10 only, with no mainnet deployment yet.
So the same four characters currently point at two different things. A byte-layout and vocabulary specification on one side, a proposed token standard on the other. Nobody involved is hiding anything, and both efforts are open about what they are. But if you have been trying to work out what KCC1 means and getting contradictory answers, that is the reason.
The same thread contained the substantive version of this argument. One community member asked whether a proposal should not first go to the shared forum, have its trade-offs debated and converge on a common standard before a new one appears, warning that the ecosystem risks repeating an earlier episode where several competing standards fragmented it instead of converging. The reply was that a working reference on testnet, with tools that actually run, is easier to converge around than a specification on paper.
Both positions are reasonable and both argue for the same outcome, which is one standard rather than four. A naming collision works directly against that outcome, because two groups can agree on every technical point and still spend months talking past each other about which document they mean.
The most common complaint in Kaspa communities right now is that the token standard is slow. The review discussion contains the real answer, and it is more interesting than "developers are slow."
On Ethereum, a contract lives on chain as a global object with persistent state. It can hide its implementation behind a stable callable interface, so a wallet building a transaction needs to know almost nothing about the contract's internals. Kaspa's layer 1 does not work that way. As Michael Sutton describes it in the review, the entire transition and verification logic must be supplied in each transaction — which means the transaction builder has to know every detail of how that specific token works.
This produces a very concrete failure mode, raised by an implementer during review. A specification that describes state layout and template bytes is enough for a reader: an explorer or a wallet can look at a UTXO and correctly recognise "this is a token, this is the balance." It is not enough for a writer. An independent wallet that wants to construct a transfer also needs the witness framing, the entrypoint selectors, the input and output ordering, the compatibility rules and the practical mass limits. Without an exact recipe, a wallet can display your token but cannot safely spend it.
That gap is the difference between "a token exists on chain" and "every wallet supports it," and it is why the standard cannot simply be declared finished.
Reviewers flagged issues that will affect anyone using these tokens, not just the people writing them. There is currently no canonical type for a script public key, which means every protocol invents its own encoding for something as basic as a pinned destination address — one reviewer notes that cross-covenant interoperability "dies at the first pinned address" if this is not fixed. And the default hash function was changed from blake2b to blake3 during the review, after conformance vectors had already been tested against the earlier revision. This is a draft that is still moving.
None of the above means the work is theoretical. Two independent implementers reported production measurements during review, and the numbers are worth knowing:
Read together, those four figures say something precise. The encoding works — thousands of real reveals verify against it without a single mismatch. But the conventions the specification proposes are not yet what the chain actually does. The standard is describing where the ecosystem is going, not where it already is.
Kaspa's storage mass rules put a practical value floor of roughly 0.1 KAS on a standard output. Every covenant state transition creates an output, so that floor applies to every transition and sets a hard minimum on how small a token instance can be. An implementer flagged this as becoming acute for token covenants specifically, "where many small instances are the natural shape." If you ever wonder why dust-sized on-chain token positions behave strangely, this is why.
It is the byte-layout and vocabulary specification underneath one. If a project describes its token as "KCC1", that describes the encoding conventions it follows, not a ratified token standard. The token standard it is presumably aiming at is KCC-0020, and that is a different document with a different author.
The word appears in announcements and reads like a stamp of approval. In practice it means conforming to a proposed layout in an unmerged draft that has changed during review. That is not an accusation against anyone. Building against a draft is completely normal in open protocol development, and early implementers are exactly the people who produce the production feedback that improves a specification. It does mean the word carries less weight than it sounds like it does. It is also worth checking which network an announcement refers to, because at the time of writing the KCC1 token work runs on testnet-10 and not on mainnet.
Reading KCC-0001 tells you how bytes are meant to be arranged. It tells you nothing about whether any particular contract is correct, whether its author can change the rules later, or whether the pool you are trading against is honest. Those are separate questions and they are not answered anywhere in the repository.
kaspanet/kccs repository on GitHub, together with their review threads. Status figures on this page were read on 14 august 2026 and will change — check the repository before relying on them. We report what the documents say, never what we think the people behind them intend.