On August 11, a contributor named Shawn reported that his own byte-saving shortcut in the KCC20 fungible-token spec let anyone mint tokens with no signature at all. He published the fix — three bytes — on the same day, before any builder had shipped code against the flaw. It is a clean example of why open review exists, and why "draft" means draft.
What KCC20 Is and Where It Stands
KCC20 is the proposed covenant-based standard for fungible tokens on Kaspa. It lives as an unversioned open pull request on the kaspanet/kccs repository. It has not been merged, versioned, or blessed by any formal process.
That has not stopped people from deploying tokens against it. The Toccata hardfork activated covenant support on mainnet on June 30, and builders have been experimenting since. The specification is the playground, but it is still being drawn.
This is the context in which Shawn, who is both a contributor to the spec and a builder working with it, proposed a small optimization days before August 11. The shortcut saved bytes in the transaction structure. It also, as he discovered, removed the signature requirement from one class of input entirely.
The Bug: Mint Without a Signature
The core of covenant-based token logic is authentication: proving that the entity moving or creating tokens has the right to do so. Shawn's shortcut exempted one input from that authentication check in order to reduce transaction weight.
His own summary is precise:
"If you exempt one input from authentication to save bytes, that input's own flags become the whole security boundary."
Translated: the thing that was supposed to be secured became the only thing enforcing security. Any holder of KAS — not just the token deployer — could have minted arbitrary quantities of the token, because no signature was required to authorize the mint. The flags on the input were the lock, and the flags were open by design.
This is not a subtle cryptographic failure. It is a logic error in a draft document, the kind that happens when you are iterating fast on a new primitive. The important part is what did *not* happen: nobody shipped a wallet, a DEX, or a token bridge that trusted the flawed shortcut.
Three Bytes
The fix restored signature verification on the exempted input. Three bytes. The diff is trivial; the consequence of not catching it would not have been.
Shawn found and reported the bug himself. He published the fix in the same pull request. The spec remains a draft. This is, by any reasonable standard, the system working correctly — open source, open review, early detection.
Why This Matters Beyond KCC20
Toccata covenants are roughly seven weeks old on mainnet. The covenant UTXO set has grown to 2,730, its highest recorded count, even as the number of transactions creating covenant-bound outputs has declined 92.6% from its August 1 peak. Development is active but early.
Silverscript, the language covenants are written in, merged its first security policy on August 11 — one day after a hardening pass, and prompted by a builder who discovered that a signature function did not behave the way he assumed. He reported it privately rather than posting details publicly. The maintainers told him it had already been fixed upstream. His practical note for others: if you are pinned to an older compiler, verify that the signature builtin you call actually lowers to a verify.
Meanwhile, there is no standard way for a wallet to discover, decode, or spend a covenant token's state. A team running a covenant token on testnet described the situation bluntly: "The app is the actor right now, and has to be. We ship the wallet inside the app… Nobody else's wallet can touch our token without reimplementing all of it." The fix — a descriptor spec, a reader spec, a writer spec — exists only as draft design.
This is the landscape. Covenants are live. Tokens are being deployed. But the specifications are drafts, the tooling is fragmented, and the security surface is still being mapped. The KCC20 mint bug is not an alarm; it is a data point about the pace and the risk profile of this phase.
What It Means for Kaspa Holders and Builders
If you hold KAS and are watching the covenant ecosystem develop, the takeaway is not "covenants are broken." The Toccata consensus layer and the Silverscript compiler are separate from any individual token specification. The bug was in a draft, found by a draft author, and fixed before anyone depended on it.
What it *should* reinforce is caution around deploying capital against unversioned specs. A token that looks like it works may be relying on assumptions that have not yet survived public scrutiny. The three-byte fix is a reminder that small things carry outsized weight in contract logic.
The same principle — open contracts, keys on your device, code you can inspect — runs through everything built on Toccata. Kaspa Safe's vault contracts are open source with 25 self-test checks in the node's VM; the alarm key and inheritance paths are visible on-chain, not hidden behind a platform. When the spec is still being written, inspectability is not a luxury. It is the minimum.
The Broader Covenant Picture This Week
Shawn's bug was the sharpest story, but the week of August 10–14 carried several related signals:
- DAGKnight's first tie-breaker left the TODO stage.
coderofstuffmerged a working implementation on August 12 on thedagknightfeature branch, not onmaster. Nothing on mainnet, no activation date. This is the parameterless successor to GHOSTDAG, and the tie-breaking rule handles the case where two competing groups of blocks finish the search tied.
- kaspa-x402 Alpha.10 landed on August 10 — a testnet binding for the x402 payment-required scheme, rebuilt on Toccata covenants so payments survive top-ups and partial claims. The release notes carry their own caveat: testnet only, not a mainnet-readiness claim.
- Kaspa's daily transaction count sits around 84,000, down more than 99% from 11.8 million in the second week of June. The decline is real, but the conclusion most people would draw is wrong. On June 30, the Toccata hardfork raised the minimum relay fee from 1 sompi per gram to 100 — a hundredfold increase in the cheapest transaction a node will accept. That is a mempool policy rule, not a consensus rule; zero-fee transactions remain consensus-valid. The bulk of the pre-fork volume came from Kaspadrome, which appears to be offline since the hardfork and is likely working to accommodate the changes. The number measures what nodes relay, not what the network can do.
Each of these items — a spec bug, an algorithm milestone, a testnet payment binding, a fee-policy shift — is a piece of the same early-stage buildout. The pattern is clear: serious engineering, public iteration, no premature claims.
Three Bytes and the Value of "Draft"
The KCC20 mint bug will not be the last flaw found in a Kaspa covenant specification. Covenants are a new primitive on a young contract layer. What matters is the shape of the feedback loop: open proposals, contributors testing their own work, fixes published before damage, no one pretending the draft is production.
Shawn's three bytes are a small patch. The habit that produced them — build, break your own thing, fix it in public — is the thing worth keeping.
FAQ
What is KCC20?
KCC20 is the draft specification for fungible tokens on Kaspa, built on Toccata covenants. It is still an unversioned open pull request on kaspanet/kccs and has not been formally released.
What was the KCC20 mint bug?
A byte-saving shortcut proposed by contributor Shawn allowed anyone to mint tokens without providing a signature. The authentication exemption meant the input's own flags became the only security boundary, which was trivially bypassable.
How was the bug fixed?
Three bytes. The fix restored signature verification on the affected input before anyone had built production tooling on the flawed draft.
Has KCC20 been deployed on mainnet?
Tokens have been deployed against the draft spec, but KCC20 itself remains a pull request with no versioned release. Wallet support for covenant tokens is still fragmented, with each project shipping its own implementation.
Does this mean Kaspa covenants are unsafe?
No. The bug was in a third-party token specification, not in the Toccata consensus layer or Silverscript compiler. It was caught and fixed during open review, which is exactly how draft specifications are supposed to work.
Put your KAS where theft can be cancelled
A covenant vault on Kaspa mainnet: your keys, your rules, our tooling. Free on-chain, forever.
Create a vault
