Kaspa KIP-17 implementation reached the Rusty Kaspa covpp integration branch on January 1, 2026, through merged pull request #797. The change added covenant-oriented transaction introspection, byte manipulation, activation plumbing, a counter example, and extensive script vectors. It was code for testing and integration, not evidence that covenants were active on mainnet.

Key takeaways

• Rusty Kaspa PR #797 merged 21 commits into covpp, not the repository’s master branch.
• GitHub reports 7,305 additions, 382 deletions, and 29 changed files; 5,456 added lines were covenant script test vectors.
• The implementation let scripts inspect selected spending-transaction fields and apply new byte, hash, signature, and arithmetic operations.
• Consensus validation enabled the new behavior only when a DAA-score activation flag was active.
• At the merge cutoff, configured network parameters set covenant activation to never, so the merge was not a mainnet activation.

What exactly merged in Kaspa KIP-17 implementation PR #797?

The pull request was opened against kaspanet:covpp and merged there on January 1. That branch detail is essential: saying that covenants “entered the codebase” means an integration line gained an implementation, not that every stable node or wallet immediately used the rules.

The diff touched consensus configuration, transaction hashing, contextual UTXO validation, the transaction script engine, RPC conversion, PSKT handling, integration tests, and examples. GitHub’s line statistics describe the review diff, not the size or complexity of the feature. Most additions were in crypto/txscript/test-data/script_tests_covenants.json, which is useful evidence of test coverage but does not replace independent review.

The PR description linked a then-pending KIP-17 proposal. This article therefore treats the merged code and its immutable review history as the January 1 source of truth, rather than importing later specification changes into an earlier publication date.

What is a covenant in Kaspa’s UTXO model?

A normal UTXO script decides whether the current spending attempt is authorized. A covenant extends that idea by allowing the script to constrain properties of the transaction that spends it. For example, a state-carrying output could require the next transaction to recreate an output with a specific script and an incremented value.

The PR included a counter example that seeded a covenant-style UTXO, accepted spends that advanced the counter by one, and demonstrated failures for an unchanged counter or a jump by two. It is an educational example, not a production asset protocol. Real applications still need threat modeling, fee handling, wallet support, recovery design, and adversarial testing.

Which script-engine capabilities were added?

The implementation added introspection opcodes for transaction-level data such as version, lock time, subnet, gas, and payload slices. Other opcodes exposed input and output properties including outpoints, counts, scripts, amounts, and the current input index. Byte-string operations, additional hashing functions, stack-based signature checks, and arithmetic primitives supported more expressive validation.

These capabilities matter because a script can evaluate the structure of its spending transaction rather than relying only on a signature. They also increase the review surface. Every opcode needs defined stack behavior, size limits, error handling, deterministic execution, and agreement across all validating nodes.

The best evidence is the PR’s commits and changed files, not a generalized claim that Kaspa became a full smart-contract platform. The merge supplied bounded script-engine building blocks in a development branch.

How did activation gating protect existing networks?

PR #797 added a covenants_activation fork parameter and passed an EngineFlags value into script execution based on the current block’s DAA score. Before activation, covenant opcodes remained unavailable; after an explicitly configured activation, the validator could apply the new rules.

At merge commit e2b77bb, the checked-in mainnet and testnet parameter sets assigned ForkActivation::never() to that field. This is strong evidence that the code was dormant by default on those configured networks at the January 1 cutoff. Activation plumbing makes controlled testing possible; it is not an activation announcement.

That distinction also prevents a consensus mistake in reporting. A feature branch can compile, tests can pass, and examples can run while production nodes continue enforcing their previous rules.

What testing evidence accompanied the change?

The largest new artifact was the covenant JSON vector file. The PR also added script-engine sanity checks, activation tests, integration-test changes, hashing tests, and the counter covenant example. Review commits show fixes to argument ordering, error messages, serialization, hashing, and transaction-ID preimage handling before merge.

That history is valuable: reviewers found and corrected details during development. It does not establish formal verification, complete wallet compatibility, or safe handling of every application design. Consensus code should be evaluated through repeatable tests, cross-implementation reasoning, resource-bound analysis, and sustained testnet operation.

What should builders do with this milestone?

Builders can use the PR to understand the intended execution model, review opcode semantics, reproduce tests, and prototype with valueless test coins. They should pin the exact commit used, expect interfaces to change, and avoid presenting prototype behavior as mainnet capability.

The next evidence point is the controlled network described in our Kaspa Testnet 12 covenants guide. For broader context, the Kaspa 2025 price and fundamentals review separates protocol work from market and adoption claims.

Frequently asked questions

Did PR #797 activate KIP-17 on Kaspa mainnet?

No. It merged into the covpp integration branch, and its checked-in network parameters kept covenant activation disabled at that cutoff.

Did KIP-17 turn Kaspa into a general-purpose smart-contract chain?

The merge added covenant-oriented, bounded script capabilities. That is not equivalent to an unrestricted virtual machine or proof that a complete application platform was live.

Were the 7,305 added lines all production logic?

No. GitHub attributes 5,456 additions to a JSON script-test file, with the rest distributed across code, examples, and integration tests.

Source and verification note

The primary source is kaspanet/rusty-kaspa pull request #797, merged January 1, 2026. Branch names, commit count, changed-file count, and diff totals come from GitHub’s PR metadata. Activation defaults and the counter example were checked at merge commit e2b77bb88a8eaa8eedefe677ed21994e3dea024d. Later revisions to the KIP specification are deliberately excluded from claims about the January 1 state. This is technical analysis, not a claim of mainnet availability or application security.