Kaspa R&D this week focused on making complex applications safer to build, easier to discuss, and potentially more compatible with existing wallets. Between August 30 and September 6, Argent received merged security work and a dedicated development channel, a DAGKnight pull request cleared testing and merged, and developers debated support for an additional ECDSA ownership scheme.
The common thread is the gap between making something work and making it safe, economical, and practical for others to use. Argent moved forward, but its transaction-building tools and some language features remain incomplete. Wallet support may broaden, but only if the extra script cost proves worthwhile.
The week in one minute
- Argent merged a security framework for multi-contract applications. It addresses identity rules that are difficult to enforce correctly by hand, although the archive does not provide enough detail to assess every protection.
- Argent now has its own R&D discussion stream. That reflects a clearer identity for the language and its intended audience, separate from SilverScript.
- Several Argent changes were merged, but the toolchain is not complete. Runtime transaction building and some range features are still behind.
- A DAGKnight pull request passed linked automated checks and merged. The archive confirms the merge, but does not describe the code well enough to claim a specific network effect.
- Developers debated direct ECDSA public-key support. It could help applications work with ECDSA-based wallets while exposing the owner more directly, but its script-size cost still needs measurement.
The big story: Argent added guardrails for apps made from several contracts
A single-program application is already hard to secure. An application made from several programs is harder because each part must interact with the right counterpart under the right rules.
Think of a delivery system in which several people handle the same parcel. Checking that every handoff goes to the intended person is as important as checking the parcel itself. In a multi-contract blockchain application, developers face a comparable identity problem: separate pieces must agree about which program or template they are dealing with.
This week, Michael Sutton opened and then merged Argent pull request 55, accompanied by documentation for what the project calls “template frame identity” security invariants. An invariant is a rule that must remain true throughout an operation. Sutton described this as the kind of protection a multi-contract compiler would include, and as a reminder that multi-contract applications are difficult to implement safely by hand.
Argent is an actor-based language and compiler for stateful applications built from multiple contracts. “Actor-based” means the design treats parts of an application as separate participants that communicate and update state. A compiler translates the language developers write into instructions the underlying system can execute.
These applications run on covenant-enabled UTXO foundations. A UTXO, or unspent transaction output, is a discrete piece of value that can be consumed in a later transaction. A covenant adds rules limiting how that value may be spent in the future. Together, they can support applications whose state advances through a chain of controlled transactions.
The practical promise is safer composition. If the compiler can enforce important identity relationships, builders may avoid subtle mistakes when several contracts cooperate. Users would not see a “template frame” button in a wallet, but they could eventually benefit from applications that are harder to connect incorrectly.
The status is concrete but limited: the pull request was reported merged on September 2. That confirms the work entered the Argent project. It does not establish that Argent is production-ready, that every multi-contract risk is covered, or that the protections have been proven in deployed applications.
The documentation was considered clear by one developer already familiar with Argent, who also warned that newcomers may struggle with its vocabulary. That matters because security rules only help human reviewers if they can understand what those rules guarantee.
For developers: The archive identifies the work as template-frame identity semantics and security invariants, but does not expose enough of the pull request’s contents to summarize its exact checks responsibly. The strongest supported conclusion is that the merged work formalizes identity requirements intended for compiler-managed multi-contract applications.
The takeaway is straightforward: Argent now contains more machinery for protecting complex contract relationships, but a merged framework is the start of validation, not the end. The next proof will come from applications that use these rules successfully.
What else moved forward
Argent gained its own home because it is becoming a distinct tool
Argent received a dedicated forum topic after developers concluded that it was mature enough to discuss separately and likely aimed at a different audience from SilverScript.
That administrative change carries a useful technical signal. Argent is no longer being treated merely as a side conversation inside another language project. Its new topic was introduced with links to the compiler repository, a playground, a starter template, and an introductory video, giving prospective builders a clearer route into the project.
Two earlier pieces of Argent work also reached confirmed merge status. Sutton reported pull request 44 merged after minor fixes, followed by the merge of pull request 54. The archive does not describe their contents, so their practical effects cannot be stated reliably.
The limitations were clearer. Sutton said runtime transaction building was behind, while “observed ranges” and virtual extensions on ranges were not yet supported. In plain English, some conveniences for constructing transactions while an application runs, and some ways of working with groups of values, remain unfinished.
That contrast defines Argent’s current position. The project has working components, merged security semantics, documentation, and onboarding resources. It also has explicit feature gaps. Its separate home makes progress easier to follow, but does not turn the language into a finished product.
DAGKnight code merged, although its effect is not documented here
A DAGKnight-related pull request entered the main rusty-kaspa repository, was accompanied by links to automated runs, and was reported merged on September 4.
DAGKnight is the named development area attached to the discussion. The archive provides the pull request and continuous-integration links, but no explanation of what changed inside the code. Continuous integration, or CI, automatically builds and checks proposed changes before they are accepted.
The sequence supports a narrow, firm conclusion: code was proposed, automated jobs were linked, and the change merged. It does not support claims about performance, activation, network behavior, or release timing.
That distinction matters for readers watching protocol development. A repository merge is real progress, but users do not necessarily experience it immediately. The next meaningful evidence would be a description of the behavior changed, further testing, or inclusion in a release.
ECDSA wallet support exposed a cost-versus-compatibility choice
Developers considered adding a direct ECDSA public-key ownership option to covenant-related standards. ECDSA is a digital signature system that wallets can use to prove control of funds. The immediate motivation was compatibility with Tangem-based use in an application under development, according to the proposer.
Existing ECDSA-P2PKH support may already provide one route. P2PKH, short for “pay to public-key hash,” identifies an owner through a shortened fingerprint of a public key. The proposer wanted a form in which the ownership information was visible more directly instead of being hidden behind that hash.
The discussion did not reveal a technical blocker. Sutton described the concept as potentially “win-win” if the scheme-identifying byte changes while the owner field stays at 32 bytes. However, IzioDev questioned whether there was enough demand to justify adding another scheme because covenant creators who support it may have to carry larger scripts.
That is the real trade-off. More ownership formats can make applications compatible with more wallet arrangements, but every supported path can add code and cost. A harmless-looking option at the standard level may become permanent weight inside applications.
For developers: The proposal concerns P2PK-ECDSA alongside existing ECDSA-P2PKH support. P2PK means “pay to public key,” where the public key itself identifies the owner. Sutton suggested measuring the added script cost and possibly consolidating the new route under the existing checkEcdsa path. A separate proposal to remove the hash key from P2PKH was also flagged for consideration.
No approval was recorded. The practical next step is measurement: quantify the extra script size, then decide whether more direct owner visibility and wallet compatibility justify it.
A SilverScript release adjustment was suggested, not confirmed
SilverScript also had a smaller release-related discussion. Sutton recommended including a minimal Cargo configuration change from an existing issue in the release. Cargo is the standard build and package tool used by Rust projects.
The archive records this as a suggestion, not a merge or release announcement. No final decision appears in the supplied messages.
Its importance is therefore modest but clear: developers identified a packaging or build configuration adjustment worth considering before release. Readers should wait for a confirmed merge or release note before treating it as shipped.
What is decided, and what is not
Completed or confirmed
- Argent received its own R&D topic, with repositories and onboarding resources collected in one place.
- Argent pull requests 44 and 54 were reported merged.
- Argent pull request 55, covering template-frame identity security semantics, was reported merged.
- The referenced DAGKnight pull request was reported merged after automated job links were shared.
Proposed or still under discussion
- Direct P2PK-ECDSA support remains a proposal.
- Its extra script cost still needs to be measured.
- A related change to P2PKH ownership representation was raised but not resolved.
- Adding the Cargo configuration adjustment to a SilverScript release was suggested, not confirmed.
Known unfinished areas
- Argent’s runtime transaction-building support is behind.
- Observed ranges are not supported.
- Virtual extensions on ranges are not supported.
- The archive does not establish when these gaps will close or when Argent will be ready for production use.
What happens next
- Evidence from Argent applications: Watch for builders to use the merged identity invariants in real multi-contract designs.
- Progress on transaction tooling: Runtime transaction construction remains one of Argent’s clearest stated gaps.
- A script-size measurement for ECDSA: That number could decide whether the compatibility benefit is worth supporting broadly.
- Details on the merged DAGKnight work: A technical summary, follow-up test, or release inclusion would clarify its practical consequence.
- Release confirmation for SilverScript: The proposed Cargo configuration change still needs a recorded decision.
This week delivered real merges, especially around Argent’s approach to safer multi-contract applications. It also made the unfinished work easier to see. That is useful progress in itself: the safeguards are becoming concrete, while the remaining tooling, cost, and deployment questions are now harder to mistake for solved problems.