Kaspa dust policy after Crescendo changed because Rusty Kaspa removed a temporary mempool rule that had constrained legitimate multi-output transactions. The June 30, 2025 merge relied instead on KIP-9’s active storage-mass framework, which prices persistent UTXO growth more directly while keeping ordinary batching possible under normal mass and fee limits.

Key takeaways

• Rusty Kaspa pull request 698 removed a temporary anti-dust check from mempool validation.
• The deleted check was a relay and admission policy, not a rule that made the transaction invalid under consensus.
• KIP-9 addresses the underlying problem by assigning storage mass to transactions that expand persistent UTXO state.
• Removing the temporary rule helped legitimate multi-output workflows, but it did not make spam free or remove transaction limits.
• The merge is an engineering and user-experience change, not evidence for a KAS price prediction.

What exactly did Rusty Kaspa pull request 698 remove?

The official Rusty Kaspa pull request 698 removed a short check from mining/src/mempool/validate_and_insert_transaction.rs. For a non-coinbase transaction, the check counted outputs minus inputs. If that difference exceeded two and the fee was less than one KAS for each extra output, the node rejected the transaction from its mempool as spam.

The merge also removed the corresponding RejectSpamTransaction error and stopped treating that error as a spam event in transaction relay. Those details matter because the change concerned whether a node admitted and relayed a transaction. The patch did not erase signature checks, UTXO validation, standardness policy, compute-mass limits, storage-mass rules, or block validation.

PR 698 recorded 155 additions and 26 deletions across 53 files, but most touched files adopted workspace lint settings. The substantive policy change was concentrated in the mempool, mining error, and relay code. Reading the diff prevents a large file count from being mistaken for a broad consensus rewrite.

Why had Kaspa added a temporary dust rule?

“Dust” commonly describes very small unspent transaction outputs whose long-term storage and indexing cost can be disproportionate to their value. Kaspa’s high throughput made uncontrolled UTXO-set growth a concrete operational concern. An attacker could create many tiny outputs, forcing full nodes to retain more persistent state.

The KIP-9 specification says a September 2023 attack exploited that pattern. A fast mempool patch limited transactions that created substantially more outputs than they consumed. It stopped the immediate pressure, but it also affected ordinary transactions with several recipients. The PR description therefore calls the mechanism too restrictive for legitimate multi-output use.

A temporary rule can be a rational incident response even when it is not an ideal permanent design. Its purpose is to reduce damage while maintainers build, review, test, and activate a mechanism aimed at the actual resource being consumed.

How did KIP-9 replace the blunt restriction?

KIP-9 introduced an extended mass model for state growth. It separates compute mass, which represents processing cost, from storage mass, which represents persistent UTXO burden. The transaction’s effective mass is governed by the larger constraint, while block accounting tracks the relevant resource limits.

At a high level, the storage formula increases pressure when a transaction turns value into many small outputs. It considers both the values and number of inputs and outputs, and it requires populated UTXO context because input amounts are not present in a standalone transaction. The specification also accounts for non-standard script sizes that occupy more storage.

This is more targeted than asking only whether outputs outnumber inputs by a fixed threshold. A transaction that creates costly persistent state receives greater storage mass, while a legitimate batching transaction can proceed when its outputs, mass, and fee fit the active rules. The wider context of the activation is covered in what Kaspa changed with Crescendo.

Did removing the rule eliminate Kaspa’s spam defenses?

No. It removed one temporary heuristic after the more fundamental KIP-9 mechanism became active. Nodes still validate referenced UTXOs, scripts, signatures, transaction structure, computed mass, storage mass, fees, standardness, and consensus context. Miners still have finite block capacity and select transactions according to their policies.

Nor does the change guarantee that every unusually shaped transaction will be relayed by every service. Wallets, exchanges, public RPC providers, and mining pools may apply their own operational limits. Developers should test against supported node releases and inspect the actual error rather than assuming that all rejection is “dust policy.”

What did the change mean for wallets, exchanges, and merchants?

Multi-recipient transactions are useful for exchange withdrawals, mining-pool payouts, merchant settlements, and wallet consolidation strategies. The temporary rule could delay or price these workflows according to a simple output-count heuristic. KIP-9 lets software reason about the transaction’s actual storage footprint instead.

Application developers should still estimate mass before signing, choose output amounts deliberately, avoid creating uneconomic UTXOs, and handle fee changes. A merchant payout service should also test worst-case batches, record transaction IDs, retry idempotently, and avoid assuming that a broadcast response proves later acceptance.

For local devnets, parameter changes should remain explicit and isolated from mainnet assumptions. Our guide to Kaspa consensus parameter overrides explains why a successful custom-network test is not evidence that a mainnet transaction will follow identical policy.

Does this update say anything reliable about KAS price?

Only indirectly, and not enough for a forecast. Lower friction for legitimate transaction construction can improve developer and operator experience, while better state accounting supports node sustainability. Those are useful protocol qualities. Market price, however, also reflects liquidity, macro conditions, exchange access, risk appetite, usage, and expectations.

A merged pull request is strong evidence about code history. It is not a trading signal, an adoption metric, or a promise of future demand. Technical analysis should remain separate from investment claims.

Frequently asked questions

Did PR 698 allow unlimited tiny outputs?

No. It removed a specific fee-and-output-count mempool check. KIP-9 storage mass, transaction mass limits, standard validation, fees, and block limits continued to constrain transactions.

Was this a second hardfork after Crescendo?

The June 30 merge itself was a software policy change. Its rationale was that KIP-9 had already become active through the Crescendo consensus upgrade.

Why not keep both protections permanently?

The PR states that the temporary mechanism hindered legitimate multi-output transactions and was unnecessary once KIP-9 addressed UTXO growth more directly. Redundant heuristics can impose user costs without matching the underlying resource cost.

Source and verification note

The primary source is Rusty Kaspa pull request 698, merged on June 30, 2025. Its diff was checked against the active KIP-9 specification, including the motivation, extended mass formula, and wallet implications. This article distinguishes merged code from broader interpretation and provides no financial advice.