The Kaspa transaction script engine cleanup merged on December 9, 2025 through rusty-kaspa PR #774. It removed two runtime feature flags, replaced a KIP-10-specific integer wrapper with native i64, simplified numeric opcodes, and consolidated test fixtures. The patch reduced legacy branching; it did not announce a new hardfork, opcode set or activation date.

Key takeaways

• kip10_enabled and runtime_sig_op_counting were removed from TxScriptEngine construction and related validation paths.
• The special Kip10I64 type was replaced with i64, while deserialization retained the eight-byte behavior used by the wrapper.
• Numeric opcode implementations were rewritten without the previous numeric_op macro.
• GitHub reports 490 additions and 6,267 deletions across 13 files, but 5,397 deletions came from one removed JSON fixture.
• Because transaction scripting sits on a consensus-sensitive path, “cleanup” still requires review, negative tests and disciplined release deployment.

What changed in the Kaspa transaction script engine?

The merged rusty-kaspa PR #774 contains eight commits rather than a narrative description. Their titles and public diff provide the primary evidence. The first commits remove kip10_enabled and runtime_sig_op_counting from the engine and callers. Later commits remove the numeric macro, replace Kip10I64, rename tests and delete a redundant comment.

That sequence indicates consolidation around one supported behavior. Instead of constructing an engine that may execute old or new branches depending on booleans, callers use a smaller interface. Fewer mode combinations can make the code easier to reason about and reduce the number of states tests must cover.

It is still wrong to call this “just cosmetic.” The affected files include transaction validation, opcode execution, data-stack handling, integration tests and wallet PSKT code.

Why were the KIP-10 branches legacy?

The official Kaspa Improvement Proposals index lists KIP-10, “New Transaction Opcodes for Enhanced Script Functionality,” as active. By December 2025, carrying an enabled switch for its behavior inside ordinary engine calls created an alternate path that no longer represented the main supported rule set.

PR #774 itself does not publish an activation policy or claim that every historical network context can ignore the distinction. Therefore, the defensible conclusion is limited: the current rusty-kaspa code no longer needed those runtime flags in the changed paths. Historical validation and test fixtures still had to preserve the correct semantics for the transactions they cover.

This is why removing a flag is different from deleting a protocol rule. The supported behavior remains in the engine; the switch and older implementation branches disappear.

What happened to numeric opcode handling?

The patch removes a macro that had generated similar numeric-opcode implementations and writes the behavior more directly. It also removes the Kip10I64 wrapper and uses Rust’s native signed 64-bit integer type. One commit message explicitly says integer deserialization continues to use eight bytes, matching the removed wrapper, while tests based on four-byte deserialization were removed.

Direct code can be easier to inspect than a macro when each opcode has small but important stack, bounds or error behavior. The tradeoff is repetition. Reviewers must confirm that equivalent opcodes still handle empty values, overflow, encoding limits and stack mutation consistently.

No pull-request evidence supports a claim of faster transactions or lower fees. There is no benchmark in #774, and the change does not alter KAS issuance or block rate.

Did 6,267 deletions mean the engine became 6,267 lines smaller?

No. GitHub’s total is dominated by removal of crypto/txscript/test-data/script_tests-kip10.json, which accounts for 5,397 deleted lines. The remaining general script_tests.json gained 133 lines and lost 45, while opcode code gained 219 and lost 397.

Those figures show why raw diff size needs decomposition. A removed fixture can make a cleanup look much larger than its executable-code change. The important question is whether relevant positive and negative cases were retained or replaced, not whether the deletion counter is impressive.

GitHub records 13 changed files, eight commits and six passing checks. The conversation also shows requested changes followed by approvals, which is stronger evidence than an unreviewed branch but not a formal security audit.

How should developers verify behavior after the cleanup?

Run the repository’s pinned test suite at the merge commit and compare results with a supported release baseline. Pay particular attention to numeric boundary encodings, signature-operation counting, KIP-10 opcodes, malformed stack values and scripts expected to fail. Consensus tests need negative cases because accepting an invalid script is more dangerous than rejecting an obviously malformed test vector.

Downstream developers should rebuild code that directly instantiated TxScriptEngine; removed parameters can cause compile-time failures that reveal the migration point. Wallet and PSKT users should also run signing and finalization fixtures because one constructor call changed there.

The broader Kaspa roadmap discussion at TOKENIZE London provides strategic context, while #774 is a concrete maintenance artifact with a bounded diff.

Does this change Kaspa’s roadmap or market value?

The PR does not introduce a new KIP, consensus activation height, throughput target or user-facing asset. It improves implementation maintainability by eliminating old branches and specialized types. That work matters because a comprehensible script engine is easier to review and extend, but it cannot support a deterministic KAS price claim.

Infrastructure sustainability is another separate fundamental. The later discussion of Kaspa price data after Kas.fyi shows how research quality depends on durable tooling and reproducible datasets. Neither code cleanup nor explorer availability alone predicts returns.

Frequently asked questions

Did PR #774 remove KIP-10 opcodes?

No. The evidence shows removal of the kip10_enabled switch and legacy implementation machinery, not removal of KIP-10 from the active proposal index.

Was this a Kaspa hardfork?

The pull request does not announce a hardfork or activation point. It is a rusty-kaspa implementation cleanup merged into the master branch.

Why can cleanup code still be risky?

Transaction script evaluation contributes to validity decisions. A subtle difference in numeric decoding, stack behavior or signature counting could matter even when the intended result is unchanged.

Source and verification note

All code claims are grounded in kaspanet’s merged rusty-kaspa PR #774, its eight commit titles, 13-file diff and December 9, 2025 merge record. GitHub reports 490 additions, 6,267 deletions and six passing checks; deletion totals are broken down above to avoid exaggerating executable-code reduction. KIP-10 status was checked against the official KIPs repository. No performance, security-audit or price claim is inferred from the merge.