Kaspa multidimensional mass is an experimental resource-accounting model that tracks storage, compute, and transient transaction costs separately. Rusty Kaspa PR #868 added per-dimension block limits and a normalization method for mempool ranking. The merge targeted the covpp-reset1 development branch, so it was not evidence that new fee rules were active on mainnet.

Key takeaways

• PR #868 replaced a single max_block_mass parameter with explicit storage, compute, and transient limits.
• Block validation compares accumulated mass in each dimension with that dimension’s own ceiling.
• MassCofactors translate resource utilization into a shared compute-reference scale for simplified mempool ordering and fee-rate calculations.
• TN12, simnet, and devnet received extra transient headroom for large proof data; the mainnet constants in this branch retained equal 500,000-unit limits.
• The pull request merged into the experimental Covenant++ branch, and code comments said future mempool work could use the dimensions more efficiently.

What did Rusty Kaspa PR #868 change?

The official Rusty Kaspa PR #868 records 14 commits, 24 changed files, 575 additions, and 131 deletions. It merged on February 8, 2026 into covpp-reset1, not master.

The change introduced a BlockMassLimits structure with three fields: storage, compute, and transient. The block-body processor then accumulated the three types independently and returned a dimension-specific error when any one exceeded its configured limit. Counters were likewise split, allowing software to observe which resource a workload consumed.

This is broader than charging by serialized bytes alone. A transaction can be modest in one dimension and demanding in another, especially when new script or proof-verification paths require temporary data and computation.

What do storage, compute, and transient mass represent?

Compute mass reflects work such as transaction bytes, script-public-key bytes, and signature operations under configured coefficients. Contextual storage mass accounts for lasting UTXO-set burden. Transient mass covers temporary validation resources that do not remain as UTXO state; large proof-related inputs motivated extra TN12 headroom. These are deterministic policy units, not direct measurements of CPU seconds, disk bytes, or electricity.

How does the normalization formula work?

Separate limits create a problem for a one-dimensional mempool: how should it compare a transaction using 60% of compute capacity with one using 80% of transient capacity? PR #868 added cofactors that map each dimension onto the compute limit as a reference.

For a resource dimension i, the code calculates cofactor_i = compute_limit / limit_i. It then multiplies raw mass by that cofactor, rounds upward, and takes the maximum normalized value across storage, compute, and transient mass. The result reflects the transaction’s most heavily utilized dimension relative to its available block capacity.

The pull request’s tests use limits of 1,000,000 storage, 500,000 compute, and 250,000 transient units. At 50%, 60%, and 80% utilization respectively, normalized values become 250,000, 300,000, and 400,000 compute-reference units. The ordering therefore follows bottleneck utilization rather than the largest raw number.

How were block limits configured in the branch?

Mainnet and general-testnet constants became BlockMassLimits::with_shared_limit(500_000), so every cofactor remained one. TN12, simnet, and devnet used 500,000 storage, 500,000 compute, and 1,000,000 transient units, plus a 300,000-byte maximum signature script for proof testing. These experimental-branch constants did not prove a mainnet policy change. Rusty Kaspa v1.1.0 RC3 was a separate mainline pre-release.

How did mining and mempool logic use the new dimensions?

Block validation enforced all three ceilings separately. Mempool fee-rate keys, estimates, and orphan limits used normalized mass on the compute-reference scale. Code comments call this one-dimensional reduction a simplification: future packing could use the full vector more efficiently when transactions consume complementary resources. The merge was accounting infrastructure, not proof of an optimal fee market.

Why did multidimensional mass matter for covenant and ZK research?

Classic transfers have relatively predictable scripts and sizes. Covenant applications and proof-verification operations can create less uniform workloads: permanent state transitions, expensive verification, or large temporary proof material.

One shared ceiling forces every resource to inherit the same headroom. Separate ceilings let developers test a larger transient allowance without equally expanding persistent storage or compute capacity. That separation can make resource policy more precise, but it does not make verification free or remove denial-of-service constraints.

Related Kaspa 2026 roadmap analysis explains why code, testnet results, activation design, and mainnet deployment must be treated as different milestones.

What did the merge not establish?

PR #868 did not set a market fee, guarantee cheaper transactions, activate mainnet rules, or solve multidimensional block packing. Its floating-point normalization deserves implementation review; in this diff it primarily served mining and mempool simplification, while consensus validation compared raw integer totals with integer limits. Later code may refine this first interface.

What were the price implications?

More precise accounting can support programmable-transaction testing, but PR #868 supplies no adoption outcome or KAS valuation target. A development-branch merge is not a guaranteed price catalyst.

Frequently asked questions

Is transaction mass the same as transaction size?

No. Serialized size can contribute to compute mass, but Kaspa’s model also accounts for signature operations, UTXO storage effects, and transient validation resources.

Does a transaction pay three separate fees?

PR #868 does not establish three user-visible fee payments. It tracks three resource dimensions and uses a normalized scalar in the experimental mempool logic.

Was multidimensional mass live on mainnet in February 2026?

The cited PR merged into covpp-reset1. That is evidence of experimental integration, not mainnet activation.

Why use the maximum normalized dimension?

The maximum represents the transaction’s tightest resource bottleneck relative to configured capacity. It creates one sortable value, although the code acknowledges that future packing can use the full vector more efficiently.

Source and verification note

This article is based on merged kaspanet/rusty-kaspa PR #868, including its branch target, commit record, changed files, configuration diff, normalization tests, and mempool comments. Exact limits and formulas refer to that February 8, 2026 revision. The source does not establish mainnet activation, final parameters, an independent audit, lower fees, application adoption, or a KAS price outcome.