Kaspa covenant fields became usable across more of Rusty Kaspa’s software stack when PR #835 merged on January 23, 2026. The change carried covenant data through transaction outputs, UTXO entries, PSKT, RPC models, gRPC, WASM, and JavaScript bindings. It improved interface consistency, but did not complete covenant wallet support or activate the feature on mainnet.

Key takeaways

• PR #835 merged 15 commits affecting 26 files in Rusty Kaspa’s experimental covpp-reset1 branch.
• The main field was covenant_id, carried through transaction outputs and UTXO representations instead of stopping inside consensus code.
• PSKT gained covenant support and version-compatibility checks, while RPC, gRPC, WASM, and JavaScript models exposed matching data.
• The pull request explicitly left arbitrary-script wallet accounts, covenant send and receive flows, and covenant-genesis transaction generation for later work.
• A development-branch merge is evidence of engineering progress, not proof of mainnet activation, application security, adoption, or price impact.

What did Rusty Kaspa PR #835 merge?

The official Rusty Kaspa PR #835 is titled “Add Covenant Related fields in Transactions, UTXOs, PSKT, RPC, and JS Bindings; Resolve Related TODOs.” GitHub records 376 additions, 101 deletions, 15 commits, and 26 changed files. Maintainer Michael Sutton merged it into covpp-reset1 on January 23, 2026 after the public checks passed.

The scope matters more than the raw line count. Earlier Covenant++ work had introduced consensus concepts such as covenant IDs and output authorization. PR #835 connected those concepts to the representations that applications and tooling actually use. It also removed an unfinished todo!() path when parsing a covenant ID from a UTXO entry.

For the preceding consensus work, see Kaspa Covenant IDs and Sequencing Commitments: The January 2026 Merge.

Why must covenant data cross every software layer?

A UTXO feature cannot be practical if only the validation engine understands it. A transaction builder must create the field, and serialization must preserve it. A node must expose it through RPC. A partially signed transaction must retain it between participants, and a browser or wallet must read the same value without silently dropping it.

That is the integration problem addressed here. A missing field at any boundary can produce an invalid transaction, an incomplete signing package, or a misleading application view. Consistent models are especially important for covenant outputs because the identifier connects an output to rules governing how its value may continue through later transactions.

This does not make every client covenant-aware. It supplies lower-level representations and conversions that client developers can build on.

What changed in transactions and UTXOs?

PR #835 added covenant handling to TransactionOutput and a JavaScript conversion path for that output. It extended batch UTXO-reference generation and implemented a conversion from the high-level transaction output into the consensus output representation.

On the UTXO side, the code began parsing covenant_id instead of reaching a placeholder, added the identifier to UtxoEntryWrapper, and included it in JavaScript serialization. It also fixed serialization and deserialization for optional outputs and entries, and covered the preallocation build feature.

These are transport and model changes. The field identifies covenant context; it is not a complete token standard, an account system, or a smart-contract runtime by itself. Script and consensus rules still determine whether a spend is valid.

How did PSKT, RPC, and JavaScript support change?

PSKT – Kaspa’s partially signed transaction format and toolkit – gained covenant data plus version checks intended to prevent incompatible covenant-enabled structures from being mixed. That is important when multiple tools create, inspect, and sign one transaction without sharing private keys.

RPC models, their gRPC equivalents, and converters received covenant bindings so node clients could observe the same information. The JavaScript-facing PaymentOutput gained covenant support, CovenantBinding received a TryCastFromJs implementation, and a redundant payment-output constructor was removed.

The companion SilverScript initial SDK overview explains how higher-level tooling began assembling state-aware covenant scripts on top of these lower-level fields.

What did the pull request explicitly leave unfinished?

The PR description is unusually clear about its boundary. It says the wallet framework still needed support for arbitrary or custom scripts rather than only its existing account patterns. It also lists custom-script account creation, dynamic registration of account types, covenant-specific send and receive operations, and a way to select the final covenant on an output.

The transaction generator also needed the ability to issue covenant genesis transactions and a more extensible way to register covenant implementations. Those tasks were deferred to avoid expanding one integration pull request indefinitely.

This means developers should not translate “fields are exposed” into “a complete retail wallet flow exists.” Data plumbing is necessary infrastructure, but usability, recovery, signing policy, audits, and application logic remain separate workstreams.

What were the activation and compatibility limits?

PR #835 targeted covpp-reset1, not Rusty Kaspa’s stable release branch. Its own description emphasizes backward compatibility and version enforcement where applicable, yet the wider Covenant++ feature set was still experimental and subject to follow-up changes.

Before production use, developers would need a finalized specification, consensus activation rules, compatible node software, stable APIs, test vectors, resource limits, wallet support, and independent security review. RPC availability alone cannot establish that a consensus feature is active on a particular network.

The safest status check is therefore layered: inspect the target branch, release notes, activation parameters, and current network documentation rather than relying on a single merged PR title.

What does this mean for Kaspa’s roadmap and price?

Cross-layer field support reduces friction for future wallet and application development. It is a concrete prerequisite for covenant tooling because developers can move the same data from consensus models to signing workflows and browser interfaces.

It is not a KAS price signal on its own. A branch merge does not measure user demand, secure application launches, fee revenue, liquidity, or operator adoption. Market analysis should separate auditable implementation progress from assumptions about when or whether that progress becomes widely used.

Frequently asked questions

Is PSKT the same as a wallet?

No. PSKT provides structures and workflows for partially signed transactions. A wallet still needs account management, address handling, transaction construction, policy, signing, recovery, and user-interface logic.

Did PR #835 make covenants available on Kaspa mainnet?

No. The source proves a merge into the experimental covpp-reset1 branch. Mainnet availability would require a release and coordinated consensus activation documented separately.

Does exposing a covenant ID through RPC enforce the covenant?

No. RPC exposes data to clients. Consensus and script validation enforce spending rules, while applications must interpret the exposed fields correctly.

Source and verification note

This article is based on merged kaspanet/rusty-kaspa PR #835, including its description, commit list, target branch, changed-file record, review, and merge status. Counts and field names were checked against GitHub’s public pull-request data. The source documents integration work and explicit future tasks; it does not document mainnet activation, a complete wallet, an independent audit, or any KAS price outcome.