A four-byte label may determine how easily future wallets and applications interact with Kaspa contracts. This week, developers opened code changes that would give contract functions predictable identifiers, much like extension numbers route callers to the right person.
The code exists, but the rules are not settled. Between July 19 and July 26, the discussion shifted from how those labels should be calculated to a more consequential question: should every function call include one, even when a contract has only a single possible destination?
The answer could decide whether basic calls work from shared conventions or depend on extra information supplied by each contract.
The week in one minute
- Two SilverScript pull requests proposed BLAKE3-based contract template hashes and four-byte function tags, bringing the compiler closer to the KCC-01 calling convention. They were opened, not reported as merged.
- Developers questioned whether every contract call should carry a function tag. Doing so could make common calls independent of contract-specific artifacts, but would depart from the current single-entry-point optimization.
- Explicitly typed array literals gained support in discussion after type inference caused two compiler bugs. The syntax remains a proposal.
- Argent introduced breaking syntax changes intended to align it more closely with SilverScript, while its lightweight audit artifact remains unfinished.
- A Rust Stratum bridge fix targeted a metrics endpoint whose memory growth could eventually cause monitoring requests to time out.
The big story: Four bytes could remove a contract dependency
Imagine entering a building with only one office. Today, SilverScript can decide that no room number is needed because there is nowhere else to go. That saves a small piece of information, but it creates a special rule: callers must know whether the building has one office or many.
Contract calls face a similar problem. A contract may expose one or several entry points, meaning named functions that outside software can invoke. When several functions exist, the call needs a selector telling the contract which one to run.
This week, IzioDev opened a pull request proposing that this selector, called a dispatch tag, be derived from the first four bytes of a BLAKE3 hash of the function signature. A function signature identifies a function through its name and expected inputs. The proposal follows KCC-01, a contract calling convention intended to standardize how software addresses contract functions (source).
In practical terms, the same function definition would produce the same compact label. Wallets, compilers, and other tools could calculate that label instead of negotiating a separate numbering scheme.
A companion pull request would use BLAKE3 for the contract template hash, a fingerprint representing the contract template. Both changes were described as relatively small, although one included additional renaming that its author acknowledged could add review noise. Neither pull request was reported as merged.
The exception may matter more than the rule
SilverScript currently omits the selector when a contract has only one entry point. Ori asked whether that optimization should be removed to conform more consistently with KCC-01 (source).
IzioDev recalled that KCC-01 itself permits no tag for a single entry point, but noted that unconditional tags might still be useful. The trade-off had not yet received a clear evaluation (source).
Michael Sutton supplied the strongest practical argument for always including the tag: it removes one contract-dependent fact from the caller’s job. Under that model, a basic KCC20 transfer call could always use the same structure instead of depending on a supplied artifact that explains whether a selector is required (source).
That is the payoff behind the headline. The four bytes are not important because they are clever or compact. They matter because predictable calls could make wallet and application behavior less dependent on contract-specific instructions.
The limitation is equally important: this remains an active design discussion. The archive records neither a final decision on unconditional selectors nor a merge of the related pull requests.
For developers: The proposed dispatch tag is the truncated first four bytes of a BLAKE3 hash over the function signature. The unresolved compatibility question is whether single-entry-point contracts retain selector-free encoding or adopt one uniform call shape.
What else moved forward
Explicit arrays could trade shorter code for fewer compiler surprises
SilverScript’s convenient array syntax has already produced two compiler bugs, prompting a proposal to make the intended type visible in the source code.
At present, [1,2,3,4] can mean either four integers or four raw bytes. The compiler decides from context, but those interpretations produce very different encoded values. Ori suggested replacing that inference with typed syntax such as int[]{1,2,3,4} (source).
For builders, the benefit is straightforward: code would say what data it creates. That could make contracts easier to review and prevent the compiler from choosing an unintended representation. IzioDev supported the move toward explicit syntax, but the conversation did not establish a final form or implementation decision (source).
For developers: The issue is contextual type inference at the literal itself, not merely display syntax. An explicit element type would simplify compilation while making byte-array and integer-array encodings distinguishable during review.
Signature names are being redesigned around intent, not machinery
A naming discussion exposed another usability concern: contract authors should not need to think in terms of the virtual machine’s internal stack when choosing a signature-checking function.
Ori proposed renaming checkSigFromStack, arguing that “stack” describes an implementation detail rather than what a SilverScript programmer is trying to accomplish. Alternatives included checkSigArg and, later, checkMsgSig (source).
The distinction matters because the language appears to support two different operations. One checks a signature tied to the transaction, while the other checks a signature over an arbitrary message supplied to the contract. IzioDev favored making the source of the signed digest explicit, while Ori preferred a dedicated checkTxSig(sig,pubkey) form over exposing a virtual transaction field that cannot be used elsewhere.
Michael Sutton suggested keeping the standard checkSig name and renaming only the special variant. He then agreed that checkMsgSig sounded suitable (source, source).
That is limited agreement on terminology, not evidence of a completed change. Still, the direction is clear: name the operation after what it verifies, not where an argument happens to sit internally.
Argent and SilverScript are converging, with some breakage along the way
Argent introduced breaking syntax changes designed to align it more closely with SilverScript and make the two languages more coherent (source).
Consistency can lower the mental cost of moving between tools, particularly when developers are already learning new contract concepts. The immediate cost is that existing Argent code may need adjustment because the changes were explicitly described as breaking.
Separate work on Argent’s post-covenant developer experience also advanced through a pull request, but one promised component remains outstanding: a lightweight audit artifact (source). An audit artifact is a compact output that helps reviewers inspect what a higher-level contract produced.
A covenant is a rule that restricts how coins may be spent in later transactions. Because such rules can carry behavior forward, readable tooling and review evidence matter as much as concise source syntax. The week produced concrete code, but not a finished audit workflow.
Separate indexes favor node flexibility at a storage cost
Developers also revisited how nodes might index covenant-related data. An index is an additional lookup structure that lets software find records without scanning everything.
The discussion distinguished two indexes with different key prefixes, including one involving a covenant identifier and a script public key, the locking condition that controls how an output may be spent. Maxim Biryukov argued that keeping the indexes separate would let a node run either one or both without requiring lookup tables needed only for a unified design (source).
The cost is additional storage when both are enabled. Michael Sutton said he tended to agree with the separate-index approach, but the exchange did not document a final specification or merged implementation (source).
For node operators, the proposed trade-off is more choice and simpler individual indexes in exchange for potentially greater disk use.
A monitoring leak threatened long-running Stratum bridges
A Rust Stratum bridge pull request addressed unbounded growth in its /metrics output, which had caused Prometheus monitoring requests to time out during long runs. It also included a webserver connection-handling fix (source).
This is operational plumbing, but it has a direct consequence: monitoring is least useful when it fails only after software has been running for a long time. The pull request was submitted during the week; the archive does not report its merge status.
What is decided, and what is not
Concrete work produced this week
- Pull requests now exist for BLAKE3 template hashing and four-byte SilverScript dispatch tags.
- Argent has a pull request containing syntax-breaking alignment changes.
- The Rust Stratum bridge has a proposed fix for connection handling and runaway metrics growth.
- Developers agreed that
checkMsgSigwas a reasonable name in the signature API discussion.
Still proposed or unresolved
- Whether single-entry-point calls should always include a dispatch tag.
- The final syntax for explicitly typed SilverScript array literals.
- Whether the signature API should expose digest sources directly or retain dedicated transaction-signature helpers.
- The final design and implementation status of separate covenant indexes.
- Completion of Argent’s lightweight audit artifact.
Broader cleanup work also remains queued. Sutton said he was prioritizing post-Toccata approachability and specification work, with cleanup expected to receive attention starting the following month (source). That is a stated priority, not a completion date.
What happens next
- Watch whether the two SilverScript hashing and dispatch pull requests are revised, merged, or held pending a selector decision.
- Look for a firm ruling on unconditional function tags, especially whether KCC20 calls should have one stable form.
- Expect a concrete typed-array syntax proposal or compiler change following the reported inference bugs.
- Watch for implementation of the
checkMsgSignaming direction and clarification of transaction versus arbitrary-message signature checks. - Look for the promised Argent audit artifact and further post-Toccata specification work.
This week’s central question began with four bytes and ended with a usability principle: shared rules can remove hidden knowledge from every wallet and application that follows. The prototype pieces are visible. The next edition should reveal whether that principle becomes the rule or remains an attractive exception.