This week in Kaspa R&D (November 2 to 8, 2026) was about one practical problem: how can an app or wallet work out the history behind a "covenant" coin without trusting an outside website? In the chat, covenant coins carry extra state and rules, such as the live state of a liquidity pool. Developers merged a new node feature that answers part of that question.
The feature is a new RPC method (a request that apps send to a node) that fetches a transaction by the block that accepted it. Around it, the chat covered smaller items: browser and JavaScript support for a covenant-ID index, an idea for notifications by covenant ID, and a proposal for parent-child covenant links.
The headline's promise comes with a limit. The lookup works only while the node still keeps the transaction, so it helps with recent history and does not give permanent proof.
The week in one minute
- Merged: a node method that returns a transaction when you give it the accepting block's hash or DAA score (a number that marks a block's position). It includes browser (wasm) support and a JavaScript example. Source
- Main use: finding the transaction that created a covenant coin, without relying on third-party services, as long as the transaction hasn't been pruned. Source
- Proposed, not built: notifications for coin changes by covenant ID, and a native "parent covenant" link. Both are suggestions from individuals. Source, source
- Also moving: wasm support for the covenant-ID index was pushed, tested on mainnet and approved, but still needs a rebase onto master. Source
The big story: Finding where a covenant coin came from, without asking a third party
Developers merged a way to ask a node for the transaction behind a coin, and it works today for any transaction the node still remembers. The method was merged into master (commit 4863866) through rusty-kaspa PR 1164. IzioDev credited @missutton for the work, and @BitCat1234 for the use case. Source
The problem: a coin with no visible past
Think of finding a package on a shelf with no label. To use it safely, you need to know where it came from and what it contains.
A covenant coin is similar. To understand its current state, an app may need the transaction that created or last changed it. Until now, that usually meant asking an outside indexing service, and you had to trust whatever it told you.
The fix: look up by accepting block
The new method returns a transaction when you give it the hash or DAA score of the block that accepted it. The workflow IzioDev described has two steps:
- Take the DAA score from the coin you are investigating.
- Call the endpoint and read the transaction data it returns. Source
Michael Sutton stressed that the result is a fully populated transaction. It includes the input UTXO entries (the coins being spent) with their locking scripts. Source
That is everything a client needs to run the transaction's scripts itself and extract information, such as the state stored in covenant outputs. In plain terms, an app can check the story itself instead of trusting a middleman.
Sutton also described two ways to use it. A client can track coin changes for one address, or query the UTXO or covenant index once per pruning period and collect all the transaction data it needs. Source
For developers: the method comes with wasm support and a JS example. IzioDev noted it can be useful beyond covenants, but covenant-origin lookup was the main goal. Source
The catch: pruning
The data does not last forever. Nodes keep a transaction only for the pruning period, and they keep it even if the coin is spent later. Source
Manyfest had assumed a node would keep a transaction as long as one of its outputs stayed unspent. On that assumption, a covenant deployer could add a small extra output to the genesis transaction so nodes would keep it as proof. Manyfest dropped the idea after Sutton's correction. Source, source
Bit Cat described the new method as a kind of on-chain cache of the most active covenant scripts, such as liquidity pools. That is one participant's framing. Source
Status: the RPC method is merged in master. The archive does not mention a release. It also does not describe any mechanism for proving a covenant's origin once the transaction has been pruned.
What else moved forward
Notifications by covenant ID: a gap spotted while writing the explanation
A node could one day push updates for every coin tied to a given covenant ID, instead of making apps poll for them. While explaining the new RPC, Sutton noticed that UTXO notifications by covenant ID should be supported. Source
That would let a wallet or app follow one contract's coins directly. The archive records only the observation, with one 👍 reaction. It names no design, owner or timeline, so treat it as an idea.
Browser-ready covenant-ID index: tested on mainnet, waiting on a rebase
Wasm support and a JS example for the covenant-ID index were pushed and checked against a real mainnet node. IzioDev reported that it works as expected and marked it approved. One step remains: the branch needs a rebase onto master. Source
Wasm support matters because it lets web and JavaScript tools use node features directly. The message does not say when the change will be merged.
Parent-child covenants: could clients explore one pool's subcontracts?
Bit Cat asked whether covenants should carry a native parent_covenant_id for when one covenant creates a child with a fresh ID. The field would persist across updates. Source
Nodes could then index parent to children. A client could explore one pool's live subcontracts and their children without scanning the whole app or reconstructing the creation history.
For developers: this is a question about a possible future protocol and index feature. Nobody replied in the archive, so there is no design, estimate or agreement.
What is decided, and what is not
Done or confirmed
- The RPC method for fetching a transaction by accepting block (hash or DAA score) is merged in master, with wasm support and a JS example. Source
- It returns a fully populated transaction, including input UTXO entries with their scripts. Source
- Transactions are available only for the pruning period, even if the coin is spent later. Source
- Wasm support for the covenant-ID index was tested on mainnet and approved. It needs a master rebase. Source
Proposals and open questions
- UTXO notifications by covenant ID: noticed as a gap, not built. Source
- A native
parent_covenant_id: asked about, not discussed further. Source - How a deployer could preserve genesis proof beyond the pruning window: not answered. Manyfest's workaround rested on a wrong assumption. Source
What happens next
The only concrete next step in the archive is the master rebase for the covenant-ID index wasm work. Source Nobody scheduled notifications by covenant ID or the parent-covenant idea. Those questions remain open.
Closing
The week started with a practical question: can an app learn where a covenant coin came from without trusting a third party? The answer is yes for recent history, and the feature is already merged. It does not yet cover older history, since pruning still removes the evidence. Next edition, watch whether covenant-ID notifications or the parent-child idea get a design behind them.