After Toccata activation, the R&D channel stopped treating fungible-token and ABI talk as free-floating design chat. The concrete move was a new repo and process surface: kaspanet/kccs, described on GitHub as "Kaspa Calls for Conventions." (repo)
The naming debate came first. On July 9, Manyfestation asked where covenant conventions should live once the ecosystem agreed on rationale, practical contract shape, and acceptance process. Sutton suggested kaspanet/kcc or kaspanet/kccs, saying KIPs worked better with the plural "s." He also said governance should lean on kas-smiths threads and some form of voting. (source) (source) (source)
IzioDev gave the practical adoption test: "One of the easiest way is to convince wallet software." Manyfestation agreed that broader acceptance mattered and asked who decides whether a proposal lands in the main conventions repo. Maxim asked why KIPs did not fit. Sutton's answer was process hygiene rather than hostility to KIPs: convention proposals would clutter consensus and node-core proposal traffic. (source) (source) (source) (source) (source)
coderofstuff pushed back in the other direction. Standardization proposals can fit the KIP process, he said, especially when the goal is ecosystem convergence around a shared purpose. He also said many of those conversations should happen first on kas-smiths or elsewhere. IzioDev and Manyfestation still preferred a separate repo for ecosystem conventions, arguing that the people who should merge eco improvements are not necessarily the same group that owns consensus evolution. Arthur made the same layer distinction later: consensus evolution and ecosystem conventions have different feedback loops, and mixing them risks premature convergence. (source) (source) (source) (source) (source) (source) (source)
The repo then got real drafts. On July 15, Sutton pointed people at https://github.com/kaspanet/kccs and said IzioDev was composing what might be called KCC1, a spec for covenant and contract ABI. Manyfestation opened PR #2 for the fungible token covenant specification, continuing the earlier kas-smiths KCC20 thread. IzioDev followed with KCC-0001 draft material defining terminology, byte layouts, entrypoints, dispatch tags, P2SH envelopes, covenant state and templates, covenant ID lineage, leader and delegator roles, and virtual elements. (source) (source) (source) (source) (PR #2) (PR #3)
KCC-0001 is careful about scope. The PR text says it is independent of any source language, compiler, framework, or artifact format, and that it does not change consensus rules. Later specs may reuse the terms and layouts without redefining them. That is the ABI-first reading: common wire and state conventions first, language politics second. (PR #3)
KCC-0020 stays narrower and more contested. Manyfestation's PR presents a draft fungible-token covenant specification built from earlier R&D and kas-smiths iterations, with explicit thanks to Sutton and IzioDev. Maxim immediately asked whether issuance and metadata were out of scope. Manyfestation said issuance and other policies remain open, and that the current proposal leaves room for state and logic extension while arguing for a minimal shape. IzioDev reinforced the boundary: nothing in KCC20 stops a token from carrying extra metadata, but that material is outside the base standard. (source) (source) (source) (source) (PR #2)
Sutton's first review comment on July 16 said the design space was finally gaining clarity, "especially when reading KCC20 in light of KCC-0001." That pairing is the article. One draft tries to freeze common covenant ABI concepts. The other tries to freeze a minimal fungible-token interaction shape on top of those concepts. Neither is marked merged as of the current open-PR state. (source) (PR #2) (PR #3)
The publishable claim is process plus substance. Kaspa now has an explicit conventions track separate from KIPs, seeded by open KCC-0001 and KCC-0020 drafts, with the hard questions already on the table: who merges, what counts as base ABI, how much token policy belongs in the standard, and whether wallets will actually converge on the result.
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
