From September 6 through September 13, Kaspa R&D moved on several fronts. Silverscript reached version 1.0.0, Argent adopted that release, and developers documented additional security rules that have not yet been implemented.
Meanwhile, a proposed way for wallets and explorers to retrieve spendable funds exposed a data-consistency problem. Researchers also tested a potentially faster post-quantum component, DAGKnight development received merged contributions, and maintainers questioned whether Kaspa should require the newest Rust compiler.
The week in one minute
- Silverscript v1.0.0 was released. This gives builders a clear version milestone, but the archive does not establish that every related security feature is complete.
- Argent synchronized with Silverscript v1. A runtime improvement was also merged, while two newly documented security rules still await implementation.
- UTXO pagination remains under review. Developers agree that wallets and explorers need efficient access to spendable-output data, but they disagree over whether the proposed interface presents a consistent enough view.
- A post-quantum accumulator showed an early performance gain. On a development network, it reduced block-validation cost by about 4 percent compared with MuHash, but used more state and still needs security review.
- Two DAGKnight pull requests were merged. The archive confirms development progress, although it does not describe their contents or any user-facing effect.
The big story: Silverscript v1 creates a milestone, not a finish line
Programs that control digital assets need more than expressive features. They also need strict rules about which transaction data can be trusted.
Imagine a payment program receiving several labeled envelopes. If the program assumes that two envelopes belong together when an attacker can rearrange or substitute one of them, a seemingly correct rule could authorize the wrong result. Secure transaction programming therefore depends on carefully defining how related inputs are grouped and validated.
That is the problem behind this week’s most important release and its immediate follow-up.
Silverscript v1.0.0 was formally released on September 9. Silverscript is tooling for writing transaction conditions, meaning rules that determine when assets can be spent. A 1.0 release provides builders with a named, stable milestone around which related projects can coordinate.
One day later, Argent was synchronized with the released version. Argent is a related language project that incorporates Silverscript and provides runtime features for developers. The update means its codebase now follows the public Silverscript v1 release rather than an earlier revision.
That practical coordination matters. When connected tools target the same release, builders have a clearer foundation for developing and reviewing applications. It reduces ambiguity about which language behavior a project expects.
But version 1 does not mean that every security idea discussed around the ecosystem is already enforced.
A separate Argent change documented what Michael Sutton called a “subtle security argument” involving leader and delegate input groups. The change added two further rules, numbered five and six, to the security documentation. Sutton explicitly noted that those additional rules were not yet implemented.
The documentation change and Silverscript synchronization were subsequently merged. A developer also volunteered to take on the missing implementation work, but the archive contains no confirmation that this implementation was completed during the week.
That distinction is essential: the risk model has been written down, but writing down a safety rule is not the same as making software enforce it.
Argent also gained a smaller runtime improvement. Its args! macro, a developer shortcut for assembling arguments, can now accept a state vector. The addition was merged on September 8, and developers discussed broadening it to accept other iterable collections in the future.
For developers: The security update arrived through Argent pull request 60, which also synchronized the latest Silverscript release candidate work with v1.0.0. The archive identifies the unimplemented items as rules five and six concerning leader-delegate input groups, but does not provide enough detail to characterize their exact enforcement logic.
The takeaway is encouraging but precise. Silverscript now has a v1 release, Argent has caught up, and a security requirement is visible rather than hidden. The next meaningful milestone will be implementation and testing of the missing rules.
What else moved forward
Wallet pagination exposed a consistency trap
Wallets and explorers need a practical way to ask a node, “What spendable funds belong to this address?” A proposed pagination interface aims to answer that question without returning an enormous result all at once, but its current design may mix data from different moments.
A UTXO, or unspent transaction output, is a piece of received value that has not yet been spent. Wallets add these outputs together to determine available funds, while explorers use them to display address activity.
Pagination divides a large response into pages. It is similar to loading search results 50 at a time instead of downloading every result immediately.
The problem is that Kaspa continues changing while those pages are being fetched. Maxim Biryukov argued that the cursor used to request the next page must preserve a complete and consistent picture across calls. Under the proposal being reviewed, earlier addresses could contain older information while later addresses contain newer information.
He illustrated the concern with two addresses. One could reflect the network at DAA score 5, while another reflects it at score 31. A DAA score is a marker of the network’s ordering progress. A consumer seeing the later score might reasonably assume the whole response is current to that point, even though it is not.
IzioDev described this as a known trade-off accepted in favor of flexibility, while remaining open to revisiting it if concrete consumer harm could be identified. Biryukov did not call it necessarily harmful, but argued that the interface could lead applications to make an incorrect assumption about freshness. The disagreement is about semantics, not whether pagination itself is useful.
Two possible designs emerged. One would retrieve data for a single address from a specified point, which both participants saw as a natural fit for regular wallets. The other would organize results around network progress and use addresses mainly as filters, which could better serve indexers, explorers, or peer-to-peer UTXO synchronization.
Explorer developer supertypo added two practical requests: a cheap way to count an address’s UTXOs and a way for users to page through them as they already can with transactions. IzioDev said the storage design does not block such an endpoint, although an efficient count-by-prefix operation might need to be added.
For developers: The disputed RPC, or remote procedure call interface, concerns how external software queries a node. The proposed alternatives organize storage either as address plus DAA score plus outpoint, or DAA score plus address plus outpoint. An outpoint identifies a particular transaction output. Reviewers also discussed making the cursor an optional transaction outpoint because its component fields should appear together or not at all.
Pull request 991 was not ready to merge by the end of the archive. Review comments remained, and at least one reviewer considered the API conceptually wrong in its current form. The useful result this week was clarification: wallet queries and bulk indexer synchronization may require different guarantees rather than one flexible interface pretending to serve both equally well.
A post-quantum experiment traded less computation for more state
An experimental replacement for one cryptographic component made block validation about 4 percent cheaper on a DAGKnight development network. That is a measured result, not a deployment decision.
The research concerns an accumulator, a compact cryptographic summary used to compare a large set of records. If two nodes calculate the same summary from the same UTXO state, matching results provide evidence that their sets agree.
Aglovale ran an LtHash “shadow accumulator” alongside the existing system and compared its results across nodes. The chosen parameters produced a 2,048-byte state. In the reported test, validation was approximately 4 percent cheaper than with MuHash, but each chain block needed an additional 1,664 bytes of state.
The unresolved question is whether the selected parameters provide enough long-term protection against quantum-capable attackers. Aglovale estimated the current binding security near 2^128 and asked whether targeting roughly 2^256 would justify a larger state and more computation.
The experiment also prompted an immediate correction. After Maxim Biryukov suggested Blake2Xb, Aglovale acknowledged that an earlier comparison had used a hand-built Blake2b construction instead. Blake2Xb may be cheaper than the proposed cSHAKE256 alternative while removing the current seed-security cap. A proper comparison is planned next.
This work remains exploratory. The benchmark is promising, but the parameters, cryptographic construction, storage cost, and desired security level are all still open.
DAGKnight code landed, while one contribution continued
Two contributions to the DAGKnight development branch were confirmed merged this week: pull request 1123 and pull request 1125. Another pull request, 1127, was posted with the note “to be continued.”
The archive does not describe what these changes implement, so no stronger conclusion about their protocol effect is justified. The visible result is continued code integration, not evidence that DAGKnight itself is finished or ready for release.
Review also touched code readability. One contributor agreed to remove comments that repeated pull-request context inside the code, recognizing that such notes could become a burden for future readers. That is modest maintenance work, but it supports a larger goal: protocol code must remain understandable enough to audit.
Requiring the newest Rust compiler met resistance
A proposal to raise Kaspa’s minimum supported Rust version passed its automated pipeline, but maintainers questioned the reason for making the newest compiler mandatory.
The minimum supported Rust version, or MSRV, is the oldest compiler developers may use to build the project. Raising it can simplify tooling, but it also forces every person compiling the software to update.
The proposal’s author cited problems involving Rust Analyzer and Clippy warnings in ecosystem projects. Reviewers responded that Clippy checks the current crate or workspace rather than its dependencies, leaving the reported benefit unclear. Michael Sutton argued that projects usually lag somewhat behind the latest compiler to avoid forcing immediate updates on every builder.
No merge was reported. The discussion remained open, with the proposal technically passing but its justification still under examination.
What is decided, and what is not
Completed or confirmed
- Silverscript v1.0.0 was released.
- Argent was synchronized with Silverscript v1.
- Argent’s state-vector argument support was merged.
- Argent’s expanded security documentation was merged.
- Rusty Kaspa pull requests 1123 and 1125 were reported merged for DAGKnight development.
- The LtHash experiment produced matching cross-node digests and an early performance measurement on a development network.
Proposed, disputed, or unfinished
- Argent’s newly documented security rules five and six were not yet implemented.
- UTXO pagination pull request 991 remained under review, with its RPC semantics disputed.
- The best division between wallet-oriented and indexer-oriented UTXO interfaces was not decided.
- LtHash’s parameters and long-term post-quantum security target remained open.
- A proper Blake2Xb benchmark had not yet been run.
- The Rust MSRV increase had passed its pipeline but was not confirmed as merged.
- Optional direct ECDSA authentication schemes were suggested as an opt-in reserved group, but the archive records only a proposal, not a decision.
What happens next
- Watch for implementation of Argent’s two newly documented security rules.
- Look for a revised UTXO pagination design that states exactly how freshness and consistency work across pages.
- Expect more input from wallet, explorer, and indexer builders about whether they need separate query interfaces.
- Watch for the promised Blake2Xb benchmark and a clearer recommendation on post-quantum security parameters.
- Look for decisions on the open Rust compiler bump and the still-continuing DAGKnight contribution.
This week delivered a real release, but its larger lesson was about boundaries. Silverscript v1 establishes a foundation; it does not erase unfinished security work. The same honesty shaped the week’s other debates: a fast prototype still needs cryptographic review, and a flexible data API still needs guarantees users can safely understand.