A token can follow the same broad rules as another token and still use a different program to control how it moves. That flexibility sounds useful until an ordinary wallet must build a transaction without guessing which program belongs there.
That was the central tension in Kaspa research from August 17 through August 23. The KCC-20 token proposal became a public draft, then immediately drew questions about token identity, programmable ownership, and wallet compatibility. Elsewhere, scripting work moved closer to stability, while node improvements for large UTXO lists and more portable consensus code remained under review.
The week in one minute
- KCC-20 entered the repository as a draft token convention. It is now ready to be challenged, not treated as approved or final. Source
- The first scrutiny exposed a wallet-facing ambiguity. Developers agreed that the document should clarify which script template identifies a token’s spendable outputs. Source
- SilverScript gained an ECDSA signature-checking standard function, and related compatibility work suggested that major SilverScript-driven breaking changes may be nearing an end. Source
- UTXO pagination returned for review after revisions. Its author was still waiting to run a live test on synchronized nodes, so the work was not yet proven complete. Source
- A portable,
no_stdconsensus-core proposal gained a dedicated review thread. It remains a pull request and does not include the separate Malachite replacement effort. Source
The big story: KCC-20 is public, but wallets need a clearer identity rule
Imagine receiving a parcel marked with the right product name but sealed inside one of several unfamiliar containers. A person might inspect the package and work out how to open it. A generic delivery machine needs a precise rule.
Wallets face a similar problem with programmable tokens. They must know how to construct a valid transfer automatically, including which locking program should appear in the transaction’s outputs. If a token can move between several different program shapes without an unambiguous identity rule, a general-purpose wallet may not know what to create next.
That practical problem surfaced almost immediately after KCC-20 was merged as a draft. KCC stands for Kaspa Calls for Convention, a process for documenting shared application conventions. Draft status matters: the proposal is available for implementation discussion and criticism, but the archive does not show it being approved as a final standard.
KCC-20 describes a convention for tokens built with covenants. A covenant is a programmable spending rule that can restrict not only who may spend coins, but also what the next transaction must look like. This can let an application carry state forward from one transaction to another.
That state lives in UTXOs, or unspent transaction outputs. A UTXO is a discrete piece of value or state that has been created but not yet spent. A wallet consumes existing UTXOs as transaction inputs and creates new ones as outputs.
The question raised during review was deceptively simple: if several different scripts share the same covenant identifier, can each script authorize or hold the same token?
The initial response was that a KCC-20 application could permit transitions between different scripts, provided each one implemented the convention’s standard transfer entry point. That would preserve composability, meaning wallets and applications could interact through a common interface. Source
But Michael Sutton identified the wallet problem underneath the flexibility. The draft appeared to assume that every token UTXO associated with a given covenant identifier would use one identical template. Without that assumption, he asked, how would a generic wallet compose the transaction? Source
A template is the fixed structure of a covenant script, separate from the state inserted into it. Developers discussed identifying that structure with a template hash, a compact cryptographic fingerprint. Under the proposed reasoning, a complete identity would combine the broader covenant identifier with the template hash. Source
In plain language, the covenant identifier can name the application family, while the template hash identifies the exact kind of programmable container holding the token.
The discussion then separated two issues that had become tangled together. First, which template is allowed to own the token? Second, may the token application deliberately move its state into another template through a special transition?
Manyfest argued that an application could support more than one template while ordinary wallet transfers kept the token in its current template. Other application-specific actions could move it to a new template if the design allowed that behavior. The possibility was presented as optional, and no concrete use case was established in the discussion. Source
The clearest point of agreement was narrower: using a single template for the asset UTXOs is acceptable, while an application may use other templates for other roles. More importantly, the fact that reviewers interpreted the draft differently showed that this assumption should be stated more explicitly. Source
For users, the eventual payoff could be predictable token transfers across compatible wallets. For wallet builders, the draft still needs to make the transaction recipe unmistakable.
For developers: The emerging identity model was described as covenant ID plus template hash, with SilverScript and Argent representing the template as a prefix-and-suffix structure. The open design space is whether standard asset transitions must preserve one template, while separate entry points may authorize controlled migration to another.
KCC-20 therefore made real progress this week, but not because it settled token design. Publication converted hidden assumptions into reviewable questions. That is exactly what a draft is supposed to do.
What else moved forward
SilverScript filled a signature gap as compatibility work approached calmer ground
SilverScript gained a standard function for checking ECDSA signatures, completing an item that had been left as a reminder earlier in the week. ECDSA is a cryptographic signature method used to prove that a transaction was authorized by the holder of a corresponding private key. The merge was confirmed on August 23.
A separate SilverScript pull request was also rebased onto the current main branch and merged. Earlier discussion showed that the language’s type checker currently focuses mostly on exact type equality, with hierarchical types left as a future ambition rather than completed functionality. Source
The wider significance is compatibility with Argent, another language in the same emerging covenant tooling environment. A pull request was opened for what Sutton called the “final catch-up” on the SilverScript side. He expected no more significant SilverScript-driven breaking changes after it, while carefully noting that smaller adjustments could still occur and Argent could introduce changes of its own. Source
That is an expectation, not a stability guarantee. Still, fewer foundational changes would let language and application developers spend less time chasing moving interfaces and more time testing what they can build with them.
UTXO pagination is closer to review, but still awaiting a live test
Software that requests a large list of UTXOs should not have to receive everything in one enormous response. Pagination divides the result into manageable pages, reducing the burden on nodes, applications, and network connections.
A long-awaited pagination pull request returned after changes based on reviewer feedback. Its author said it could be reviewed again, but was still waiting for nodes to synchronize before conducting a live test. Source
That status distinction is important. The code has been revised and is available for another review, but the archive does not show a completed live test or merge.
For wallets and services that inspect addresses with many outputs, pagination could make data retrieval more controlled and practical. This week’s result was renewed momentum, not delivery.
A no_std consensus core could make Kaspa’s core logic more portable
A proposal to make consensus-core code work in a no_std environment received its own discussion topic and was flagged as a sought-after feature. In Rust, no_std means code can operate without the language’s normal standard library, which is useful in constrained or specialized environments.
The author clarified that reviewing the work does not require cryptography or low-level expertise, widening the pool of potential reviewers. Source
The proposal remains under review. It also does not replace Malachite, a separate component whose replacement is being handled in another pull request. Source
The immediate consequence is architectural rather than user-visible: reducing reliance on the standard library can make important code easier to reuse in more environments. Whether this particular proposal is ready still depends on review and testing.
Core cleanup passed review and reached the codebase
Maintenance work also advanced in rusty-kaspa. Reviewers approved several Toccata cleanup pull requests, with one identified pull request explicitly confirmed as merged. Another reviewed change was adjusted for readability, approved, tested, and then reported merged. Source
These changes do not promise a new wallet feature. Their value lies in keeping core code easier to understand and safer to modify. Even the small debate over whether a boolean conversion looked like validation or value extraction reflected that goal: code should communicate its intent to the next reviewer, not merely produce the correct result.
What is decided, and what is not
Completed or confirmed
- KCC-1 and KCC-2 were published as draft Calls for Convention. Source
- KCC-20 was merged into the KCC repository with draft status. Source
- SilverScript pull request 163 was rebased and merged. Source
- The ECDSA signature-checking standard function was reported merged. Source
- Reviewed cleanup work in
rusty-kaspawas merged. Source
Proposed, testing, or unresolved
- KCC-20 is not final. Its rules for asset templates and optional template transitions need clearer wording and further challenge.
- The Argent catch-up exists as a pull request; the archive does not confirm its merge.
- UTXO pagination has revisions ready for review, but its live test was still pending.
- The
no_stdconsensus-core work remains a pull request. - Hierarchical type support in SilverScript is a future intention, not a completed feature.
What happens next
- Watch for KCC-20 text that explicitly defines whether standard token UTXOs must retain one covenant template.
- Look for concrete challenges to the draft’s wallet-composability assumptions and any examples that justify transitions between templates.
- Check whether the Argent catch-up is accepted and whether compatibility work reveals further breaking changes.
- Follow the UTXO pagination live test and subsequent re-review.
- Watch for broader review of the
no_stdconsensus-core proposal and a clearer account of where that portability is intended to be used.
The week began with a token convention becoming visible and ended with its most important assumption under examination. KCC-20 is not finished, but it has crossed a useful threshold: wallets, language designers, and application builders can now test whether the same draft actually means the same thing to all of them.