Welcome to Kaspa R&D Weekly for 19 to 25 October 2026. Most of the action this week was in a review thread for a new covenant lookup tool, which lets apps find coins tied to a specific covenant ID. A proposed wallet convention for a post-quantum-friendly address style also took shape, and several tools shipped.
The practical stakes: the lookup could make it easier for builders to find their app's coins, but a node that answers cheap-looking requests with expensive database work is easier to overload. The wallet convention is about how wallets might keep public keys hidden until a coin is spent. Both are still in review, not finished.
The week in one minute
- Covenant lookup: The new index and RPC call (a request apps send to a node) were marked ready for review. A reviewer then raised a possible overload risk, and that question is unresolved. Source
- Wallet convention (KIP-22): Ori drafted a proposal for a standard address style that hides public keys until spending. It was moved into the wallet-convention track, and a wallet prototype is under way. Source
- Releases: Rusty Kaspa v2.1.0 and Silverscript v1.0.1 are on crates.io, with a quick Windows fix. Source
- Argent compiler: A large internal rewrite was merged, and app builders were asked to rebuild and check their outputs. Source
The big story: a covenant lookup is ready for review, but one request could cost a node far more than it looks
The covenant ID lookup is built and marked ready for review, but it is not merged, and a reviewer says its safety limits may not protect nodes. Maxim Biryukov flagged the work ready for review on 21 October.
The problem it solves
Imagine a library where books carry a tag for the project they belong to. Without a catalogue, finding every book for one project means walking the shelves. The covenant index is the catalogue. Apps can ask a node for the unspent coins tagged with a given covenant ID, instead of searching everything.
Developers also explained how the answers come back in pages. The node returns a "cursor", a bookmark saying where the last page stopped, and the app passes it back to continue. The index holds only unspent coins, but a request can be limited to a range of DAA scores (a chain-position counter the developers used as a time-like marker). That lets apps page through history cheaply. (source)
First debate: should this call behave like the address lookup?
Early in the review, Ds and Maxim spent many messages on whether requests should be sorted and how the cursor should work. Ds wanted this call to match the existing address-based lookup (getUtxosByAddressesV2), so clients would not need two usage habits.
The disagreement mostly dissolved once IzioDev explained that the address call had been changed. Callers now send the same list each time and only swap in the new cursor. (source) Ds had been working from older comments in the code. After checking, he said the remaining difference is only in response ordering, which is less problematic, though he still prefers the two calls not to differ.
For developers: Maxim prefers sorted, de-duplicated requests so a cursor implies that everything before it is covered. He also argued that lexicographic order helps the database cache. Ds said the gain is unproven, noting that no benefit was observed on the address-call dataset. (source) Maxim offered to replace sorting with a check that input is already sorted. (source)
The bigger question: can a small request cause a lot of work?
Ds raised a possible denial-of-service risk. The call limits how many results it returns, but not how much database searching it does to find them. (source)
The call accepts up to 5,000 covenant IDs and 5,000 script public keys (SPKs), an optional list the lookup uses to narrow its search. Ds calculated that this could mean about 2.5 million database "seeks", where a seek is a jump to a specific spot in the database. A request returning few results could still cost a node a great deal of work.
He later added that one covenant ID, one SPK and a wide DAA range might be enough, because there is a seek for each DAA score. He said the analysis is not complete.
The reviewers split on how much this matters, and the messages show trade-offs, not a winner:
- Maxim doubted that 5,000 covenant IDs would each share the same 5,000 SPKs, calling it more likely "5000+5000 instead of multiplication". (source) He said that limiting by seeks is not hard and still works with the cursor. The downsides he named are a worse user experience and confusing cases where the limit is hit with no results. (source)
- Ds said security should come first. He suggested limiting by database operations and splitting the call into two: one with SPK narrowing and one without. (source)
- IzioDev argued that limits alone cannot stop determined spam, so the real protection sits higher up, for example at a load balancer. (source) He suggested lowering the covenant ID limit, since he expects most requests to use one ID. (source)
- Maxim also mentioned other mitigations: disabling the index, authorizing RPC clients, or supporting only some covenant IDs. Ds said he might accept guarding the whole call behind an "unsafe RPC" flag, though he is unsure about accidental triggering. (source)
Ds was explicit that he would not block the current version on his own. If others do not see a real problem, the code can stay as is. He also said his review focused on the index internals, while the wiring looked fine.
A different question: should this live in the node at all?
Guy Fawkes asked whether this indexing belongs in the node. He noted that other networks treat indexing as a separate service and suggested that historical queries could live in an opt-in service with its own limits. (source) Ds replied that the index covers only unspent coins, and DAA ranges give paging "for free". Nobody settled the question in the thread.
Status: Under review, not merged. IzioDev said he would add browser/JavaScript (WASM) support on top of the same pull request. (source) Whether to add a database-work limit, split the call, or keep it as is remains open.
What else moved forward
A wallet address style that hides public keys: KIP-22 gets a draft and a prototype
Ori wrote KIP-22, a proposal for a standard wallet convention, and a prototype wallet implementation has begun. It sits in the post-quantum discussion thread. (source)
IzioDev summarized the idea as an agreed P2SH program (a standard locking script) that effectively behaves like a P2PKH payment. (source) The post-quantum link made in the thread is that public keys should not be exposed before a coin is spent.
Because it is a wallet convention and not a change to how nodes work, IzioDev suggested it be filed as a KCC (a Kaspa community convention) instead of a KIP. Ori agreed and moved it. Ori also added BitcoinsSG as an author, since coderofstuff and Maxim noted the idea was similar to earlier work. (source)
Why a separate "purpose" number? Wallet addresses are generated from a path with numbered levels, and the first level is called the "purpose". Coderofstuff asked why this proposal uses its own purpose (22') when BIP44 uses a constant 44, and he said the choice has consequences for wallets. (source)
Ori answered that sharing keys across wallet types is bad practice. Without a separate purpose, a P2PK wallet might expose the public keys of the P2PKH wallet. (source) Aglovale added that any extended public key already shared for a 44' account would expose the keys under it. Ori confirmed this. (source) IzioDev noted that Rusty Kaspa already uses 45 for multisig wallets. (source)
Gaurav, whose earlier idea the proposal resembles, said his approach keeps key derivation on the wallet side, so wallet makers can adopt stronger post-quantum schemes without touching the chain or transaction mass. He believes derivation on the wallet side plus never reusing addresses gives "good enough security", and that Kaspa's fast confirmations cover the short window during spending. That is his view, not a team position. (source)
For developers: IzioDev is prototyping this in the wallet SDK and CLI. His preferred route is to extend the existing BIP32 account type with a stored scheme field (P2PK or P2PKH), which needs a small storage backward-compatibility step, instead of adding two new account types. Either way, accounts would be kept apart so a P2PK account cannot make P2PKH payments by mistake. (source)
Takeaway: This is a draft and an early prototype. The details, including the purpose number, are still being discussed, and the archive shows no approval.
Rusty Kaspa and Silverscript are now easy to use as Rust libraries
Rusty Kaspa v2.1.0 and Silverscript v1.0.1 are published on crates.io, so Rust developers can add them as ordinary dependencies. Examples include kaspad, kaspa-consensus-core, silverscript-abi and silverscript-lang. (source)
Windows MSVC users hit a problem: the 2.1.0 package of kaspa-hashes lacked an assembly file. Michael Sutton published v2.1.1 with only the packaging fix. Existing projects can pin it with cargo update -p kaspa-hashes --precise 2.1.1, while new projects pick it up automatically. (source)
Status: Published and fixed.
Argent's compiler rewrite lands, and app builders are asked to check their outputs
A major compiler refactor for Argent was merged. The author is IzioDev, and Michael Sutton called it a significant step toward audits and a first release. (source)
The compiler now carries structured representations of the code through each stage, instead of repeatedly rewriting source text. The stated benefit is that it is easier to reason about and audit.
Builders with working Argent apps are asked to rebuild against the latest master and confirm that transaction flows still work. The compiled artifacts should be byte-for-byte unchanged, including script bytecode, template hashes and artifact IDs. Any difference is worth reporting. Manifest files are expected to change structurally.
The generated .sil source files will look different, because they now come from Sil's AST printer, and the generated comments are currently gone. Michael said useful comments may be restored later.
Status: Merged, with a request for community regression checks.
What is decided, and what is not
Done or confirmed
- Rusty Kaspa v2.1.0 and Silverscript v1.0.1 are on crates.io.
- kaspa-hashes v2.1.1 fixes the missing Windows file.
- Argent's compiler refactor is merged.
- The KIP-22 idea was moved to a KCC pull request with BitcoinsSG as co-author.
- The covenant ID lookup was marked ready for review.
Proposals and active design work
- The KIP-22 wallet convention and its prototype in the wallet SDK and CLI.
- Limiting the covenant lookup by database work, and possibly splitting it into two calls.
- Gating the call behind an unsafe RPC flag, offered as one possible mitigation.
- A separate opt-in indexing service instead of one inside the node (Guy Fawkes's suggestion).
Open questions
- Is the covenant lookup's overload risk real enough to change the limits? Opinions differ.
- Should the two lookup calls be made to behave identically?
- Is the 22' purpose number settled? The archive shows only discussion.
- Will KIP-22 gain broader agreement? No approval appears in the archive.
What happens next
- IzioDev said he will add WASM support to the covenant lookup pull request. (source)
- IzioDev said he is building a proof of concept of the KIP-22 convention in the wallet and welcomes feedback. (source)
- IzioDev said he would open a pull request to fix outdated comments on the lookup's cursor documentation. (source)
- Argent app builders are asked to rebuild and report any change in compiled artifacts. (source)
- Windows MSVC users with Rusty Kaspa dependencies should run the cargo update command. (source)
- Ds suggested analyzing the maximum number of seeks and writing a benchmark. Nobody committed to doing it in the thread. (source)
Closing
This week showed two sides of building: shipping tools, and checking whether they hold up under pressure. The covenant lookup works well enough for review, but the review asked whether one small-looking request could cost a node too much. The next edition should show whether the database-work limit, a split call, or the current design wins out, and how far KIP-22 gets as a wallet convention.