Kaspa covenant RPC serialization was corrected in Rusty Kaspa PR #839 so an output’s covenant binding survived conversion from the RPC model into the consensus transaction model. The same merge extended the Rothschild transaction generator with covenant IDs and version testing. It targeted covpp-reset1, not an activated mainnet release.

Key takeaways

• A one-line RPC conversion fix replaced a constructor that discarded the covenant field with one that preserves an optional binding.
• Rothschild gained opt-in flags for covenant-ID population and transaction-version randomization; both defaulted to false.
• Covenant-aware test transactions use the post-hardfork version, while version randomization can exercise legacy and new parsing paths.
• The generator can start a new covenant lineage or continue an existing ID from a selected input, binding generated outputs to that authorizing input.
• PR #839 merged into the experimental Covenant++ branch, so it was test infrastructure rather than proof of mainnet availability.

What did Rusty Kaspa PR #839 merge?

The official Rusty Kaspa PR #839 records 11 commits, two changed files, 96 additions, and nine deletions. It merged on February 9, 2026 into covpp-reset1 after review and six passing repository checks.

Most additions were in rothschild/src/main.rs, the repository’s transaction-generation utility. The second file, rpc/core/src/convert/tx.rs, received only one changed line, but that line corrected an important information-loss boundary.

The source is therefore best read as integration and testing work. “Rothschild transactions” here refers to transactions produced by that codebase utility, not a new token class, consumer wallet, payment brand, or consensus primitive.

What was wrong with covenant RPC serialization?

Before the fix, converting an RpcTransactionOutput into the core TransactionOutput called a constructor with only value and script public key. Any optional covenant binding carried in the RPC object was left behind.

PR #839 changed the conversion to call TransactionOutput::with_covenant, passing item.covenant.map(Into::into). In plain language, an absent binding remains absent, while a present RPC binding is converted into the consensus-client representation rather than silently dropped.

Serialization boundaries connect nodes to miners, wallets, SDKs, load generators, and indexers. A dropped field makes the in-memory transaction differ from its RPC message, so tests can exercise the wrong object or clients can lose lineage data.

The related Kaspa CPU Miner v0.2.6 guide explains how the mining-side RPC schema gained the corresponding covenant fields for TN12.

How did Rothschild generate covenant-aware transactions?

The merge added --enable-covenant-id and --randomize-tx-version. Both flags defaulted to false, and the covenant-ID flag was hidden in the command-line interface, consistent with experimental use rather than a polished user feature.

When covenant IDs are enabled, the generator selects one input. With a one-percent probability it derives a new genesis ID from that input’s previous outpoint and the transaction’s authorized outputs. Otherwise, it tries to reuse the covenant ID already attached to the selected input’s UTXO entry. If an ID is available, every generated output receives a CovenantBinding containing the selected authorizing-input index and that ID.

This produces repeated state-lineage patterns useful for load and validation testing. Random selection is a test-data strategy; it is not an application-level security policy and should not be copied into production covenant design without a specification.

Why did transaction version matter?

The generator chose its base transaction version according to whether covenant IDs were in use. Covenant-aware output construction selected the post-Covenant-hardfork version; ordinary construction retained the existing version.

With --randomize-tx-version, the generator could choose version zero or one. The final code only applied covenant bindings when the selected transaction version was the post-hardfork version. Review commits explicitly refined this relationship, preventing an inconsistent combination where legacy-version transactions were populated as though new covenant semantics applied.

Version testing helps developers check acceptance, rejection, serialization, and signature behavior around a planned activation boundary. It does not choose the activation point. Consensus parameters and node activation logic decide when a network accepts a new transaction version.

What did the TN12 support change?

The utility learned to use Testnet 12’s coinbase-maturity parameters when connected to network suffix 12. It also logged the RPC endpoint during connection. Combined with covenant-ID generation and version control, that made the tool more useful for producing representative TN12 traffic.

The word “representative” needs care. Synthetic traffic can cover edge cases and produce volume, but it does not prove that real applications have good user experience, safe contract logic, or sustainable demand. A random transaction generator is valuable precisely because it can create patterns normal users may never produce.

The next application layer is compiler and contract tooling. The planned SilverScript stateful covenants guide covers how developers express state transitions; PR #839 itself only improved transport and test generation.

Why was a one-line conversion fix significant?

Consensus data crosses wire, RPC, client, core-transaction, UTXO, SDK, and storage representations. A field defined at both ends can still vanish in an adapter. Review must therefore trace it end to end. The one-line fix preserved bindings, while the generator produced transactions that could expose later losses. Six passing checks accepted the merge but did not equal an independent audit or prove every SDK compatible.

What did PR #839 not deliver?

It did not activate mainnet covenants, publish an application standard, make Rothschild a wallet, or prove random lineages model every valid transition. It supplied no contract audit, final activation parameters, or compatibility guarantee. Its branch target and default-off flags show the work remained experimental.

What were the price implications?

Field preservation and better test traffic reduce implementation risk but do not establish adoption or token demand. PR #839 contains no price target, so a guaranteed KAS catalyst claim would exceed the source.

Frequently asked questions

What is a Kaspa covenant binding?

In this branch, it links an output to an authorizing input and a covenant ID, allowing a UTXO covenant lineage to continue under defined rules.

Is Rothschild a wallet or smart-contract platform?

No. In Rusty Kaspa it is a transaction-generation utility used to create traffic for testing.

Why is transaction version zero important in the tests?

It represents the legacy path in this versioned experiment. Randomizing between legacy and post-hardfork versions helps exercise boundary behavior.

Was PR #839 active on mainnet after merging?

No evidence in the source supports that conclusion. It merged into covpp-reset1, an experimental branch.

Source and verification note

This article is based on merged kaspanet/rusty-kaspa PR #839, including its branch target, review history, file diff, CLI defaults, covenant-population function, transaction-version logic, and RPC converter. Exact behavior describes that February 9, 2026 revision. The source does not establish mainnet activation, production-wallet readiness, a security audit, adoption, or KAS price impact.