Kaspa script vector optimization in rusty-kaspa PR #757 enabled SmallVec’s const_generics feature and changed the inline script capacity from 36 to 35 bytes. Merged on November 18, 2025, this focused maintenance patch aligns the container more closely with common script-public-key data while preserving conversion and serialization test coverage.

Key takeaways

• ScriptVec uses SmallVec so short script byte sequences can be stored inline instead of requiring a separate heap allocation.
• The patch enabled SmallVec’s const_generics feature and changed SCRIPT_VECTOR_SIZE from 36 to 35.
• Rusty-kaspa’s own code comment says the type is optimized for the common 34-byte P2PK script size.
• JSON, JavaScript/WASM, RPC-hex and utility tests were updated for the new capacity and passed the repository’s merge checks.
• No benchmark accompanied the pull request, so it supports a precise implementation claim—not a quantified speed, memory or price claim.

What changed in the Kaspa script vector?

The primary source is rusty-kaspa pull request #757. Its workspace dependency change adds the const_generics feature to SmallVec 1.11.1. In consensus/core/src/tx/script_public_key.rs, the SCRIPT_VECTOR_SIZE constant moves from 36 to 35, making the alias effectively SmallVec<[u8; 35]>.

Five related test locations were adjusted to use the same size: transaction JSON serialization, script-public-key serialization and WASM conversion, RPC hex conversion, RPC model mock data, and the shared hex utility. GitHub records a deliberately small diff—10 additions and 10 deletions across six files—with six checks passing before merge.

The change fixes repository issue #748, which asked for const_generics support so SmallVec could accept array sizes outside its older predefined set. It is an internal representation update, not a new transaction script opcode or a change to what a valid Kaspa payment means.

What does SmallVec do here?

A normal Rust Vec<u8> stores its elements in separately allocated memory once populated. SmallVec provides a vector-like interface with room for a chosen number of elements inside the value itself. When the byte sequence fits, the container can avoid a separate allocation; if it grows beyond that inline capacity, it can still spill to heap storage.

That behavior is useful for script public keys because many instances are short and repeatedly created, copied, serialized or passed through node and RPC code. Rusty-kaspa’s source comment says the chosen type is optimized for the common 34-byte pay-to-public-key script size. A 35-byte inline array therefore covers that documented common case while supporting an additional byte of capacity.

Upstream SmallVec documentation explains the general inline-storage model. It should be read as library behavior, not as evidence that this particular Kaspa patch achieved a measured end-to-end performance gain.

Why was the const-generics feature necessary?

Rust const generics allow an array length to be represented as a compile-time parameter. With SmallVec’s feature enabled, rusty-kaspa can use the exact [u8; 35] backing array selected by the maintainers instead of being constrained to a library-provided list of array sizes.

The important point is design precision. The patch did not replace dynamic script handling with a fixed-length script format. SmallVec remains variable-length: 35 is its inline capacity, not a consensus limit saying every script must contain exactly 35 bytes.

That distinction prevents two common misreadings. First, lowering the capacity from 36 to 35 does not truncate valid scripts. Longer sequences can spill out of inline storage. Second, enabling const generics does not introduce “generic scripts” at the protocol level; it is a Rust compilation feature used by the node implementation.

How did the patch protect compatibility?

The diff updates expected hexadecimal strings and test arrays wherever the prior 36-byte fixture was embedded. It retains round-trip checks: serialize a script public key, deserialize it and compare the resulting bytes; convert SmallVec data to and from RPC hex; and pass a script through JavaScript/WASM representations.

These tests are meaningful because representation changes can fail at boundaries even when core logic compiles. A node implementation must keep consensus objects, RPC models and browser-facing bindings in agreement. The merge page reports six checks passed, although the public PR does not claim an exhaustive audit of every external application.

Developers working near header representations can compare this narrow patch with the larger Kaspa virtual relations by level refactor, which introduced compression plus database fallback concerns. The shared lesson is to test conversion boundaries whenever an internal collection changes.

Does this change fees, scripts or transaction validity?

PR #757 does not change Kaspa’s fee formula, script language rules, signature verification or accepted transaction formats. It changes the Rust container capacity used to hold script-public-key bytes in memory and updates fixtures accordingly. Existing scripts are still represented as variable-length byte sequences.

The patch also provides no evidence that wallet users will notice a latency difference. A tiny allocation improvement may matter when repeated across many objects, but total node performance depends on consensus processing, database I/O, networking, workload and compiler behavior. Only a controlled benchmark could isolate the effect.

For the same reason, this commit should not be translated into a KAS price prediction. It is evidence of active code maintenance and attention to data layout. Market value depends on many unrelated technical, liquidity, adoption and macroeconomic factors.

What should builders check?

Builders compiling the relevant revision should keep the repository’s lockfile and feature configuration consistent rather than importing the type alias into another project by memory. Downstream code that hard-coded a 36-byte test fixture should be checked, but production code should not normally assume an internal inline capacity is a protocol rule.

Run serialization, RPC and WASM tests on every supported target. If an application receives scripts over a public interface, validate by protocol rules and length limits documented for that interface—not by SmallVec’s in-memory capacity.

For broader deployment configuration, see Rusty Kaspa environment variables. That update concerns how kaspad receives settings and is independent of this data-layout change.

Frequently asked questions

Does a 35-byte SmallVec reject a 36-byte script?

No. The number describes inline capacity. SmallVec can allocate additional storage for a longer vector; consensus and API validation rules determine whether a script is acceptable.

Why not set the capacity to exactly 34?

The merged patch chose 35 while documenting optimization for the common 34-byte P2PK script. The PR does not publish a design note comparing every possible capacity, so a more specific motive would be speculation.

Did this patch make Kaspa transactions cheaper?

No fee reduction is documented. The change affects rusty-kaspa’s in-memory representation and tests, not the serialized transaction fee rules.

Source and verification note

This analysis is grounded in kaspanet’s merged rusty-kaspa PR #757, merged November 18, 2025. The public diff shows the SmallVec feature flag, the 36-to-35 constant change, six touched files, 10 additions, 10 deletions and updated round-trip fixtures. SmallVec behavior is cross-checked against its version 1.11.1 documentation. No performance benchmark or market projection is inferred.