Kaspa after Crescendo produced blocks at 10 BPS instead of one block per second, shortening the network’s operating rhythm while preserving proof of work. The May 5, 2025 hardfork also activated consensus and storage changes that mattered to node operators, wallet developers, miners, merchants, and anyone evaluating Kaspa’s real-world payment experience.

Key takeaways

• Crescendo activated on Kaspa mainnet on May 5, 2025 after extended Testnet 10 operation.
• The headline change was a tenfold block-rate increase, from 1 BPS to 10 BPS.
• KIP-9, KIP-10, KIP-13, and KIP-14 addressed storage, transaction introspection, and the broader consensus upgrade.
• Faster blocks improve responsiveness, but applications still need risk-based confirmation policies.
• The upgrade was infrastructure progress, not a guarantee about KAS price or adoption.

What changed for Kaspa after Crescendo?

The most visible change was block cadence. According to KASmedia’s post-upgrade report, Crescendo raised mainnet block production from one to ten blocks per second. That means the BlockDAG receives new blocks much more frequently, giving transactions more frequent opportunities to enter the consensus history.

The increase was not an isolated configuration switch. Rusty Kaspa, the high-performance Rust implementation of the node, provided the foundation for the heavier processing load. The upgrade followed more than a year of 10 BPS operation on Testnet 10, where contributors could observe network behavior before the mainnet activation.

This distinction matters: 10 BPS describes block production, not a promise that every payment is economically final in one tenth of a second. Wallets, exchanges, and merchants choose confirmation policies according to transaction value, threat model, and operational risk.

Which Kaspa Improvement Proposals were involved?

The source report identifies several proposals in the Crescendo package. KIP-14 coordinated the main consensus transition, while KIP-9 and KIP-13 addressed persistent and transient storage requirements. Those rules help the network account for the data burden created by transactions instead of treating every output as equivalent forever.

KIP-10 introduced transaction-introspection opcodes. Introspection allows scripts to reason about selected properties of the transaction being evaluated. That is an important primitive for covenant-style controls and more expressive transaction policies, although it is not the same as adding a general-purpose virtual machine to Kaspa Layer 1.

For non-developers, the useful lesson is that Crescendo combined performance with resource-accounting and scripting work. Evaluating it only by the 10 BPS headline misses much of the engineering scope.

What did 10 BPS mean for payments?

A quicker block rhythm can make a checkout feel more responsive because a valid payment can be observed and accumulated in the DAG sooner. It also gives payment software more frequent state updates. Kaspa’s UTXO model remains important: a merchant watches the relevant address and outputs, validates the received amount, and waits for the chosen acceptance threshold.

Good commerce software still needs to handle underpayments, overpayments, multiple transfers, exchange-rate expiry, duplicate callbacks, and temporary API failure. The network upgrade does not remove those application responsibilities. Our overview of Kaspa payments for online commerce provides the customer-facing context, while this article focuses on the protocol change.

What changed for miners and node operators?

At 10 BPS, nodes see and process blocks more frequently. Operators therefore need supported releases, adequate CPU, memory, storage, and bandwidth, plus monitoring that can distinguish normal load from a fault. Miners likewise need software compatible with the activated consensus rules; an outdated node can follow a rule set that the upgraded network no longer accepts.

More frequent blocks also change the texture of mining statistics. Short observation windows can look noisy, especially for solo miners, because finding a block remains probabilistic. The source article pointed readers to a community solo-mining simulator, but simulations are planning aids, not earnings guarantees.

Why the testnet period mattered

Testnet 10 had already been operating at 10 BPS for an extended period before the mainnet fork. That created evidence about stability and performance under testnet conditions and gave developers time to update tooling. Community participation added diverse hardware, networks, and usage patterns to the rehearsal.

Testing cannot prove the absence of every bug. It can, however, make the upgrade boundary observable and expose incompatibilities earlier. A careful rollout combines testnets, code review, release documentation, operator coordination, and post-activation monitoring.

How can the community explain Crescendo accurately?

The strongest explanation begins with verifiable facts: date, block-rate change, named proposals, source repository, and known limitations. Avoid turning a technical milestone into a price prediction. Kaspa merchandise can help start a conversation, but the design should point people toward learning rather than substitute branding for evidence.

For example, a Kaspa Kulture T-shirt can invite the question “what is Kaspa?” The responsible answer is a short explanation of proof of work, BlockDAG ordering, and Crescendo’s tested 10 BPS transition, followed by links to primary technical material.

Frequently asked questions

Did Crescendo make Kaspa a proof-of-stake network?

No. Kaspa remained a proof-of-work network. Crescendo changed block rate and multiple consensus rules; it did not replace mining with staking.

Does 10 BPS mean every payment is final in 0.1 seconds?

No. Blocks are produced at that approximate rate, but acceptance and confirmation policies depend on application risk and observed consensus state.

Was Crescendo only a speed upgrade?

No. The package included storage-accounting and transaction-introspection changes in addition to the 10 BPS transition.

Source and verification note

The primary editorial source is KASmedia’s May 12, 2025 report, A Knight for Glory: Quantum Resistance, ETH Denver, and Crescendo Responses. Technical claims should also be checked against the public rusty-kaspa repository and the linked Kaspa Improvement Proposals. This article is educational and makes no investment claim.