A language designed to make Kaspa smart contracts readable and maintainable reached its first v1 release candidate on August 30. That is more than a version number: if testing holds, developers could soon build stateful contracts without writing directly in Kaspa Script’s lower-level machinery.
The tension is that a release candidate is deliberately unfinished proof. During August 24–30, developers merged major compiler work, challenged how contracts identify callable functions, and asked users to hunt for regressions. The next milestone depends on what that testing reveals.
The week in one minute
- Silverscript v1-rc1 was released. It is intended to behave like the upcoming v1, which is planned for mainnet use one week later unless substantial issues appear. Developers are being asked to test contracts now. Source
- Argent’s compiler internals were substantially rebuilt. The merged refactor improves how higher-level contract state and input references map into generated Silverscript, but its author warned that the work is not fully closed. Source
- Entry ranges landed in Argent. This gives contracts a way to work with ranges of transaction inputs under updated reference rules, following review and fixes. Source
- A post-quantum vault prototype spent successfully on TN10. It used hash-based signatures verified by existing Kaspa script capabilities, but remains unaudited and heavily assisted by large language models. Source
- Developers explored better contract discovery and time proofs. Both the proposed covenant index and the script-level clock involve important trade-offs and remain design work, not shipped network features. Sources, source
The big story: Silverscript v1-rc1 turns “almost ready” into a public test
Imagine maintaining a contract whose rules govern funds or shared application state. Writing those rules is only half the job. Other people must be able to read them, tools must encode calls correctly, and compiler upgrades must not quietly reinterpret what the author meant.
Silverscript is intended to address that problem. It is a high-level smart contract language that compiles into Kaspa Script, letting developers express stateful contract behavior in a more readable form. On Sunday, the project published v1-rc1, its first release candidate after review, testing, and standardization work. The team describes it as functionally equivalent to the intended v1 release. Source
The practical consequence is straightforward: Kaspa application developers now have a concrete build to test rather than a moving development target. If no substantial issue appears, the stated plan is to release v1 for mainnet use one week after the candidate.
That does not make v1-rc1 production-ready by declaration. Its purpose is to expose precisely the problems that internal review can miss, including bugs, inconsistent behavior, unclear language rules, and documentation gaps. The release announcement explicitly asks developers to test both existing and new contracts.
The final stretch changed more than the version number
Several merges prepared the ground. SilverScript pull requests 221 and 222 landed during the week, including work relevant to dynamic arrays of structured data and an independent compiler representation API. Pull request 219 also merged and became the base for ongoing function-identification work. Sources, source, source
That representation is called an abstract syntax tree, or AST: a structured model of source code that compiler tools can inspect and transform. Developers later opened paired SilverScript and Argent changes described as the final AST adjustments SilverScript should require before release. The Argent half merged on August 30; the SilverScript half was still presented as pending in the archive. Sources, source, source
Argent, a related higher-level compiler project, also merged a large internal refactor. It consolidated several ways that contracts refer to transaction inputs and improved the mapping between developer-visible state and its physical representation. Michael Sutton called it a major change and asked application authors to upgrade, test thoroughly, and report regressions. He also noted small breaking changes for which the compiler should guide users. Source
For developers: Argent pull request 50 unified reference handling across the contract’s own input, consumed peer inputs, and observed peer inputs. Pull request 44, covering entry ranges, was then rebased onto those semantics, reviewed, corrected, and merged at the end of the week. Sources, source, source
The result is real but bounded. SilverScript has a public release candidate, while Argent has completed important prerequisite work and is moving toward its own stability and audit phase. The decisive evidence will come from contracts compiled and exercised outside the core development loop.
What else moved forward
A tiny function label exposed a cross-language compatibility problem
Wallets and applications need an unambiguous way to select a contract function. The week opened with a case where two functions could receive the same identifying tag even though their structured arguments contained different field sizes.
That matters because an application binary interface, or ABI, is the shared rulebook describing how software encodes calls and data. If two genuinely different call shapes appear identical, a generic wallet or tool could construct the wrong request.
The proposed correction is to derive the dispatch tag, the compact identifier used to select a function, from the actual ABI-level structure rather than merely a named record. Developers agreed that grouping must remain visible because grouped fields have linked lengths and therefore represent a different interface. KCC-01 and SilverScript pull requests were opened, but the archive does not show them being merged. Sources, source, source
A second discussion clarified what the compiler should emit. Hexadecimal text would make tags easier for humans to recognize, but would burden every encoder and decoder with conversions. The proposal was revised to keep raw bytes as the portable ABI form, leaving friendlier display formats to libraries or ecosystem tooling. Source
For builders, the payoff is fewer opportunities for two languages or wallets to disagree about what a contract call means. The design direction became clearer, but implementation approval was still pending.
Finding contract-controlled funds needs an index, and every ordering favors someone
A UTXO is an unspent transaction output, an individual piece of value or state that can later be consumed. A covenant is a contract-like rule that restricts how such an output may be spent. As covenant activity grows, wallets and services may need to find every UTXO governed by a particular covenant.
Developers discussed a secondary database index for that purpose. The central trade-off was the order of its keys: should it make searches by owner script faster, or prioritize chronological pagination across the covenant?
Pagination means retrieving a large result set in manageable pages. Developers considered ordering records by covenant identifier and DAA score, a measure of accumulated network activity used here to navigate records over time. That supports fetching recent entries across a covenant, while filtering for a particular spending script may require a broader scan. Putting the script first reverses the advantage. Sources, source
The conversation also uncovered a client-side trap. A cursor based on DAA score is not automatically a permanent checkpoint because reorganizations can change recent UTXOs. Clients may need to watch chain changes and revisit an earlier position rather than assuming every previous page is final. Source
Database snapshots could provide a frozen view between page requests, but keeping snapshots alive can prevent storage files from being pruned and may conflict with in-memory caches. Several participants therefore advised against casually adding that feature. Sources, source
No final index design appears in the archive. What did emerge is a sharper requirement: contract discovery should not slow existing UTXO queries, and an apparently simple cursor needs explicit reorganization handling.
Existing script features powered an unaudited post-quantum vault
A developer presented a proof of concept for a vault protected by hash-based signatures intended to resist future quantum attacks. The prototype verified those signatures directly in Kaspa script and reportedly spent successfully on the TN10 test network using both SLH-DSA and LMS designs.
The notable claim was not that Kaspa had adopted post-quantum security. It was that the experiment required no new opcode, precompiled verifier, or zero-knowledge proof. According to its author, Toccata’s existing capabilities were sufficient. The reported spends cost 0.2339 TKAS and 0.0597 TKAS respectively. Source
The limitations are equally important: the repository was described as unaudited and heavily assisted by a large language model. This is experimental evidence, not a reviewed wallet product or protocol decision.
Still, the prototype narrows a practical question. Post-quantum custody may be explorable at the script level before the network adopts specialized cryptographic machinery. Whether that approach is safe, economical, and usable remains open.
Contracts may be able to prove “recent time,” within a wide window
Transaction time can reliably prove that a point in time has passed, but a lower timestamp does not necessarily prove that the claimed time is still in the future. That asymmetry complicates contracts that need to record a trustworthy start time and unlock another branch much later.
Developers identified a post-Toccata approach using a chain-block sequence commitment. A script could check a block hash and prove the timestamp included beneath its commitment. Consensus would establish that the referenced chain block came from roughly the last 12 hours, producing a clock that is recent and not from the future, but only at approximately 12-hour granularity. Sources, source
An alternative would use a specially structured UTXO as a DAA oracle, meaning an on-chain reference that represents network progress. That could offer finer granularity, but it depends on additional state and measures DAA progress rather than ordinary time. Participants proposed documenting both approaches and their trade-offs; one utility implementation in Argent was only a possibility. Sources, source
The discovery shows that time-sensitive covenant designs may not require a conventional clock. It does not yet establish a standard developer interface.
What is decided, and what is not
Completed or confirmed
- SilverScript v1-rc1 is released, with semantic versioning adopted for the v1 series. Source
- SilverScript pull requests 219, 221, and 222 were reported merged. Source
- Argent’s major state and input-reference refactor merged, with explicit regression-testing guidance. Source
- Argent’s AST API work and entry-range implementation merged. Sources, source
- A reversed SilverScript loop range will produce zero iterations, following the empty-range interpretation. Source
Proposed, experimental, or unanswered
- Revised ABI-derived dispatch tags had open KCC-01 and SilverScript pull requests, with no merge confirmed in the archive. Source
- Covenant-index key order, cursor validity, and safe pagination across reorganizations remained under discussion. Source
- Snapshot-backed pagination was discussed but drew architectural and storage concerns. Source
- The post-quantum vault is an unaudited proof of concept, not an endorsed production design. Source
- The recent-time proof and DAA-oracle alternative need comparison and documentation. Source
What happens next
- Release-candidate testing: watch for contract regressions, unclear semantics, or documentation problems that could delay SilverScript v1.
- The mainnet v1 decision: absent substantial findings, the stated target is one week after v1-rc1. Source
- Dispatch-tag review: the open specification and compiler changes need a final decision on ABI-derived function identity.
- Argent stabilization: its newly merged refactors and entry ranges now need application-level testing before Argent can enter a broader stability and audit phase.
- Evidence from experiments: the post-quantum vault needs independent scrutiny, while the two proposed clock approaches need clearly documented trade-offs.
This week produced a candidate rather than a coronation. SilverScript’s language work is close enough to invite mainnet expectations, but the most useful thing developers can do now is try to break those expectations before real contracts depend on them.