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 specification, KCC-0020. Both advanced to Final in the kaspanet/kccs repository on 21 October 2026, together with KCC-2 for authority schemes. 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 the following.
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.
On an account-based chain a token works because every 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?" still 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 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 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 these days is that the token standard is slow. The review discussion contains the real answer, and it is more interesting than "developers are slow."
On an account-based chain, a contract sits 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 still 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, so check the repository before relying on them. We report what the documents say, never what we think the people behind them intend.KCC1, formally KCC-0001, is a proposed specification that defines common terminology, byte layouts and application binary interface conventions for covenants on Kaspa. It defines canonical state and argument codecs, entrypoints and dispatch tags, the P2SH envelope of a covenant program, covenant state and templates, Covenant ID lineage, leader and delegator roles, and virtual elements. It is independent of any source language or compiler and does not change consensus rules. It is not a token standard.
In the kaspanet/kccs specification repository, no. KCC-0001 is the shared vocabulary and byte layout specification that token standards build on, and the fungible token standard there is a separate proposal called KCC-0020. Confusingly, at least one project uses the name KCC1 for its own proposed token standard, which is a different document. The same abbreviation points at two different things.
Yes, since 21 October 2026. KCC-1, KCC-2 and the fungible token standard KCC-20 advanced to Final in the kaspanet/kccs repository on that day. A finalized KCC marks a point the ecosystem converges on, it does not change consensus rules, and each wallet still has to add support.
On an account-based chain a contract is a global object with persistent state and a stable callable interface, so a wallet building a transaction needs to know little about its internals. Kaspa's layer 1 is UTXO based and verification focused, so the full state transition and verification logic must be supplied inside every transaction. That means the transaction builder needs to know the specific details of each token implementation, which is why the specification also needs an exact writer recipe and not only a state layout.
As of August 2026 there are at least three overlapping proposals plus one shipped implementation. KCC-0020 covers fungible token covenants, KCC-0008 proposes a unified multi-token standard covering fungible, non-fungible and mixed profiles, and KaspaCom has an implementation called KCC20V2 whose compatibility with the drafts is being clarified in its own tracker. All of them depend on the base specification KCC-0001, which is itself unmerged.
Not as of August 2026. The team behind the KCC1 token work stated in the official Kaspa Telegram that it is a proposal rather than a launch, running on testnet-10 only, with no mainnet deployment yet. The underlying specifications in the kaspanet/kccs repository are also still open pull requests without an approving review.
Not automatically. A specification describing state layout and template bytes is enough for a reader, so an explorer or wallet can recognise a token and display a balance. Constructing a transfer additionally requires witness framing, entrypoint selectors, input and output ordering, compatibility rules and practical mass limits. Without that exact recipe an independent wallet can display a token but cannot safely spend it.
Building on Kaspa? We review projects and run testnet load tests before launch.
follow kaspa pulse