A decentralized exchange prototype now runs in Argent, an experimental environment for Kaspa contracts. Its trading logic is deliberately incomplete, yet it answers a more important question: can several contracts and assets interact without forcing builders to wire every low-level connection by hand?
That matters because easier transaction construction could make wallets and applications safer to build. The prototype also exposed what still needs definition, including a common token shape, a standard contract interface, and how applications should represent native KAS.
Those tensions shaped Kaspa Core R&D discussions from July 13 through July 19, 2026. The week produced working code and one merged compiler improvement, but no finished exchange or approved token standard.
The week in one minute
- A decentralized exchange, or DEX, proof of concept demonstrated asset registration, swaps, contract ownership, and reserve migration. Its business rules remain intentionally incomplete, but its cross-contract machinery is described as mature (source).
- A new builder interface can resolve the low-level links among multiple applications automatically. Developers describe transactions in terms closer to their own contract logic (source).
- Drafts for KCC-0001 and KCC20 began defining how contracts communicate and what a fungible token should minimally contain. Both remain proposals seeking review (source).
- SilverScript merged built-in access to the full Blake family of cryptographic hash functions, giving contract authors more native tools (source).
- A DEX builder identified a missing shared-data pattern: contracts cannot currently read a common unspent output without consuming it. Whether Kaspa should add read-only “reference inputs” is unanswered (source).
The big story: The exchange is unfinished, but its transaction builder solves a deeper problem
Imagine booking a trip where choosing a flight forces you to manually connect the airline, payment processor, hotel, and insurance systems. Each service might work, but coordinating them becomes the real engineering challenge.
Multi-contract blockchain applications face a similar problem. A transaction may need to satisfy several independent programs, connect their inputs and outputs correctly, preserve assets, and create the next valid state for every participating contract. One incorrect link can invalidate the entire transaction.
Kaspa’s experimental solution appeared this week inside a DEX proof of concept. A DEX is an application that allows assets to trade through on-chain rules instead of a central operator. Michael Sutton reported implementing pair registration, swaps, covenant ownership, and reserve migration in Argent (source).
A covenant is a rule attached to funds that restricts how those funds may be spent in the future. Kaspa represents spendable funds as UTXOs, or unspent transaction outputs: discrete parcels of value that a later transaction can consume. A covenant can require the spending transaction to recreate a particular structure, prove ownership, conserve token amounts, or interact with another covenant.
The prototype’s exchange calculations are not finished. That limitation is important: it is not a production-ready DEX, nor evidence that its market design is complete.
What appears more mature is the machinery connecting its parts.
Sutton said the builder interface now lets an author describe a transaction according to the application’s own high-level logic. A comprehensive resolution procedure then handles “linkage and low level multi-app resolving and plumbing” automatically (source).
In plain language, the developer states what the transaction should accomplish, while the builder works out how the participating contracts fit together. This is the difference between assembling every wire in a machine and specifying how the machine should behave.
That could reduce two barriers for future applications. First, builders may write less fragile coordination code. Second, reusable contracts could interact through common shapes instead of requiring a custom integration for every pairing.
Why the asset experiment matters
The prototype includes a generic asset abstraction and an asset pegged to KAS. Here, “pegged” means the contract’s recorded asset amount is intended to equal the native KAS held by the same UTXO.
The goal is to let an exchange treat KAS like other assets rather than adding special KAS handling throughout its code. An outside contract could read the common asset amount, while the canonical KAS contract would enforce its equality with the underlying native value (source).
That simplicity comes with unresolved usability and accounting questions. Maxim Biryukov warned that software might accidentally count both the recorded asset amount and the native UTXO value, effectively treating one balance as two. Manyfest also noted that users might need to represent KAS through the token convention rather than simply sending native KAS, potentially making some interactions less convenient (source).
Others argued that wallets could hide this conversion and that it might not require a separate transaction. No shared conclusion was recorded. The discussion ultimately revealed a terminology gap around what “composability,” meaning the ability of independent contracts to work together, should guarantee (source).
The prototype therefore delivered more than an exchange demo. It provided a concrete test case for proposed standards and exposed where their apparently simple abstractions can create real wallet and accounting hazards.
For developers: The proof of concept exercises inter-contract communication patterns across pair registration, swaps, covenant-controlled ownership, and reserve migration. The resolver constructs the required multi-application transaction links from Argent-level descriptions. The DEX’s business logic should not be treated as a completed reference implementation.
What else moved forward
Token standards gained written shapes, not final rules
Kaspa’s proposed fungible-token convention moved from broad discussion into a pull request. The KCC20 proposal defines a minimal token instance around ownership and amount, plus a recognizable transfer structure (source).
The idea is comparable to agreeing on the shape of a plug before deciding what every appliance will do. If applications recognize the same minimal fields and spending pattern, wallets, exchanges, escrows, and other contracts can integrate tokens more generically.
KCC20 does not attempt to settle every token feature. Issuance policies remain open, and projects could extend the minimal state with additional logic. Metadata such as names, links, and decimal settings was explicitly treated as outside the proposal’s required core, although nothing would prevent an implementation from adding it (source).
A separate design offered a three-part structure: transferable balances, a minting-right UTXO, and a metadata UTXO. Its author argued that separating those roles could prevent ordinary transfers from competing over shared supply or metadata state. This was a participant proposal, not an adopted direction (source).
Meanwhile, KCC-0001 was drafted to describe a common contract ABI. An ABI, or application binary interface, is the agreed format that lets separately written programs call and understand one another. Review comments suggested that reading KCC20 alongside this broader interface proposal was helping clarify the design space (source).
The payoff is precision, not finality. Kaspa now has concrete documents that reviewers can challenge, but neither archive discussion establishes an approved standard.
Wallet fixes received confirmation from covenant users
Two users confirmed that a Rusty Kaspa wallet pull request fixed separate covenant-related problems: one involving transaction mass calculation and another involving the compute budget (source).
Transaction mass is a measure used to account for the resources a transaction consumes. Compute budget refers to the permitted cost of executing its logic. Errors in either area can cause a wallet to reject a valid transaction, calculate it incorrectly, or fail to prepare it for relay.
The archive does not establish that this pull request was merged or released. What is confirmed is narrower but useful: two affected users tested the change and reported that it resolved their respective issues.
SilverScript’s hash toolbox reached the codebase
SilverScript merged support for all Blake hash functions as built-ins after the pull request was opened for review earlier in the week (source). A hash function converts data into a fixed-size fingerprint, allowing programs to verify commitments or relationships without embedding the original data.
Making these functions built in means contract authors can invoke them directly through the language instead of recreating supporting machinery. This is completed work at the repository level, although the archive does not mention a packaged release.
A related Argent pull request explored securely launching subordinate applications with new covenant IDs, identifiers that distinguish covenant lineages, without adding new trust assumptions (source). That work was presented as an interesting design topic, not as merged functionality.
Minimum fees stay simple, while priority remains more nuanced
A brief wallet question clarified that storage mass should not determine the minimum relay fee. Storage mass measures the burden a transaction places on the network’s stored UTXO state. It can still affect priority fees, which influence transaction selection, but not the basic minimum (source).
One reason is practical: increasing a fee can itself alter storage mass, creating a circular calculation. Excluding it from the minimum fee makes wallet estimation substantially simpler. The discussion also tied the minimum to regulated block-space protection rather than the fee market (source).
For wallet users, the consequence is fewer opportunities for fee calculation to chase its own tail.
A shared price board revealed a missing read-only primitive
A DEX builder raised a harder architectural question: how can many contracts read the same on-chain price board without each spending it?
Under the described covenant model, introspection, meaning a contract’s ability to inspect transaction details, is scoped to the transaction spending the relevant UTXO. If a price board lives in one UTXO, reading its state requires consuming and recreating it. Two simultaneous readers would then compete to spend the same output, and only one could succeed (source).
The suggested remedy was a reference input, a transaction dependency that can be read without being spent. That could support shared price feeds, liquidation thresholds, or other frequently consulted state. It also raises questions about reorganizations and validity dependencies on outputs that remain unconsumed.
The author explicitly asked whether this belongs on L1, the base Kaspa protocol, or in L2 systems and virtual programs built above it. No answer appears in the archive. The bottleneck is clearly stated; the protocol response remains open.
What is decided, and what is not
Completed or confirmed
- SilverScript’s Blake hash built-ins were merged.
- The Argent DEX proof of concept was implemented with several cross-contract interaction patterns, while its market logic remains incomplete (source).
- A high-level transaction resolver is reported as working across those multi-application interactions (source).
- Two users confirmed that a wallet pull request fixed their covenant transaction issues (source).
- Storage mass was clarified as relevant to priority, not the minimum relay fee (source).
Proposed or still unanswered
- KCC20 and KCC-0001 are drafts under review, not approved standards (source).
- Token issuance and required on-chain metadata remain outside KCC20’s minimal proposal.
- A canonical KAS asset representation has support, but its accounting and wallet behavior remain under discussion.
- Read-only reference inputs have been suggested, with no recorded decision about adding them to the base protocol.
- Securely launching subordinate applications with new covenant IDs is active experimental work, not confirmed merged functionality.
What happens next
- Watch for revisions to KCC20 after its initial review, especially where it must align with the KCC-0001 contract interface (source).
- Look for concrete examples resolving whether a KAS-pegged asset simplifies composition without creating double-counting hazards.
- Follow whether the Argent DEX experiment turns its mature transaction plumbing into reusable patterns beyond the intentionally incomplete exchange logic (source).
- Watch for a protocol response to the reference-input question and whether shared read-heavy state is considered suitable for L1.
- Check whether the user-confirmed covenant wallet fixes progress from successful testing to a merge or release.
The week’s most valuable result was not a finished exchange. It was proof that much of the machinery behind coordinated contract transactions can be hidden from application authors. The next test is harder: turning that convenience into standards whose rules are clear enough that wallets, assets, and independent contracts all interpret the same transaction the same way.